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 in
Using GETMAIN SHARED storage 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.
