Re: Change commitment control after compilation

<Buck>
This stuff is static - no real changes for 10 or 20 or 30 years.
</Buck>

That would never make a problem, if it works and nobody needs to have a look to it! It will become a problem, if this leeds to writing the new stuff looking like this old stuff.

<Buck>
So what gets changed? The database stays mostly the same - employee
master, payroll time cards, many work files and some EOM, EOQ, EOY
accumulators. A column gets added for task, and a few new reports are
written. A new program is written to convert the new swipe card data
format into the old time card file layout, with the new task column
being updated too. In this way, a new business function is added with
very little change to the payroll application as a whole.
</Buck>

I would think about adding some exit points with well defined interfaces, so that new functionality could be integrated without only having a look to the old programms! The changing parts have to be separated from the "static" parts, needing noc change.

<Buck>
It wasn't a design choice, as much as that is how it slowly grew.
</Buck>

We hope that software grews, mostly this is the ways software shrinks.

<Buck>
The big problem with commitment control is that the life of a
'transaction' can be very long - multiple programs over multiple days.
</Buck>

Commitment Controll is just a technique to ensure that the contents of the database is following some rules - the idea behind this is: lost data integrity often is the starting point for further more severe errors in a software system. Commitment controll gives a chance to ensure, that a whole bunch of actions is done completely or completely not. In the last case it could be redone after solving the originating problem, without having to repair the data (mostly this task is error prone). In your case, first step would be to me to journal all tables and worktables (as not done yet) to get mor information for data repair. My second step would be to write some checking routines, checking the consistency of the critical tables, to recognize problems before they are arising. Third step would be to prepare the most critical porgramms for error recovery. Initial version could be to have a job save, run the programm check data, in case of problems save the produced data and restore the before status. This would be some sort of "commitment controll" with rather big transactions. If this is not sufficient (because too much data is resetted), next step would be to break the process in parts (could be data segments) and to automate the process.

In your scenario the main problem is not using commitment control, but seperating the old stuff from the stuff needed to be changed. This is very diffrent from the starting point of discussion, talking about programms using embedded SQL, if such programms write data, commitment controll is a must have, in your case maybe nice to have.

Dieter