quasi-reentrant.html |
Last updated: Thursday, 27 June 2019Before the open transaction environment was implemented in CICS®, all CICS tasks running user applications ran on the QR TCB. The tasks were given control by the CICS dispatcher, which dispatched use of the TCB between the tasks. Programs running on the QR TCB are called quasi-reentrant.
A quasi-reentrant program is a program that is in a consistent state when control is passed to it, both on entry, and before and after each EXEC CICS command. Such quasi-reentrancy guarantees that each invocation of an application program is unaffected by previous runs, or by concurrent multithreading through the program by multiple CICS tasks.
CICS runs user programs under a CICS-managed task control block (TCB). If your programs are defined as quasi-reentrant (on the CONCURRENCY attribute of the program resource definition), CICS always invokes them under the CICS quasi-reentrant (QR TCB). The requirements for a quasi-reentrant program in a multithreading context are less stringent than if the program were to run concurrently on multiple TCBs.
CICS requires
that an application program is reentrant so that it guarantees consistent
conditions. In practice, an application program might not be truly
reentrant; CICS expects quasi-reentrancy
.
For example, application programs could modify their executable code, or the variables defined within the program storage, but these changes must be undone, or the code and variables reinitialized, before there is any possibility of the task losing control and another task running the same program.
CICS quasi-reentrant
user programs (application programs, user-replaceable modules, global
user exits, and task-related user exits) are given control by the CICS dispatcher under the QR TCB.
When running under this TCB, a program can be sure that no other
quasi-reentrant program can run until it relinquishes control during
a CICS request, at which point
the user task is suspended, leaving the program still in use
. The
same program can then be reinvoked for another task, which means the
application program can be in use concurrently by more than one task,
although only one task at a time can be running.
To ensure that programs cannot interfere with each other's working storage, CICS obtains a separate copy of working storage every time an application program runs. For example, if a user application program is being used by 11 user tasks, there are 11 copies of working storage in the appropriate dynamic storage area (DSA).
Quasi-reentrancy allows programs to access globally shared resources, for example the CICS common work area (CWA), without the need to protect those resources from concurrent access by other programs. Such resources are effectively locked exclusively to the running program, until it issues its next CICS request. For example, an application can update a field in the CWA without using compare and swap (CS) instructions or locking (enqueuing on) the resource.
Take care if a program involves lengthy calculations: because an application program retains control from one EXEC CICS command to the next, the processing of other transactions on the QR TCB is excluded. However, you can use the task-control SUSPEND command to allow other transaction processing to proceed; see Task control for details. Runaway task time interval is controlled by the transaction definition and the system initialization parameter ICVR. CICS purges a task that does not return control before expiry of the specified interval.
Last updated: Thursday, 27 June 2019