Having shared access to temporary storage data in this way avoids the need to function ship requests from multiple AORs to a QOR. Each AOR can reference shared temporary storage data via a temporary storage data sharing server in the same z/OS image. Shared temporary storage also helps remove potential temporary storage affinities when using local queues specific to particular CICS systems.
Access to a pool by CICS transactions running in an AOR is via a TS data sharing server that supports the named pool. Each z/OS image in the parallel sysplex requires one temporary storage data sharing server for each pool defined in a coupling facility accessible from that z/OS image.
Figure 1 shows a parallel sysplex environment with several CICS Terminal Owning Regions (TORs) and AORs, communicating with temporary storage data sharing servers in their z/OS image and accessing shared temporary storage data held on the coupling facility.
The Authorized Cross-Memory (AXM) Environment
The CICS data sharing servers use a common run-time environment. This is the AXM server environment; it provides necessary services the various servers can exploit. If CICS data sharing servers are to be used, the AXM system services must launch first. AXM system services are initialized via a z/OS subsystem definition called AXM. The subsystem interface isn’t activated or used; the definition enables scheduling of AXM initialization by the z/OS master scheduler, and so establishes AXM cross-memory connections for a given z/OS image.
The AXM subsystem may be defined both statically and dynamically. For static definitions, an entry may be added to the IEFSSN member of SYS1. PARMLIB as follows. This makes AXM services available when IPLing z/OS:
SUBSYS SUBNAME(AXM) INITRTN(AXMSI)
You can also initialize AXM system services with a dynamic subsystem definition: