The daily edition.

1. Capability Overview

In traditional mainframe rehosting and deployment, an Enterprise Server instance (known as a region) is scaled vertically ("scale-up") by adding CPU cores, memory, or vCPUs to the hosting machine. However, vertical scaling exhibits non-linear returns and leaves the single region as a Single Point of Failure (SPOF).

Rocket Enterprise Server addresses this limitation through Performance and Availability Clusters (PACs). A PAC binds multiple distributed Enterprise Server regions across nodes into a single logical entity, delivering near-linear horizontal scaling, workload distribution, and active-active high availability for online transactions (CICS/IMS) and batch jobs (JCL).

2. Architecture & How It Works

• Single System Image (SSI) via PSOR: A PAC relies on a central in-memory/NoSQL data store called the PAC Scale-Out Repository (PSOR)—typically backed by Redis or Oracle Coherence. The PSOR acts as the cluster coordination backbone (PAC Scale-Out Repository (PSOR)). It synchronizes:
  • Resource definitions and transaction routing metadata.
  • JCL job submission, queue scheduling, and execution state across regions (Mandatory: Region Availability).
  • Cluster-wide lock management (ENQ/DEQ recovery) and cross-region file open/close states.
  • CICS NEWCOPY and phase-in requests to deploy updated load modules across all member regions simultaneously.
• Selective User-Data Scaling (SOR Models): Beyond system metadata in the PSOR, supplementary Scale-Out Repositories (SORs) handle shared application state. Administrators use SOR Models to selectively route non-recoverable Temporary Storage (TS) and Transient Data (TD) queues to the SOR while keeping local, node-specific queues on the host to minimize network latency (Scale-Out Repository (SOR)).
• Eliminating Storage SPOFs with Database File Handler (DBFH): Replicating flat VSAM files across disks can propagate file corruptions if an I/O split occurs during multi-step updates. Rocket Enterprise Server enables storing VSAM datasets directly within an RDBMS (such as Db2, Oracle, or SQL Server) via the Database File Handler (DBFH), providing relational ACID guarantees and multi-region concurrency for transactional data (Performance Availability Clusters (PACs) Requirements).

3. Practical Configuration & Operational Tidbits

1. Shared CSD in RDBMS: To guarantee consistent resource definitions across the PAC without manual file synchronization, configure the CICS System Definition file (dfhdrdat) inside the relational DATASTORE using an sql:// URI prefix rather than a local disk path (PAC Best Practices).
2. Cluster Administration via caspac: Always use the dedicated caspac command-line utility to initialize, modify, or clean cluster records in the SOR/PSOR. Direct manual edits to the underlying Redis keys bypass internal versioning and state validation (PAC Best Practices).
3. Region Identity in the System Initialization Table (SIT): While all regions in a PAC share the same basic SIT parameters and startup lists, each region must be provisioned with a unique APPLID (which functions as the node netname) and SYSID for inter-system communication (ISC) (PAC Best Practices).
4. Configuration Interface: The recommended way to register the PSOR and configure PAC topology is through ESCWA (Enterprise Server Common Web Administration) under Operation > SORs, pointing to your Redis cluster endpoint (e.g., localhost:6379) (Configuring the PSOR in ESCWA).

4. Reference Citations (Rocket Enterprise Server 12.0 Manuals)

• Performance and Availability Clusters Rationale — Enterprise Server 12.0 for UNIX
• PAC Scale-Out Repository (PSOR) — Enterprise Server 12.0 for UNIX
• Scale-Out Repository (SOR) — Enterprise Server 12.0 for UNIX
• Mandatory: Region Availability — Enterprise Server 12.0 for UNIX
• Configuring the PSOR in ESCWA — Enterprise Server 12.0 for UNIX
• PAC Best Practices — Enterprise Server 12.0 for UNIX
• Performance Availability Clusters (PACs) Requirements — Enterprise Server 12.0 for UNIX