CICS Intersystem Communication (ISC) & Distributed Processing
Large-scale mainframe transactional systems often partition workloads across multiple specialized CICS regions—such as Terminal Owning Regions (TOR), Application Owning Regions (AOR), and File Owning Regions (FOR)—or connect distributed applications back to centralized z/OS mainframes. [1]
Read the full briefing
1. Capability Overview
Large-scale mainframe transactional systems often partition workloads across multiple specialized CICS regions—such as Terminal Owning Regions (TOR), Application Owning Regions (AOR), and File Owning Regions (FOR)—or connect distributed applications back to centralized z/OS mainframes.
Rocket Enterprise Server provides complete Intersystem Communication (ISC) within its Mainframe Subsystem Support (MSS) architecture. ISC enables distributed processing split across multiple Enterprise Server regions (MSS-to-MSS) as well as bidirectional communication between open systems and host IBM z/OS CICS regions (MSS-to-mainframe) via TCP/IP and Rocket Mainframe Access (Intersystem Communication, Supported Link Types).
2. Architecture & The Core Distributed Facilities
Rocket Enterprise Server implements the four standard distributed transaction processing models (Intersystem Communication):
- Distributed Program Linking (DPL): Allows a COBOL application running on Enterprise Server to issue an
EXEC CICS LINK PROGRAM(...) SYSID(...)call to execute a program residing on a remote region (Distributed Program Linking). A shared communication area (COMMAREA) or channel/container is transferred over the wire, providing a straightforward mechanism to invoke business logic or access remote DL/I (IMS) and SQL databases on host CICS without migrating datasets. - Transaction Routing: Permits a 3270 terminal attached to an initiating region (TOR) to run transactions that execute on a remote target region (AOR) (Restrictions on Transaction Routing). Users can route sessions interactively using the built-in routing transaction
CRTE SYSID=<target>(Testing Inbound Transaction Routing from the Host). - Function Shipping: Enables programs to access remote resources transparently. Standard file control commands (
READ,WRITE), temporary storage requests (WRITEQ TS), and transient data queues (WRITEQ TD) that reference remote system definitions in the CICS System Definition (CSD) table are intercepted and shipped across network links to the remote region for execution (Intersystem Communication). - Asynchronous Processing & START Routing: Allows a local program to trigger asynchronous background transactions on a remote system via
EXEC CICS START TRANSID(...) SYSID(...)without waiting for the remote transaction to return a response payload (Intersystem Communication).
3. Practical Configuration & Operational Tidbits
- Service Listeners for Inbound Links: To accept incoming ISC requests from other regions or mainframe systems, the Enterprise Server region must configure an active Service Listener bound to a designated network endpoint (To Add a Service Listener to an Enterprise Server Region). In ESCWA, listeners are provisioned under
[Region] > Listenersspecifying communication handlers such asmfcsortn3270. - System Identifiers and Connection Definitions: Both participating systems require matching CSD definitions. In the local region, administrators create a
CONNECTIONentry specifying the remote system ID (SYSID), netname, and protocol parameters, paired withSESSIONentries specifying the maximum number of concurrent sessions (Bidirectional MSS-to-mainframe Example). - Terminal Routing Id Constraints: Terminal IDs must remain unique within a CICS region estate. When transaction routing is active in one direction, routing back to your initiating terminal is rejected by the runtime engine because duplicate terminal IDs cannot be registered simultaneously on host and client systems (Testing Inbound Transaction Routing from the Host).
- Identity Propagation & Passtoken Security: When routing transactions across ISC boundaries, user identity can be verified seamlessly using encrypted passtokens. In high-security environments, administrators can disable passtokens in the ESF Manager configuration within the Directory Server repository to mandate that users explicitly authenticate across security domain borders (Typical Passtoken Configurations).
4. Reference Citations (Rocket Enterprise Server 12.0 Manuals)
- Intersystem Communication — Enterprise Server 12.0 for UNIX
- Distributed Program Linking — Enterprise Server 12.0 for UNIX
- To Add a Service Listener to an Enterprise Server Region — Enterprise Server 12.0 for UNIX
- Testing Inbound Transaction Routing from the Host — Enterprise Server 12.0 for UNIX
- Restrictions on Transaction Routing — Enterprise Server 12.0 for UNIX
- Bidirectional MSS-to-mainframe Example — Enterprise Server 12.0 for UNIX
- Supported Link Types — Enterprise Server 12.0 for UNIX
- Typical Passtoken Configurations — Enterprise Server 12.0 for UNIX