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

[Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>]

I’d have a look at the compression parm.   That will slow the save down by orders of magnitude.    I somehow doubt it needs to be that compressed.  I’ll bet CPU jumps a bit during that operation as well.  


Jim Oberholtzer
Agile Technology Architects

> On Jun 19, 2025, at 1:33 AM, Reeve <rfritchman@xxxxxxxxx> wrote:
>
> 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!
>
> --rf
> --
> 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.