Re: Change commitment control after compilation

On 12/19/2013 11:16 AM, D*B wrote:

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

This is a good point!

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

My example used L1 as the transaction boundary. To be clear about it,
that means that an unknown number of detail cycles were processed before
the transaction cycle was ROLLBACKed. Totals accumulated for a report
will not be rolled back; only the disk records. This requires that some
analysis be made to find these fields and move them from the detail
cycle to the commit boundary (L1 total time).

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.

Aside from issues of keeping batches separate, this is a good approach.

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

This is the struggle we all face, I think. Some bosses will accept the
judgement of her programmers and some are not as understanding. I try
to do some refactoring in every program I touch; especially if I can
generate test cases to cover the changes.
--buck