Re: Fw: Change commitment control after compilation

*young guys* --- LOL
I have been programming since 1973!
the condition i described: pgm a gets lock on company master, processes
transactions calls other pgms that do not update company master and at LR
updates company master.
using commit control, if any other pgm in the stack uses COMMIT op code,
ALL record locks are released.
when pgm A attempts to update company, gets update w/o read error.
this happened in a shop that attempted to use commit control w/o having
designed the entire application to use it. it all pgms in the app were
designed w/commit control in mind, the logic in pgm a would have been
different.



Jeff Young
Sr. Programmer Analyst


On Wed, Dec 18, 2013 at 3:55 PM, D*B <dieter.bender@xxxxxxxxxxxx> wrote:

<Jeff>
One of the major issues using commitment control is the release of record
locks (ALL) when issuing a COMMIT operation.
Take a legacy job where a pgm gets the company master at the start of
processing, processes all details, *then* updates the company master with
the totals. (not a good design, but I *have* seen this). Now, that pgm
calls other pgms, one of which issues a COMMIT at the end of the processing
for a control group. (the pgmr did not know about the first pgm). ALL
record locks released, then pgm 1 fails on update!
Perhaps using different AG's *might* fix this, but ideally, the entire
application would be in the same AG.
</Jeff>

... in this scenario without commitment controll the record lock would be
released earlier, with the update and a second triy to update would fail
anyway. Go back and think about your design. I'm rather unsure, wether your
applications are rock solid!
Why don't you young guys not want to understand, that programmers life
would be much easier using commitment controll???

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