Starts commitment control for files that are being journaled.
What is the purpose of STRCMTCTL command ?
February 4, 2018
February 4, 2018
By NickLitten
February 4, 2018
Starts commitment control for files that are being journaled.
Session expired
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.
Is there a way to see who started Commitment Control with the STRCMTCTL command? Thanks for any light you can shed on this.
COMMIT CONTROL only covers the job that is running it. It is not system-wide. So YOU can signon and STRCMTCTL and that means that any updates/adds/deletes to journaled files will only be applied when a COMMIT statement is reached or they will be discarded if a ROLLBACK is processed (or if you signoff without doing a commit). Make sense?
Thanks Nick… We are very confused as starting around March 20th of this year one of our backup jobs that has run fine forever. Stopped working with error messages and they seem to point to QILE commitment definition. We are doing save while active saves that we have not changed in years and now they can not reach a successful check point anymore and the save ends abnormally. It appears to be related to the QILE commitment definition but we are guessing at this point.
We are supposed to compile ALL of our programs with COMMITT(*NONE) so we are wondering if someone did Not do that and maybe that is why we are having problems. we are a little lost to say the least. We appreciate any ideas you might have. Thanks in advance.
Without looking at the code, *guessing*, it sounds like you are within a commit boundary — in other words a program has a whole bunch of journaled updates to apply so is locking a bunch of data? This might explain why the save boundary cannot complete…
I appreciate your help Nick. It turned out being someone compiled a program with COMMIT(*CHG) instead of *NONE as we don’t use commitment control. We recompiled the program and the saves worked again . Thanks again
Glad you founbd it. Being in a commit boundary with COMMIT(*CHG) is not obvious and is a P.I.T.A 😉
You can override this at code level, so you dont need to remember to compile with COMMIT(*NONE). More here https://www.nicklitten.com/sql-rpg-and-the-annoying-compile-commit-none-thing/