Record storage management in extended run-units

Products

IDMS IDMS - Database

Issue/Introduction

When multiple IDMS programs (or dialogs) are used to complete a single unit of work, there will often be a need to pass currency for records between those programs. When this is done, it creates what is called an extended run-unit.

Run-units can be extended in IDMS between one upper-level (calling) program and a lower-level (subordinate) program in some situations. When this is done, specific considerations apply to how storage is allocated and managed for records accessed by the run-units.

Environment

Release: All supported releases.

Resolution

There are two ways to successfully access records in a subordinate program when the calling (higher-level or mainline) program has extended the run-unit:

Bind the records in the upper-level program; pass the records from the upper-level program to the lower by specifying them as parameters on the call; and include them in the linkage section and procedure division using clause (if COBOL) of the subroutine.
Have the subordinate program issue BINDs for records it will retrieve.

These two approaches are mutually exclusive. One approach or the other should be implemented between two programs, but not both.

For up-to-date syntax examples on how to code these options, refer to the latest example of syntax for the BIND and other statements in the IDMS DML Reference COBOL manual.

There are additional questions to consider here as well.

If a record RecZ is modified in calling ProgA and a COMMIT is not done, if an OBTAIN RECZ is done in called ProgB, are the changes made in ProgA still in the record as ProgB sees it?

A: In a more generic situation, without an extended run-unit, this depends on a few variables. When ProgA performs an UPDATE and not a COMMIT, then calls ProgB, ProgA still retains an exclusive lock on the record occurrence which it updated. If ProgB opens a separate run-unit, it will then not be able to retrieve that record occurrence unless it is running in a transient read isolation level (READY AREA RETRIEVAL with sysgen parm RETRIEVAL NOLOCK). The only exception to this when two run-units are involved, even via CICS, is when they have transaction sharing turned on. Then there will not be lock conflicts between the two run-units, but care must be taken in sharing the locks. In this case, you have passed subschema-control and extended the run-unit from ProgA to ProgB. In that case ProgB is sharing the run-unit of PROGA. So when it issues an OBTAIN it should read the record from the buffer and get the version of RecZ with the changes made by PROGA. Since they share the run-unit, either ProgA or ProgB could issue a COMMIT or a ROLLBACK. If the record is not committed by either one, then any changes made by either ProgA or ProgB would be lost.

When the control goes back to the calling PROGA, is the record still bound or does a new BIND need to be done?

A: IDMS can only have one address at a time bound for any record type. A BIND RECORD command does not allocate any storage for the program. The command passes an address to IDMS that the program is responsible for acquiring. When ProgA binds a record and updates an occurrence then extends the run-unit to another program (ProgB), an OBTAIN issued by ProgB will get the updated view of the record but it will be returned to ProgA's storage if ProgB did not bind its own storage location before issuing the OBTAIN. If ProgB did issue its own BIND RECORD then that program's storage location is now the only address IDMS knows about for the record type. When control goes back to ProgA IDMS remains bound to ProgB's storage location unless or until ProgA issues another BIND RECORD for the record type. If ProgB's storage gets freed but ProgA issues another OBTAIN it can lead to corrupted storage within CICS (or within the CV if the programs are part of a DC task).

So in a case where the initial BIND of a record is done in the subroutine ProgB, then ProgA MUST re-issue a BIND on the record in order to access it. In addition, if ProgB has made any updates, ProgA will need to re-OBTAIN the record in order to see those updates.

Because this is rather complex, most sites simply pass the records along with the subschema-control when extending the run-unit, to avoid any confusion or storage corruption.