Re: SAVLIB SAVACT(*SYSDFN)

*SYSDFN will still reach multiple checkpoints during the course of the

save.
Thanks for your input, Sue.  I went through the entire thread again trying
to understand it and I think I'm pretty much there.  Rob's initial post
talked about not doing journalling.  We intentionally don't kill jobs in
MSGW for fear of permanent data corruption.  We have a process to
gracefully kill non-MSGW jobs and ALCOBJ *EXCL to thwart the out of sync
data saved.  This works fine.  The one or two jobs in MSGW are the only
ones that cause a couple files to not get saved every so often due to no
SWA.  That is the entire reason for looking into save while active *SYSDFN
so we don't lose entire files.  In my tests, with SAVLIB *SYSDFN, the
waiting only occurred on files set for update.  Of course, with *SYSDFN it
saved the file after the wait whereas *NO left the object out.  I didn't
notice much of a time difference but you said the quantity of objects could
also determine checkpoint processing.  We have many objects saved in a
library but we never list more than one library on the SAVLIB.  Do you
think we will notice our backups taking longer with *SYSDFN than *NO?  I
have never seen *SYSDFN on a SAVLIB skip any objects, even ones in use.  If
the *SYSDFN were to skip some objects for some reason, it would be logged,
right?  Most of our data libraries are only a couple thousand objects.  One
of our software packages has its data library with about 146,000 objects.
That logs some messages to QSYSOPR in the backup job (job hold large number
of objects).  Anything we should watch out for especially with V5R4?
Thanks in advance!

Craig