CA ADS Runtime System › CA ADS Tasks, Run Units, and Transactions › Extended Run Units

Extended Run Units

A run unit is kept open (extended) when a dialog passes control to another dialog, user program, or application function by using an INVOKE, LINK, TRANSFER, or EXECUTE NEXT FUNCTION command.

A run unit is extended when control passes to any one of the following:

• A user program.

  If a run unit is not already open and the LINK command's USING RECORDS list includes SUBSCHEMA-CONTROL, CA ADS opens and extends a run unit. If the run unit is already open, the run unit is extended.

• A dialog with a premap process and no associated subschema.
• A dialog with a premap process whose schema and subschema are the same as those of the issuing dialog and whose usage modes are equally or less restrictive than those of the linking dialog.

  A usage mode is considered more restrictive than another usage mode if either of its two components is more restrictive.

  The following table shows the relative restrictiveness of usage modes.

• Any lower-level dialog, provided that the USING SUBSCHEMA-CONTROL clause of the LINK command is used.

Considerations

The following considerations apply to extended run units:

• Rollback when a run unit is extended with the LINK command

  The LINK command does not automatically write a checkpoint to the CA IDMS/DB journal file. This allows a lower level dialog to check for errors and issue a ROLLBACK command if necessary. In this case, the entire extended run unit is rolled back.

  If a COMMIT command is included in either dialog, the dialog is rolled back only to the COMMIT checkpoint. In this case, the entire extended run unit is not rolled back.

• Adding an area to a dialog

  It is possible that the extended run unit will no longer be extended, if:

  • You add an area to one of the dialogs in an application thread (for example, when the record is migrated into a different area).

  and

  • Any of the dialogs are recompiled.

  A run unit that is no longer extended can have a serious impact on handling a potential ROLLBACK or abend. If the run unit is no longer extended, then recovery can be incomplete and can disrupt the integrity of the database. If such a change to the subschema occurs, we recommend comparing the original application run unit structure to the modified application run unit structure. For this comparison, use, for example, ADS TRACE=CTL or Journal Reports.

• Using default usage mode with the option FORCE

  We recommend not to use the subschema FORCE option for ADS applications with extended run units. Change the dialog code instead.

  Several problems can occur if you use the subschema FORCE option for ADS applications with extended run units. For example, if the dialog that needs a new area is the recipient of an extended run unit, the FORCE area is not READIED.

  Note: For more information on the limitations of using the FORCE option with ADS dialogs, see the Area Statement section (in the Subschema Statements chapter) in the CA IDMS Database Administration Guide.

• Runtime deadlocks
  • If a user program issues a subschema BIND followed by any database activity, the program can deadlock at runtime. To avoid this situation, a COMMIT command should be coded before a LINK to a user program that issues a BIND or FINISH command.

    It may be more efficient to remove subschema BIND and FINISH activities from the user program and allow the extended run unit to handle these functions. In this case, the issuing dialog must pass SUBSCHEMA-CONTROL to the program. Subschema records passed to the program must be bound only if the user program provides its own subschema record buffers. When control returns to CA ADS, the runtime system automatically rebinds the record buffers.

  • If a dialog issues non-SQL DML and SQL DML against the same non-SQL defined database at one time, deadlock of the run units is possible.
• Extending SQL transactions

  If a dialog links to a lower level dialog after beginning an SQL transaction (where the lower level dialog also issues SQL commands), the developer must either:

  1. Issue an SQL COMMIT WORK command before linking to the lower level dialog, or
  2. Compile the RCMs for the two dialogs into a single access module (AM).

  Choice one results in two units of recoverable work; choice two results in a single recoverable unit of work. When neither one or two are done, the SQL request of the lower level dialog fails, because its RCM information is not found in the active AM.

More information:

Control Commands