A program (or table) that CICS loads in response to a LOAD PROGRAM HOLD command remains in directly addressable storage until explicitly released by the same, or by a different, task.
Any CICS tasks that run while the loaded program (table) is held
in storage can use the loaded program's storage to exchange data, if:
- The program is not loaded into read-only storage, or
- The program is not defined to CICS with RELOAD(YES)
Although you could use a temporary storage queue to make the address of the loaded program's storage available to other tasks, the more typical method would be for other tasks to issue a LOAD PROGRAM command also, with the SET(ptr_ref) option so that CICS can return the address of the held program.
The nature of the affinity caused by the use of the LOAD PROGRAM
HOLD command is identical to that caused by the use of GETMAIN SHARED
storage (see Figure 1 and Figure 1), and the same rule applies: to preserve
the application design, the dynamic or distributed routing program
must ensure that all transactions that use the address of the loaded
program (or table) are routed to the same target region.
Figure 1. Illustration of inter-transaction affinity created
by use of LOAD PROGRAM HOLD. The dynamic routing program
needs to be aware of this affinity, and ensure that it routes TRN2
to the same target region as TRN1.
Note: This rule applies also to programs defined with the RESIDENT
option on the resource definition for the loaded program (whether
the HOLD option is specified on the LOAD command). However, regardless
of affinity considerations, it is unsafe to use the RESIDENT option
to enable transactions to share data, because programs defined with
RESIDENT are subject to SET PROGRAM(program_name) NEWCOPY commands,
and can therefore be changed.
The rule also applies to a non-resident, non-held, loaded program where the communicating tasks are synchronized.
