Re: is this the correct understanding for commitment control running in ILE?

Jay,

Using SQL its very simple, just compile your programs with the (hopefully
unchanged) defaults and ensure that journaling is turned on for all files
(that should be the case anyway) and its done. Using RLA commitment control
has to be started before the first update operation.
In your case its rather simple: Your PgmA is your commit master, just
compile it as SQLRPGI and it will start commit implicit. This programm
should now be responsable for the transaction. It calls its slaves (all
running with *caller) and decides afterwards if its okay and ends the
transaction with commit, in case of error with rollback. I would not use the
implicit commit at end of ACTGRP, its more readable to issue an explicit
commit. Normally a Programm has to do more than one transaction and needs
the commit after each single transaction - its a matter of style and not of
functionality.

Starting commit at Joblevel, you would loose the ability to have diffrent
commit levels within one job. If you still have OPM programms, making
problems in your actual environment, change the old programs to ile, instead
of restricting your new programms.

In case of lock conflicts it will timeout as expected. Using commit, you
could restart with rollback, without commit, the database remains in
incosistent state. Its much easier to work with commitment controll than
without! In heavy conflicting environments there is one problem with
DB2/400: reading a record for update sets a SHRNUP lock, two diffrent jobs
could read the same record for update and none of these could update the
record. In this case it would be better to start with an update to get the
full lock (we used a dummy update of a flipflop column) and the updates
could be done insequence.

regards Dieter