DFSMStvs Application Migration Guide

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.