Re: Change commitment control after compilation -- RPG400-L

Dieter

First of all you are outnumbered since 99 % of RPGLE code still uses RLA.

Besides that RLA (cleverly done) can do stuff that COMMIT never can do
since you can lock a record while doing some processing before you update
it and if you have a set of transactions you can lock their master record
while the transactions are being processed.

Thereby RLA doesn’t need any ROOLBACK functionality since it by the master
record can own a transaction set during an update.

What neither RLA nor COMMIT handles is what I call data in transit, that
is, redundant data that resides in one or several buffers or in browsers
where you have to insure that the record/row hasn’t been updated by others
in the meantime if a user tries to update the record/row.

The most cost effective way to insure that is to have a record update
counter that is passed with the redundant data and then checked against the
actual value of the record/row before the update.

And don’t try to argue against that technique, I have never experienced
this technique to fail in more than 100 systems in 30 years! And BTW it
works both on RLA and SQL.

The bottom line is that RPGLE based systems has both techniques, RLA gives
you much more control than SQL so why not use the best technique available
for the job?

On Thu, Dec 19, 2013 at 5:16 PM, D*B <dieter.bender@xxxxxxxxxxxx> wrote:

... must have been another life before now, that I've used cycle and
strange things like this (and MR and...)...

@read, write commit - is this a transaction and needs commit or not?

it depends on the read methods you are using. using RLA (record level
access) or a cursor in SQL it could be done without Commitment controll,
but using select into and update where, it might not work as expected,
because the select into does not lock the record without commit, it could
be changed before you write and you would loose an update!

First conclusion: using SQL for updates without commitment controll is a
severe technical flaw.

Commitment controll does not only block records to one logical unit, it
enables fine grained record locking strategies!

@Input primary batch processes:

an input primary batch process is a classical example for a transaction:
one cycle is the transaction and at end of the cycle (calculations
included!), I would have to say commit, if all was ok and rollback
otherwise. Implementing this is rather easy! just set a flag (some people
call this indicator) doCommit to TRUE (some people call this *ON) at the
beginning and for every error situation to FALSE (some people are saying
*OFF) and at end of cycle you have a criterium to decide wether to commit
or to rollback. What to do with the rcord in the IP (transaction) file,
depends on the logic of your (maybe) three programms, coming after this:
could these programs continue, or do they need the work of the first? One
idea could be to move them to an error pool of died transactions, copying
these records back before a next run, they could be performed again.

@ROI of effort for redesign:

in one of my earlier lifes, I succeded to convince my boss to add 20% to
the estimated time to implement some changes, or fixes to an existing
programm for redesign. for example estimated 5 => adding redesign tasks for
estimated 1 day, such tasks could be: eliminate unused code, rename vars,
SRs to more meaningfull names, extract redundandent code to a procedure,
change srs to proceduresm or implement cc. This had had 2 effects: the
threshold to write the programm new, instead of doing greater changes in
this programm came a little bit down and programms needing many fixes
(caused by instability) got many redesign tasks and became more stable with
each fix. The total effort for changes and fixes increased 20% at startup,
but decreased within 1 year, caused by better and more stable programms.

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