*NOCMTBDY aka "Dirty Save"

In a nutshell, simplifies (or enables) saves for an always on system, while
complicating the recovery process.

I'm not sure why the job you describe would be causing a problem. But
unless somebody is using commitment control when writing to your source
files (which would require them to be journaled) it shouldn't be an issue
in your scenario.

Charles


On Mon, Aug 7, 2023 at 12:47 PM <smith5646midrange@xxxxxxxxx> wrote:

Does anyone know the details about the *NOCMTBDY? The help text worries
me, specifically that first line of the second paragraph.

There should be nothing changed in this library by this job (still trying
to get access to the journal info to confirm) and if not, do I still have
to do APYJRNCHG or RMVJRNCHG to restore and use the source files in it even
though nothing in the library / files was changed?

*NOCMTBDY
The system will save objects without requiring transactions with
pending record changes to reach a commit boundary. Therefore,
objects may be saved with partial transactions.

If you restore an object that was saved with partial transactions,
you cannot use the object until you apply or remove journal changes
(APYJRNCHG or RMVJRNCHG command) to reach commit boundaries. You
will need all journal receivers that contain information about the
partial transactions to apply or remove the changes. Until you
apply or remove the changes, any future save of that object will
include the partial transactions, even if you do not specify
*NOCMTBDY.




-----Original Message-----
From: smith5646midrange@xxxxxxxxx <smith5646midrange@xxxxxxxxx>
Sent: Monday, August 7, 2023 2:20 PM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxxxxxxxx

Subject: RE: SAVOBJ checkpoint failure

I was able to chase this down.

There is a job running using commitment control and even though it has not
changed anything in the problem library, apparently just having the library
in the libl is enough to cause the checkpoint to fail.

It looks like there is a parm SAVACTWAIT(xxx *NOCMTBDY). I don't know
anything about it but I'll be checking that out.

Thanks all for your help.


-----Original Message-----
From: smith5646midrange@xxxxxxxxx <smith5646midrange@xxxxxxxxx>
Sent: Monday, August 7, 2023 12:53 PM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxxxxxxxx

Subject: RE: SAVOBJ checkpoint failure

Is there a way to find what file(s) / member(s) might have this problem?

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Mark Waterbury
Sent: Monday, August 7, 2023 11:15 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: SAVOBJ checkpoint failure

Someone might have had commitment control active (STRCMTCTL) in their
job, for testing, and then opened some of those source members in SEU ...?
I think that when it says it "failed to reach a checkpoint" that means
there is some commitment control going on ...

On Monday, August 7, 2023 at 10:21:46 AM EDT,
smith5646midrange@xxxxxxxxx <smith5646midrange@xxxxxxxxx> wrote:

We have a process that backs up our dev source and pushes it over to our
prod machine for offsite backup. This has been running for about 6 months
with no problem. We are doing a SAVOBJ to a *SAVF with SAVACT(*LIB) and
now it is failing on one library with the message



Save ended. Unable to reach checkpoint.



I just did the command manually and got the same error. I immediately did
a WRKOBJLCK on the library and there are no locks on it. This process
works on other libraries so it is just one specific library that is
"broken".
Since the library only contains source, there shouldn't be anything using
it.



I recommended opening a ticket with IBM but the admins want to have a
meeting first to discuss this and that is not going to happen until
tomorrow which means we lose another night's backup.



Does anyone have any idea what I can look at in advance?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.




--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.