How You Define CTC Devices for Use in VCF Environments

Advanced Topics › How You Define CTC Devices for Use in VCF Environments

How You Define CTC Devices for Use in VCF Environments

The CTCPATH statement identifies the CTC device addresses used to transport the VCF from the master system to the client systems. As of Version 12.0, the CTCPATH statements are valid for all communication methods. Activating COMPATLEVEL=12.0 lets other communication methods use CTCPATH statements.

Conceptually, a CTC device connects an I/O address on one processor to an I/O address on another processor. VCF data that is sent from one side is received on the other side, so every transmission consists of two operations: an outbound write operation from one side, and an inbound read operation on the other side. Data may be transmitted in either direction over a CTC path, but it travels in only one direction at any one moment.

The following information describes how you implement the CTCPATH statement:

Place the CTCPATH statements in the MIMINIT member of the CA MIM parmlib.
Make the CTCPATH statements in the MIMINIT member the same on all systems.
Do not place the CTCPATH statements in IFSYS/ENDIF blocks.
During the initialization, the defined device addresses are allocated and made available for use exclusively by CA MIM.

The following information describes how you implement the CTCPATH command:

Issue the CTCPATH command dynamically as CA MIM is executing.
Issue the CTCPATH command before or after CA MIM is synchronized.
You can use the CTCPATH command to make a system master eligible. From the master eligible system, add paths to every known system and from every known system add paths to the master eligible system.

The CTCPATH statement has the following parameters:

ADDRESS = (primaddr, altaddr1, ... altaddrn)
The ADDRESS parameter defines the CTC device addresses used to communicate in an outbound fashion from the system indicated in the FROMSYSTEM parameter. At least one primary address must be specified. The alternate addresses are used in recovery situations.
FROMSYSTEM = system name
(Optional) Identifies the originating system for the path. This system sends the VCF in an outbound fashion on this path.

Note: FROMSYSTEM is an optional parameter that defaults to the local system.
TOSYSTEM = system name
(Optional) Identifies the destination system for the path. This system receives the VCF in an inbound fashion on this path.

Note: TOSYSTEM is an optional parameter. Omitting TOSYSTEM causes CA MIM to discover connections as the initial communication completes.

Examples

CA MIM sends data in both directions from the master to each client system. One path is required from the master to each client system. Two CTCPATH statements are used to define the path from the master to the client, and from the client to the master. The following figure illustrates this concept:
```
CTCPATH FROMSYSTEM=SYSA ADDRESS=9FC TOSYSTEM=SYSB
CTCPATH FROMSYSTEM=SYSB ADDRESS=7FC TOSYSTEM=SYSA
```
You would place the preceding CTCPATH statements in the MIMINIT member to represent this configuration.
The following figure illustrates the use of alternate CTC addresses for use in recovery situations:
```
CTCPATH FROMSYSTEM=SYSA ADDRESS=(9FC,AFC) TOSYSTEM=SYSB
CTCPATH FROMSYSTEM=SYSB ADDRESS=(7FC,8FC) TOSYSTEM=SYSA
```
You would place the previous CTCPATH statements in the MIMINIT member to represent this configuration.

In this example, 9FC/7FC is the primary path, and AFC/8FC is the alternate path. The alternate path is used only when a problem is detected with the primary path. The alternate paths do not provide any performance advantages in terms of load sharing. They are for backup purposes only. Up to 15 alternate paths can be defined between any two systems. The total number of required CTCPATH statements depends on the number of defined systems in the MIMplex and whether the configuration is symmetrical or asymmetrical. We recommend symmetrical configurations because full redundancy provides the best recovery options. Master system recoverability is important in CTCONLY environments.
A symmetrical configuration provides greater flexibility because the systems are connected to each other. Then, all systems are considered eligible masters. The following figure illustrates a symmetrical configuration in which all three systems are considered eligible masters:
```
CTCPATH FROMSYSTEM=SYSA ADDRESS=8C3 TOSYSTEM=SYSB
CTCPATH FROMSYSTEM=SYSB ADDRESS=2C3 TOSYSTEM=SYSA
CTCPATH FROMSYSTEM=SYSB ADDRESS=2C8 TOSYSTEM=SYSC
CTCPATH FROMSYSTEM=SYSC ADDRESS=7C8 TOSYSTEM=SYSB
CTCPATH FROMSYSTEM=SYSC ADDRESS=8C4 TOSYSTEM=SYSA
CTCPATH FROMSYSTEM=SYSA ADDRESS=8C4 TOSYSTEM=SYSC
```
You would place the preceding CTCPATH statements in the MIMINIT member to represent this configuration.
In an asymmetrical configuration, systems are not connected to each other. At least one system is connected to every other system in the MIMplex. The following figure illustrates an asymmetrical configuration in which SYSC is the only eligible master.
```
CTCPATH FROMSYSTEM=SYSA ADDRRSS=8C4 TOSYSTEM=SYSC
CTCPATH FROMSYSTEM=SYSC ADDRRSS=8C4 TOSYSTEM=SYSA
CTCPATH FROMSYSTEM=SYSB ADDRRSS=2C8 TOSYSTEM=SYSC
CTCPATH FROMSYSTEM=SYSC ADDRRSS=7C8 TOSYSTEM=SYSB
CTCPATH FROMSYSTEM=SYSD ADDRRSS=520 TOSYSTEM=SYSC
CTCPATH FROMSYSTEM=SYSC ADDRRSS=720 TOSYSTEM=SYSD
```
The preceding CTCPATH statements are placed in the MIMINIT member to represent this configuration.
You can omit the TOSYSTEM operand on the CTCPATH statement, which lets CA MIM discover connections as the initial communication occurs.
Note: By omitting the TOSYSTEM operand, master eligibility is unable to be determined at initialization time. Without TOSYSTEM specified, CA MIM cannot determine connections. However, as the initial communication occurs, CA MIM reevaluates the master eligibility and notifies you of the changes.

Complete CTCPATH Statements:
```
CTCPATH FROMSYSTEM=SYSA ADDRESS=8C3 TOSYSTEM=SYSB
CTCPATH FROMSYSTEM=SYSB ADDRESS=2C3 TOSYSTEM=SYSA
CTCPATH FROMSYSTEM=SYSB ADDRESS=2C8 TOSYSTEM=SYSC
CTCPATH FROMSYSTEM=SYSC ADDRESS=7C8 TOSYSTEM=SYSB
CTCPATH FROMSYSTEM=SYSC ADDRESS=8C4 TOSYSTEM=SYSA
CTCPATH FROMSYSTEM=SYSA ADDRESS=8C4 TOSYSTEM=SYSC
```
Removing the TOSYSTEM operand reduces the CTCPATH statements:
```
CTCPATH FROMSYSTEM=SYSA ADDRESS=(8C3,8C4) 
CTCPATH FROMSYSTEM=SYSB ADDRESS=(2C3,2C8) 
CTCPATH FROMSYSTEM=SYSC ADDRESS=(7C8,8C4) 
```
During the initialization, CA MIM initiates the communication on every locally defined CTC. For example, on SYSA CA MIM initiates communications on devices 8C3 and 8C4. As external systems respond to the communications on 8C3 and 8C4, CA MIM completes its internal representation of that path by filling in the destination systems name. As the connections are completed, CA MIM reevaluates the local systems master eligibility and notifies external systems if the local system becomes master eligible.

Note: CA MIM cannot synchronize until an eligible master is available. By removing the TOSYSTEM operand, CA MIM is unaware of eligible masters before initial communications complete. Therefore, CA MIM cannot synchronize and remains in a PENDING state. Issue the DISPLAY SYSTEMS command to identify any systems that are preventing CA MIM from starting. If NOPATH is specified, issue a FREE command to clear the NOPATH status and CA MIM then ignores that system during master eligibility evaluations. However, when doing a format start, CA MIM always honors the FREE status that is specified on the DEFSYS statements.
You can issue the dynamic CTCPATH command to add new connections between systems or add alternate CTC devices for existing connections.
The master eligibility can change when you add connections. For example, assume SYSA, SYSB, SYSC, and SYSD are connected in the following fashion:

Dynamically adding paths from SYSA to SYSB and SYSD makes SYSA the master eligible connection.

Note: Dynamically adding a path on SYSA and SYSB creates a fully functional connection.

Virtual Control File Sizing Considerations

The VCF size is a mirror image of the primary backup DASD control file when the CA MIM complex executes in a mixed CTC and DASD environment.

The VCF image contains the same number of blocks (of size MIMINIT BLKSIZE), as the primary backup DASD control file. The primary backup DASD control file is defined as the DASD control file that was in use when the migration to the VCF took place. CA MIM supports up to 100 DASD control files. We recommend that alternate DASD control files be progressively larger in size than the primary control file. When the primary DASD control file or the VCF becomes full, a migration to a larger alternate DASD control file is successful. The larger alternate DASD control file yields an equally larger size VCF when compared to the original DASD control file size.

When running in a VCF-only environment (that is, MIMINIT COMMUNICATION=CTCONLY or MIMINIT COMMUNICATION=XCF), the VCF image size is dynamic.

VCF sizing:

Determine the initial VCF size by multiplying the MIMINIT BLKSIZE specification by the MIMINIT VCFMAXBLOCKS specification.
When the VCF image size needs increased, the detecting system expands the VCF dynamically.
As each external system accesses the VCF, the system detects that the VCF has been expanded and begins operating with the increased file size.
Depending upon the MIMINIT BLKSIZE specification, the VCF image can expand to a maximum of 2 GB.