Re: SAVLIB SAVACT(*SYSDFN)

 wrote on Tue, 08 Aug 2006 20:28:52 GMT:

Instead of skipping critical objects (current technique) 
that are locked by these particular jobs we thought of
changing from SAVACT(*NO) to SAVACT(*SYSDFN).

I'm sure Al will correct me.....

In V5R4, *SYSDFN works much like the *LIB entry for SAVACT of 
previous releases.  This means the SAVLIB job will attempt to get 
a checkpoint across all objects within the library and if it 
can't, it will create multiple checkpoints, or if there are too 
many objects, it will create multiple checkpoints to avoid those 
object limits.  

As with all SWA processing, you have control over the the amount 
of time it will wait while trying acquire the checkpoint.  At the 
end of the wait period, if checkpoint can't be obtained, the 
object/file is skipped.

In previous releases, *SYSDFN did not attempt to mimic *LIB and 
simply did things its own way.  Meaning, you couldn't really 
figure out all that was part of the same checkpoint and this left 
you at risk of having the order header out of sync with the order 
detail in the event of a restore.  This is less likely to happen 
in V5R4 and later releases (unless it gets changed again!) when 
all the files reside in the same library.  

HTH,