Previous Topic: The Effects of Control CommandsNext Topic: Longterm Locks


Extended Run Units

Typically, an CA ADS run unit begins when the dialog issues a command accessing the database (for example, OBTAIN) and ends when the runtime system encounters the next control command issued by the dialog (that is, LINK, INVOKE, DISPLAY, TRANSFER, LEAVE, or RETURN).

An extended run unit is a run unit that is kept open when the runtime system encounters the LINK command under the following circumstances:

  1. When the LINK is to the premap process of a dialog with no associated subschema
  2. When the LINK is to the premap process of a dialog with an associated schema and subschema identical to those of the calling dialog
  3. When the LINK is to a user program

Implications of the extended run unit are as follows:

  1. Currencies are passed to the lower-level dialog and are restored upon return to the upper-level dialog.
  2. Currencies are not passed to user programs; currencies are saved and restored to the upper-level dialog when control is returned.
  3. The lower-level dialog can perform error checking to decide whether to issue a ROLLBACK command.
  4. Because a FINISH is not issued, record locks held by the upper-level dialog are not released. A COMMIT can be coded in the upper-level dialog if the developer needs to release locks before linking to the lower-level dialog.
  5. If a COMMIT is issued prior to the LINK command and an abend occurs in the lower-level dialog, the rollback will be incomplete; the rollback will only go to the COMMIT checkpoint and not to the start of the run unit.
  6. If a lower-level user program opens its own run unit, a deadlock can occur. The possibility of a deadlock condition can be avoided by taking either of the following actions:
    1. Issue a COMMIT prior to the LINK.
    2. Pass the subschema control block to the user program and let the program use the same run unit. Issue no BINDs or FINISHes in the user program.