Re: CPF377F Save ended. Unable to reach checkpoint.

[Charles Wilt <charles.wilt@xxxxxxxxx>]

The late great Al Barsa used to do an awesome presentation about SWA at
COMMON.

One point discussed was a "Dirty (Ragged) SWA".  The following AI generated
info lines up with my recollection...


   - To ALLOW a "Dirty" (Ragged) Save:
   Set the third element of the SAVACTWAIT parameter to *NOCMTBDY (No
   Commitment Boundary).
      - Command Example:
      SAVLIB LIB(PRODDATA) DEV(TAP01) SAVACT(*LIB) SAVACTWAIT(120 *NOCMTBDY
      *LOCKWAIT)
      - What happens: The system will save the object immediately, even if
      it has uncommitted changes. It will issue message CPI3731 to warn you
      that a ragged save occurred.


Al Barsa’s Rules for Handling Dirty SWA
If you must perform a save-while-active where transactions are ongoing, Al
emphasized these strict requirements to ensure the data is actually usable:

   1. Mandatory Journaling: You must journal every object being saved.
   Without the journal receivers, you have no way to "clean" the data after a
   restore.
   2. Apply Journaled Changes (APYJRNCHG): Upon recovery, you cannot just
   restore the files and start the application. You must use the
APYJRNCHG command
   to bring the "ragged" data to a consistent state.
   3. The "Sync-up" Cost: Al often argued that the time you "save" by not
   waiting for a clean checkpoint is often lost tenfold during a high-pressure
   disaster recovery because of the complexity of the manual synchronization
   steps required.


IIRC correctly, Al called this a "last resort" for a 24/7 system that you
could not quiesce.  And to point 3 above, recovery from such a save is
difficult.  But on the other hand, Al pointed out,  how often do you need
to do a recovery?

HTH,
Charles

On Tue, Mar 24, 2026 at 6:17 AM Gad Miron <gadmiron@xxxxxxxxx> wrote:

> Hello guys
>
> In the last couple of months there were 3 failures of a nightly SAVLIB
> LIB(*ALLUSR).
> The CMD was
> SAVLIB LIB(*ALLUSR) DEV(TAP01) ENDOPT(*LEAVE) SAVACT(*LIB) PVTAUT(*YES)
> OMITLIB(WWLLIBD QSRVAGT DWHD URPS)
>
> The error was: CPF377F Save ended. Unable to reach checkpoint.
>
> Looking for CPI8365/CPI836B in DSPLOG, I found:
> CPI8365 99 INFO Save-while-active request requires commit or rollback for
> job 429718/QUSER/QZDASOINIT
>
> Now,
> is there a way to prevent such failures when executing a SAVLIB with
> SAVACT(*LIB)?
> What I aim to is receiving something akin to the MSGs received for locked
> objects
> CPF3761 Cannot use XXX in Library YYY
>
> and then CPF3771 999 objects saved from LIBXXX. 3 not saved.
>
> at the end of the save operation.
>
>
> Can it be done?
>
>
> TIA
>
>
> Gad
> --
> 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.