74 DFSMStvs Application Migration Guide
take any action to recover from a retained lock; the cause of the retained locks
must be identified and corrected externally to the program before rerunning.
Figure 6-7 Processing deadlocks in COBOL
If you compare this with the processing for PL/I shown in 7.4, “Step 2: Check for
deadlocks and time-outs” on page 91, you will see that COBOL gives us the
VSAM-generated return code and reason code directly so that it is simple to
check. Note that there are many unique combinations of return code and reason
code; we have only shown two for the sake of brevity.
The program is still usable, but could cause lock contention and unnecessary
coupling facility use, because it does not issue any commit calls.
6.5 Step 3: Add commit and backout logic
We decided to add commit and backout logic in this way:
1. We introduced a parameter file to allow us to change the number of master
file updates between commits. We did this because we wanted to experiment
with the number of commits. We also thought that it would be better to be able
to change the commit frequency outside the program, rather than having to
re-compile to do so.
The code that we added is shown in Figure 6-8 on page 76. We define the
parameter file as a sequential file and open it for input. We read the first
record and use the first eight bytes as the number of updates allowed
between commits.
Write MASTER-RECORD
Invalid key Display "Cannot add key " INPUT-KEY
End-Write
If MASTER-FILE-STATUS not = "00"
Move "failed" to ADD-STATUS
Perform 0100-DISPLAY-VSAM-ERROR
Evaluate VSAM-RETURN-CODE also VSAM-FEEDBACK-CODE
When 8 also 15
Display "Deadlock detected"
When 8 also 16
Display "Request timed out"
End-evaluate
Else
Add 1 to UPDATE-COUNT
End-If
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.

Get DFSMStvs Application Migration Guide now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.