Re: Fw: Change commitment control after compilation

[Jeff Young <jyoung0950@xxxxxxxxx>]

*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.