Enhancements in Gaining Coupling Facility Ownership
This chapter describes a z/OS V2R2 enhancement at the Gaining Coupling Facility Ownership processing. This function is run by XES, a z/OS component in charge of the coupling facility (CF) access.
An IBM Parallel Sysplex is a set of z/OS systems that are connected to CFs. A CF cannot be shared by z/OS systems in different Parallel Sysplexes because of the risk of the lack of data integrity.
This chapter includes the following topics:
3.1 A z/OS instance joining a Sysplex
When a z/OS instance is performing an Initial Program Load (IPL) in a Parallel Sysplex environment, it tries to join a Sysplex. To make this connection, the XCF component of the z/OS instance first tries to establish a conversation with another XCF in the other z/OS systems that are in the same Sysplex. This conversation is done through the pathout information at COUPLExx Parmlib member. The following verification is required for a successful join:
•As declared at the COUPLExx Parmlib member of this z/OS, the Sysplex name is the same of the previous z/OS systems already in the Sysplex.
•The symbol &Sysclone is unique per z/OS in the Sysplex.
•GRS RNL is the same as in other previous z/OS Sysplex members.
•The MAXSYSTEM parameter counter of z/OS systems in the Sysplex is not exceeded.
If everything is correct, the XES component tries to connect to the CF.
Connecting to the CF
Before z/OS V2R2, the concept of CF Authority was implemented to avoid the same CF being used in different Sysplexes.
The CF Authority is a string of bytes in the CF. It is formed by the Sysplex name plus the contents of the current TOD. The first z/OS XES joining the Sysplex (first connecting) requests the CF to store the CF Authority. The Sysplex name in the CF Authority comes from the COUPLExx Parmlib member, as defined by the installation. The act of storing a new CF Authority in the CF known as gaining ownership.
The CF is located by XES through its name and attributes (Name, Type, MFG, Partition, CECID, and other information) as described at the CFRM couple data set.
Also, when a first XES in a z/OS succeeds is connecting to a CF, this XES also copies the CF Authority into the CFRM couple data set (CDS). Then, every time that a gaining ownership process is run, the CF Authority at the CFRM is compared with the CF Authority in the CF to avoid the same CF in several Sysplexes. CF Authority is cleared (zeroed) at the CF when it is being removed from the Sysplex.
The CF Authority is set to zero in the following cases:
•The CF is started by Coupling Facility Control Code (CFCC)
•An owned CF is removed from the CFRM policy and it is not owned or used by any Sysplex.
•During the transition to a new CF Authority (briefly)
3.2 Definition enhancements
Before z/OS V2R2, hardware definition and configuration errors can cause issues when XES from the z/OS system in the IPL process tries to connect to a CF that is used by z/OS systems from other Sysplexes. In this case, messages are shown at the console and the operator must decide on what action to take. If the information is insufficient, an incorrect decision can cause a full Sysplex outage.
The z/OS V2R2 enhancement for this problem is the introduction of a new keyword CFRMTAKEOVERCF with a default for (NO) at COUPLExx Parmlib member.
When a Sysplex attempts to gain ownership to the CF via the first IPL of one of its z/OS systems, it attempts to store a new CF Authority in a CF. One of the following situations can arise as a result:
•If CF Authority of the CF matches the old CF Authority in the CFRM CDS, this CF was used lately by this Sysplex.
An old CF Authority in the CFRM CDS can match the one in CF for the following reasons:
– The Sysplex is in the IPL process in the previous CF. It appears that there are no problems with this issue; therefore, CF can be used.
– Initially load another z/OS with a different Sysplex couple data set, with another Sysplex name, but using a copy (from mirroring or otherwise) of the same CFRM CDS. This configuration is not recommended because other z/OS systems are still using the current copy of CFRM CDS; that is, running in another Sysplex and using this CF.
The action here depends which of the following COUPLExx member keywords is used:
– CFRMOWNEDCFPROMPT(NO): This keyword is the default. Sysplex gains ownership automatically.
– CFRMOWNEDCFPROMPT(YES). The operator is prompted and must decide. This keyword was available before z/OS V2R2.
•CF Authority mismatches. A CF Authority in the CFRM CDS does not match the one in CF for the following reasons:
– Sysplex-wide initial load with a different CFRM CDS. There is no problem to use such CF.
– Initial load a z/OS from different Sysplex couple data set but using an old copy (from mirroring or otherwise) of the CFRM CDS. This situation has many potential issues if the Sysplex that is using the current copy of CFRM CDS still using CF.
– Initially load another sysplex (different sysplex CDS) with a CFRM policy that has a CF that does not belong to it. This configuration is also not recommended and puts the systems at risk.
The action here depends which of the following COUPLExx member keywords is used:
– CFRMTAKEOVERCF(NO): This keyword is the default and recommended. XES rejects the use of a CF that might be in use by another Sysplex. By using this option, the installation avoids potential errors and forces the installation to reactivate the CF that is incorrectly accessed to pass it from one Sysplex to another Sysplex, if required.
– CFRMTAKEOVERCF(PROMPT): This keyword is old behavior. The operator is prompted to make a decision that is based on understanding the request and its implications.
Two of the following situations are not tested:
•There is no CF Authority, which means there is zero CF Authority.
•Authority matches a current authority in the CFRM CDS (for example, in a total connectivity loss/re-gain).
3.3 Possible approach considerations
The following suggested approaches can help you decide which options to take; however, unique circumstances to your configuration might override these suggestions:
•The following approach is suggested:
– Use the following statements for the safest configuration:
• CFRMOWNEDCFPROMPT(YES)
• CFRMTAKEOVERCF(NO) z/OS V2R2 new default behavior
– Statements with the most automatic gain ownership of the CF are possibly susceptible to more configuration errors because of insufficient clear information that is available to the operators:
• CFRMOWNEDCFPROMPT(NO) this is the default
• CFRMTAKEOVERCF(PROMPT) this advocates pre-z/OS V2R2 behavior
•The use of CF might be rejected for CFRMTAKEOVERCF(NO), as shown in Example 3-1. Here, takeover refers to gaining ownership.
Example 3-1 Example of not allowed takeover
IXC518I SYSTEM S1 NOT USING
COUPLING FACILITY SIMDEV.IBM.EN.ND0100000000
PARTITION: 00 CPCID: 00
LP NAME: N/A CPC NAME: TINK6
NAMED LF01
AUTHORITY DATA: PLEX1 01/30/2015 08:08:55.195784
REASON: TAKEOVER PROHIBITED.
REASON FLAG: 13340009.
•More authority data in messages IXC500I, IXC518I, and IXC362I when applicable, as shown in Example 3-2. AUTORITY DATA is from the CF and CFRM AUTHORITY is from CFRM CDS.
Example 3-2 DISPLAY XCF,CF,CFNAME=
IXC362I 18.13.16 DISPLAY XCF
CFNAME: LF02
COUPLING FACILITY : SIMDEV.IBM.EN.ND0200000000
PARTITION: 00 CPCID: 00
SITE : SITE1
POLICY DUMP SPACE SIZE: 1 M
ACTUAL DUMP SPACE SIZE: 1 M
STORAGE INCREMENT SIZE: 1 M
AUTHORITY DATA : PLEX1 01/30/2015 18:06:13.281887
CFRM AUTHORITY : PLEX1 01/30/2015 17:53:35.128473
■
•Enhanced explanations in IXL150I as a result of the DISPLAY CF command, as shown in Example 3-3. The following hints explain the new information:
– NOT IN USE BY SYSTEM (Hint: See IXC518I)
– NOT CONNECTED TO SYSTEM (Hint: Check paths)
– NOT IN THE CFRM ACTIVE POLICY (Hint: Check CFRM policy)
Example 3-3 DISPLAY CF
IXL150I 18.18.51 DISPLAY CF
COUPLING FACILITY SIMDEV.IBM.EN.ND0100000000
PARTITION: 00 CPCID: 00
LP NAME: N/A CPC NAME: TINK6
CONTROL UNIT ID: 0001
NAMED LF01
NOT IN USE BY SYSTEM
■
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.