Re: Change commitment control after compilation

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