At the core of a
Performance and Availability Cluster (PAC) are the regions, a
PAC can contain two or more regions
- These regions can be distributed across hardware to improve PAC resilience.
- All participating regions must be the same bitism, on the same OS and version, and have the same product version installed.
Note: Micro Focus recommends that you create a PAC with at least three regions. This enables instances within the PAC to be temporarily suspended
for maintenance without compromising the availability of the PAC.
The
PAC Scale-Out Repository (PSOR) enables the PAC to be administered and operated as a single system image:
- Synchronization of key CICS and system resource definitions. See
CICS Resources section in the
Supported Configurations topic for more information.
- Providing operational support for JCL job submission, scheduling, monitoring, and control.
- Abstraction of where Jobs are run.
- Reply and job kill capabilities.
- Recovery processes, such as release ENQs, closing, and database hosted files left open.
- Mechanisms to update and deploy new load modules using CICS NEWCOPY and JCL batch.
Note: A PAC must have only one PSOR.
The following are examples of how a Scale-Out Repository (Scale-Out Repository (SOR)) reduces the administrative burden and minimizes the risks that might normally be part of managing a scale-out configuration
of
enterprise server instances:
- Switching from online to batch; without the SOR, as the CICS application starts in each region, the FCTs for the files it
uses will be marked as open. Switching to batch would require the administrator to go to each region in turn and perform an
FCT close on the file. With the SOR, the first region to run the CICS application would mark the file open in the FCT and
the SOR will apply this to all the instances in the PAC. To switch to batch, the administrator simply goes to any single instance
in the PAC, close the FCT, and the action will be applied for all instances in the PAC.
- Administering a batch job; if a batch job is submitted to any
enterprise server instance in a PAC where the PAC is sharing a catalog and spool files. The job gets added to the queues and the first
enterprise server instance in the PAC available to submit that job will pick it up. The job might run on a different
enterprise server instance than the one it was submitted on. If you wanted to administer that job without the SOR, you would need to go to each
enterprise server instance, in turn, to determine which one was running that Job. With the SOR, the job can be administered from any region in the PAC.
- Updating a library used across the PAC; without the PAC, the administrator would need to go to each
enterprise server instance, in turn, and install the library. With the SOR, the library can be loaded into the SOR which will then manage its publication
to all the
enterprise server instance in the PAC.
Note: Over time as more capabilities are added to the PAC, then more supporting actions will be added to the function of the SOR
to minimize administration requirements.