Re: Change commitment control after compilation

[Jeff Young <jyoung0950@xxxxxxxxx>]

D*B,
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 Young
Sr. Programmer Analyst


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

> @Buck: the first step is very easy:
> - give your new programms a named activationgroup COMMIT
> - if you issue a commit after each write and use all defaults it's working
> as before and the problem of the OP is gone!
> - starting from this point you could put some database operations
> together, completing all together (you've said commit), or all discarde
> (you've said rollback)
> - maybe your batch processe are workink like lots, I've seen, reading some
> workfiles, producing another and changing a flag, in the primary file to
> read => just put all operations for one record of the primary file to one
> transaction and you would have lots of benefit.
> - another effect will be, that you would have to start journaling to all
> files, giving you much more information what did really happen during the
> nightly batch, when you where lieing in your bed, sleeping, coming to the
> office next morning and your batch is sitting and waiting for you to answer
> soem inqiry message...
>
> <Buck>
> ... why not write...
> </Buck>
>
> reading some responses, I'm getting in these list, I'm thinking it might
> be a waste of time...
> but anyway, if you've some questions, I will try to answer.
>
> 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.