Re: CMTW (commit wait) on a large number of jobs

Arco, thank you for your explanation.

A careful reading of the SAVACT parameter suggests *LIB (from the command
help: "Objects in a library can be saved while they are in use by
another job. All of the objects in a library reach a checkpoint together
and are saved in a consistent state in relationship to each other.) was
the culprit. Even though I was saving only a few small objects, *LIB was
waiting for _every_ object in the journal to sync to reach a checkpoint; we
have multiple EDI/XML/JSON request threads running and there's no telling
when we would have reached a checkpoint. *LIB makes sense for some tables
but not for this harmless read-only object.

*SYSDFN works and is what I should have used.

--reeve



On Thu, Jun 19, 2025 at 11:51 AM Arco Simonse <arco400@xxxxxxxxx> wrote:

Hi Reeve,

When saving with "save while active" the OS creates a checkpoint where the
status of the objects under commit control in the same journal must all be
in sync with each other. This process might need a long time to complete,
and since they specified SAVACTWAIT(*NOMAX) it will take all the time it
needs.


https://www.ibm.com/docs/en/i/7.5.0?topic=concepts-commitment-control-save-while-active

Best regards,
-Arco


Op do 19 jun. 2025 07:33 schreef Reeve <rfritchman@xxxxxxxxx>:

A customer has been periodically experiencing a backlog of CMTW's at
certain times of the day and we determined the cause was an attempt to

save

a read-only table using this command:
SAVOBJ OBJ(&table) LIB(&datalib) DEV(*SAVF) OBJTYPE(*FILE) +
SAVF(&SAVFLIB/&SAVF) TGTRLS(V7R3M0) UPDHST(*NO)

SAVACT(*LIB) +

DTACPR(*HIGH) SAVACTWAIT(*NOMAX)


The SAVACTWAIT(*NOMAX) is likely the villain...but why when the apps are
just reading?

There were about 1,000 *SHRRD locks on the table in question. I set
commitment control to *CHG. I have WITH *NC on each select. All SQL, of
course. V7R3. The app is a complex, database-heavy pricing service
program used in interactive and batch jobs. I will add PRECHK(*YES)
ACCPTH(*NO).

Even though the backup in question ran every night at 1800, we didn't
always have the problem. There are other unrelated jobs triggering at
1800.

This is a puzzler. Thank you for your insight!

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.