Disruptive CF Upgrade

Use the procedure in Table 1 when the coupling facility image must be reactivated, but the CPC on which the coupling facility resides will remain operational across the reactivation process. This procedure also assumes the CF links, CF control unit, and CF definition in the CFRM policy are not changing.

Table 1. Steps: move a disrupted coupling facility
Step	Command	Reason
0	Create new CFRM policy distinct from the currently active policy with the updated structure definitions based on CFSizer or SIZER. Alternatively, update the current policy "in place" to avoid changing the name of the policy.	This step can be done ahead of time to minimize net down time. Appropriate structure sizes for the new CFCC level can be obtained from CFSizer (`http://www-947.ibm.com/systems/support/z/cfsizer/`) or Sizer (`http://www-947.ibm.com/systems/support/z/cfsizer/altsize.html`). Updated structure sizes are necessary to ensure that a performance problem does not occur due to a structure space constraint. Also, the updated structure sizes will ensure that there is no issue restarting an application in the future due to invalid structure sizes. This step is required for CFCC Level changes. This step is desirable if the sizes were not adjusted across the last CFCC Level upgrade or if the usage of the structures has changed significantly. Caution: This procedure assumes the CF links, control unit, and CFRM definition are not changing. If the links, control unit, or CFRM definition change, the CF may become accessible earlier than planned.
1	`SETXCF START,MAINTMODE,CFNAME=cfname`	Place the CF to be upgraded in maintenance mode so that no new structures will be allocated on the CF.
2	`D XCF,REALLOCATE,TEST` (available z/OS Version 1 Release 12 )	Preview the results of REALLOCATE. Evaluate any exceptions. If a severe problem is detected, remove cfname from MAINTMODE and address the problem. Then, go back to Step 1.
3	`SETXCF START,REALLOCATE`	Issue REALLOCATE to have XCF assess each structure and relocate, as appropriate. XCF will seek to move the structures off the CF in MAINTMODE.
4a	`D XCF,CF,CFNAME=cfname`	Determine if any structures remain in the CF that is being removed from service. If no structures remain in the CF being removed, go to Step 6. If structures remain in the CF that is being removed, follow Step 4b and Step 5.
4b	`D XCF,REALLOCATE,REPORT` (available z/OS Version 1 Release 12)	If a structure did not move, review the REALLOCATE REPORT output and address any errors.
5	If structures remain in CF cfname, issue the following commands: `SETXCF START,REBUILD,STRNAME=strname,LOC=OTHER SETXCF STOP,REBUILD,DUPLEX,STRNAME=strname,KEEP=NEW\|OLD D XCF,CF,CFNAME=cfname`	Move any structures that remain in cfname. Application-specific protocols may be needed to move structures. Then, verify that no structures remain on the coupling facility about to be upgraded. For details about moving structures out of the CF, see Removing structures from a coupling facility for shutdown and Removing a structure from a coupling facility.
6	On each system, issue: `VARY PATH(CFname,xx,CFname,yy,etc),OFFLINE,UNCOND`	VARY the paths to the CF offline. The VARY command must be issued from all systems in the sysplex; path numbers may be different for each system. Taking the paths offline and then recycling is cleaner for z/OS to handle than not taking the paths offline. The hot unplug or TOGGLE is received as an “error” by z/OS. To obtain the list of CHPIDs, issue `D CF` from each system. The list of CHPIDs is helpful when bringing the paths back online. The VARY command is used rather than the CONFIG command because it is possible that use of the links by STP would cause the CONFIG command to be rejected. Using the VARY command affects only the logical path state for coupling facility communication and does not affect (nor is it affected by) the STP network; STP can still use the links to maintain the timing network. When the paths are VARYd OFFLINE, the `D CF,CFNAME=cfname` command shows the paths as being logically offline, but physically online.
7	`RO *ALL,D CF,CFNAME=cfname D XCF,CF,CFNAME=cfname`	Verify that no system has an active path to CF. At this point, the paths will indicate logically OFFLINE. Reverify that no structures in the CF and no systems have connectivity to CF.
8	From the CF OPERMSG console, issue: `SHUTDOWN`. After the SHUTDOWN completes, ACTIVATE the CF. Note: Do not perform a POR the CPC. If there is to be a POR of the CPC, use procedure "Push/pull" of a coupling facility or POR of a processor with a coupling facility.	The SHUTDOWN command is recommended to avoid the potential error of DEACTIVATING the coupling facility that has all of the structures allocated in it. The SHUTDOWN command will not complete if structures are present in the coupling facility. The following scenario shows the message sequence for the SHUTDOWN command when structures are still allocated in the CF: `=> shutdown CF0090A Do you really want to shut down the Coupling Facility? (YES/NO) => yes CF0093A There are structures present in the CF. SHUTDOWN canceled.` After the SHUTDOWN command completes successfully, the CF LPAR will become “not operating.” If structures are still allocated in the CF, verify that the correct CF was selected for SHUTDOWN. If the correct CF was selected, consider reviewing the structures still allocated in the CF and seek to move them out of the CF. At this point, the paths must be VARYd back ONLINE to allow structures to rebuild out of the CF. VARY the paths ONLINE and go back to Step 5. If you do not want to VARY the paths ONLINE and move the structures (that is, deleting the structures is acceptable), the CF image may be DEACTIVATEd.
9	`SETXCF START,POLICY,TYPE=CFRM,POLNAME=new_policy` or `SETXCF START,POLICY,TYPE=CFRM,POLNAME=mod_active_policy`	Activate the new CFRM policy with the definitions for the updated structure sizes, per CFSizer or SIZER output. Structure size changes will be pending after the new or modified policy is activated.
10	On each system, issue: `VARY PATH(CFname,xx,CFname,yy,etc),ONLINE`	VARY paths online. The command must be issued from all systems in the sysplex; path numbers may be different for each system. To obtain the list of CHPIDs, issue `D CF` from each system or use the list from Step 6.
11	`D XCF,CF,CFNAME=cfname RO *ALL,D CF,CFNAME=cfname`	If any changes were made to the CF definitions in the CFRM policy, verify that XCF is connected to the correct CF, including the serial number for the new CF. `D XCF,CF,CFNAME=cfname` indicates the CF definition that XCF logically knows about. `D CF,CFNAME=cfname` contains the physical information for the CF the image is connected to. The serial numbers noted in the `D XCF` and `D CF` commands for each CF must match. Verify that all systems have connectivity to the new CF and all the paths are ONLINE. Also, verify that CF to CF links are available.
12	`SETXCF STOP,MAINTMODE,CFNAME=cfname`	Take the newly-defined CF out of MAINTMODE to allow structure allocations in the new CF.
13	`SETXCF START,REALLOCATE`	Relocate structures to the desired CFs. XCF will seek to resolve the changes pending.
14	`D XCF,REALLOCATE,REPORT` (available on z/OS Version 1 Release 12)	Verify that all structures reside in desired CFs. Correct any errors noted by the report.
15	Verify that structures reside in preferred CFs. Review output from z/OS Health Check `XCF_CF_STR_PREFLIST`. Issue the following SETXCF REBUILD commands, as necessary, to move structures. `SETXCF START,REBUILD,STRNAME=strname,LOC=OTHER SETXCF STOP,REBUILD,DUPLEX,STRNAME=strname,KEEP=NEW\|OLD`	REALLOCATE processing may complete with 0 exceptions because XCF / XES placed the structure in the most desirable CFs; this may not coincide with the order of the CFs in the PREFLIST. Investigate structures that were not placed in the CF that is noted first in the PREFLIST. Assess the reason for the structure placement and relocated structures to the desired CFs, as needed.