Advanced Topics › How You Define Your VCF Master and Error Recovery Environment › How You Select Master Systems

How You Select Master Systems

The master CA MIM address space manages the VCF. Therefore, the master system uses more storage and performs more I/O operations than client CA MIM address spaces.

To define the master candidate list, issue the following statement:

GLOBALVALUE VCFMASTER=(sysa,sysb,sysc)

The master candidate list is examined from left to right during initialization to determine which CA MIM address space is to be the master system. The master candidate list is also examined in recovery situations when the current master becomes unavailable due to hardware or system-related errors. If the current master is unable to continue managing the VCF, management responsibility is passed to the next candidate in the VCFMASTER list.

You can change the master candidate list after synchronization by issuing the GLOBALVALUE command. You can issue the command from any active CA MIM system. The GLOBALVALUE parameter changes are routed to each system in the MIMplex.

The GLOBALVALUE statement has the following parameters:

• GLOBALVALUE VCFMASTER – The VCFMASTER parameter defines your preferred master candidate list. However, internally, CA MIM builds an eligible master list. The master candidate list and the eligible master list may or may not include the same systems. For example, in a four-system MIMplex (SYSA, SYSB, SYSC, and SYSD) where the CA MIM address space on each system has CTC or XCF connectivity to each of the other systems, all systems are eligible to become master. Therefore, all systems are included in the internally built eligible master list. However, you may have defined GLOBALVALUE VCFMASTER=(SYSA,SYSB). In this case, the eligible master list consists of SYSA, SYSB, SYSC, and SYSD, while the defined master candidate list consists of only SYSA and SYSB.
• GLOBALVALUE ANYELIGIBLE=[YES|NO] – In recovery situations, the ANYELIGIBLE parameter dictates whether CA MIM selects any master eligible system or only the specified systems in the VCFMASTER candidate list to begin managing the VCF.
• GLOBALVALUE MOSTPREFERRED=[YES|NO] - The most preferred master is always the leftmost system defined in the VCFMASTER candidate list. The most preferred master may or may not be the currently active master. If a more preferred system joins a currently executing MIMplex and MOSTPREFERRED=YES, CA MIM will automatically migrate master systems to the more preferred system.

  Consider the following example where a more preferred system joins a currently executing MIMplex:

  • A four-system MIMplex is defined including systems SYSA, SYSB, SYSC, and SYSD
  • GLOBALVALUE VCFMASTER=(SYSA,SYSB)
  • GLOBALVALUE MOSTPREFERRED=YES
  • SYSA is down and FREED
  • The currently active master system is SYSB
  • Systems SYSB, SYSC, and SYSD are synchronized

  When SYSA joins the MIMplex, CA MIM evaluates the MOSTPREFERRED parameter. In this scenario, MOSTPREFERRED is YES; therefore, CA MIM automatically transfers master responsibility to SYSA. If MOSTPREFFERED were NO, SYSB would have retained its master status.

• GLOBALVALUE NOMASTER=[WAIT|TERMINATE] - The NOMASTER parameter defines how client systems react when the currently active master CA MIM address space terminates or becomes unresponsive and there are no other eligible masters available in the MIMplex. This parameter determines whether the client CA MIM address spaces should terminate or wait for an eligible master to rejoin the MIMplex. However, if your initial communications method was CTCDASD, an automatic migration to your physical control file occurs when the master system becomes unavailable.
• GLOBALVALUE VCFMASTER = (sysa, sysb, ...sysn) - The VCFMASTER parameter defines your master candidate list. The leftmost system in the list is your most preferred master. An eligible master has connectivity to each system in the MIMplex. If a system has connectivity to each system in the MIMplex, then that system is added to the eligible master list. If a VCFMASTER parameter is defined having systems that are not eligible to become master systems, CA MIM attempts to select a master based on the eligible master list built internally.

As mentioned previously, master eligibility is determined internally. CA MIM systems evaluate their master eligibility dynamically during initialization, as VCF communication paths become available, and as dynamically added systems join the executing MIMplex. For a system to be master eligible, it must meet at least one the following criteria:

• Fully defined and connected CTCPATH statements in MIMINIT. In other words, a system must have a CTCPATH statement to every defined CA MIM system and every CA MIM system must have a CTCPATH statement defined to that system. However, if communication paths are unusable, then the system is not master eligible.
• A CA MIM system ‘discovers’ that it can communicate with every other defined system using a mix of CTC devices and XCF paths.
• If ANYELIGIBLE=YES is specified, then any system that can communicate with all currently active CA MIM systems is considered master eligible if all non-active systems are FREED or DISABLED. For example, assume you have ANYELIGBLE=YES and you have defined your systems with DEFSYS INITIAL=FREED. Starting CA MIM with FORMAT=BOTH or FORMAT=CF will cause the local system to assume master eligibility.
• If ANYELIGIBLE=NO is specified, then any system listed in the VCFMASTER candidate list that can communicate with all active systems is considered master eligible if all non-active systems are FREED or DISABLED.

Note: When running CA MII, you can gain the most benefit by selecting the system with the most managed enqueue activity to be the master system. The master system reads the VCF directly from its own storage, therefore it incurs no device I/O overhead, providing the best enqueue response time to the master system. You determine the number of managed enqueue requests by issuing the CA MII DISPLAY SERVICE command.