Re: SAVLIB SAVACT(*SYSDFN)

This is a formula for disaster.  You run the risk of "posting a debit

without a credit", and journaling in necessary.
In normal operations, if a job happens to blow up in the middle between
files, then yes.  It is probably a good idea in general but we haven't
taken the step in mass yet.  It would probably help with resolving data
issues but I don't want to get into a lenghty discussion.  We do journal
some files and we may journal more if this becomes an issue.  We may
journal in mass, I don't know.  Backups are also a low probability of out
of sync data for us.  I won't drag out the details but the basics are:
1. Get a list of interactive users with locks then send them a message
about signing out.  Wait some time for jobs to end.
2. Kill all jobs at once with a lock on the library being saved except MSGW
jobs.  Wait some more time for jobs to die.
3. ALCOBJ *EXCL WAIT(0) on every file in the library.  If any errors other
than CPF0944, get a list of jobs holding the locks and kill them.  Anything
afterwards should either be ending or in MSGW.
4. SAVLIB SAVACT(*NO).  This will wait two minutes on some objects if jobs
are still dying.  The only objects not saved are locks from the MSGW jobs.

So, what happens if we change from SAVACT(*NO) to SAVACT(*SYSDFN) in V5R4
to get the missing MSGW locked data?  Any longer saves?  Any missed
objects?  Thanks for your input!

Craig