Chapter 6. Migrating a COBOL program 75
If the file is not present, we assume a default value of one for the commit
interval. After some testing, we now know that this is not a good default, and
we would set it to 100 as a compromise between the cost of committing and
the frequency of committing.
2. Next we count the number of successful updates and, when enough updates
have been done to match the parameter specified, we call a commit
procedure. This is shown in Figure 6-9 on page 77.
3. In the commit procedure, shown in Figure 6-10 on page 78, we request a
commit and check the return code. If the commit has not completed
successfully, we try to back out and then end the program.
We also added logic at the end of the program to perform a final commit before
closing the files even though there is an implicit commit at the end of the
program. If our program issues the commit call, it can interpret any return codes
and possibly act upon them. More importantly, issuing explicit commits avoids a
potential problem: an implicit commit is done, by definition, at the end of a step
after the application has closed its files normally.
There is a short window of time between the close and the implicit commit when
locks are still held and are retained locks. So, if another application requests a
locked record, it sees a retained lock and will probably have to fail rather than
seeing a held lock, for which the program will wait. Interestingly, the problem is
also avoided by not closing files within the program, but by letting task
termination close the files and commit the last unit of recovery.
To summarize, it is best to commit and close explicitly, and it is acceptable to do
neither. If you close explicitly but fail to commit the last unit of recovery, you may
get retained locks.
We were able to introduce the commit logic simply by counting updates because
we have independent updates, by which we mean that each input record in the
input transaction file describes one transaction and a transaction is completely
described by one input record — there is a one-to-one correspondence between
input records and transactions. If the updates were
not independent, or if an input
record represents a business transaction requiring updates of multiple files, we
would have to ensure that we commit or back out on a transaction boundary (see
Figure 6-8 on page 76).
Warning: The program should not be used at this stage. If there are no
problems, it will complete correctly. However, we have lost the ability to rerun
without reviewing the output and altering the input data. We will address this in
the next step.