"Push/pull" of a coupling facility or POR of a processor with a coupling facility

Use the procedure shown in Table 1 for either of the following situations:

a CF is going to move onto a new CPC
the CPC on which the coupling facility resides is going to be PORd and there are physical or logical changes to the CF

Note: If the CPC is going to be PORd and there are no physical or logical changes to the CF, use POR of a CPC with a Coupling Facility with no Physical or Logical Changes to the CF .

Table 1. Steps: move a coupling facility for a push/pull operation or a POR of the processor where the CF resides
Step	Command	Reason
0	Create new CFRM policy distinct from the currently active policy with the new CF definition and 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. For the "push/pull", the node descriptor for the CF must be updated (machine type, serial number, partition number, etc.). 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. The “resizing” of structures is required when upgrading to a new CFCC level, such as, CFCC 16 (z10) to CFCC 17 (z196).
1	Quiesce all work on z/OS images that reside on the CPC being PORd or removed. Remove z/OS images from the sysplex by issuing `V XCF,sysname,OFFLINE`
2	Reassign STP roles, as needed.	Ensure CTN will not be unexpectedly disrupted when the "old" CPC where the CF image resides is removed. For more information, see IBM White Paper 101833, Important Considerations for STP server role assignments, at `http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101833`.
3	`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.
4	`D XCF,REALLOCATE,TEST` (available z/OS Version 1 Release 12)	Preview the results of REALLOCATE and evaluate any exceptions. If a severe problem is detected, remove cfname from MAINTMODE and address the problem. Then, go back to Step 3.
5	`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.
6a	`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 8. If structures remain in the CF being removed, follow Step 6b and Step 7.
6b	`D XCF,REALLOCATE,REPORT` (available z/OS Version 1 Release 12)	If any structure did not move, review the REALLOCATE REPORT output and address any errors.
7	If any 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.
8	`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 utilize 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.
9	`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. Re-verify that no structures in the CF and no systems have connectivity to CF.
10	From the CF OPERMSG console, issue: `SHUTDOWN`	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 6a. If VARYing the paths ONLINE and moving the structures is not desired (that is, deleting the structures is acceptable), then the CF image may be DEACTIVATEd.
11	Remove the CPC about to be PORd or removed from the CTN.	Removal from the CTN will allow the CONFIG command(s) in Step 12 to be accepted.
12	`CONFIG CHP(xx,yy…),OFFLINE,UNCOND`	Configure the links to the CF OFFLINE. `D CF,CFNAME=cfname` and `D M=CHP` will show the links as physically OFFLINE. Recall that paths were already logically OFFLINE from the VARY OFFLINE issued previously. The CONFIG command is used (in addition to the VARY PATH command) to ensure that z/OS can recognize all hardware changes.
13	Bring in the “new machine”.	Remove the “old” machine and bring in the “new” machine or, POR the CPC, depending on the scenario.
14	`ACTIVATE parms,SOFT=VALIDATE` On the Nth partition, issue: `ACTIVATE parms,FORCE`	If making changes to CF elements (CF control units or CF channel paths) in the I/O configuration, ensure that SOFT=VALIDATE is specified in the parms on the ACTIVATE system command. SOFT=VALIDATE is a requirement on all N-1 partitions when changes to CF elements are made. When SOFT=VALIDATE is specified, HCD builds the change control blocks, CCBs, for hardware changes, as well as, software changes. SOFT=VALIDATE also ensures there is sufficient hardware system area (HSA) space to accommodate the changes. On the Nth partition, activate the parms. For more information, refer to "Activate Command Parameters" in z/OS MVS System Commands.
15	`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 definition for the new CF and updated structure sizes per CFSizer or SIZER output. Recall, the new CF definitions is only required for a “push/pull” scenario. The CF definition change will take effect immediately. Structure size changes will be pending after the new or modified policy is activated. From a CFRM perspective, the previous definition was removed and a new CF definition was added. The new CF definition will not be in MAINTMODE even if the CFNAME is the same.
16	`SETXCF START,MAINTMODE,CFNAME=cfname`	Place the newly-defined CF in MAINTMODE to prevent DUPLEX(ENABLED) structures from immediately moving into the CF when connectivity is established.
17	Add the CPC that was PORd back into the CTN or add the new CPC to the CTN. Activate the CF partition. Reassign STP roles as necessary.	The CPC must be added to the CTN to be properly synchronized with the other CPCs. CF must be activated to allow the system to connect and use the image. Ensure STP is in the configuration you want to use. For more information, see IBM White Paper 101833, Important Considerations for STP server role assignments, at `http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101833`.
18	`CONFIG CHP(xx,yy,etc),ONLINE V PATH(CFname,xx,CFname,yy,etc),ONLINE`	Configure CHPIDs online. The configuration commands must be issued from all systems in the sysplex; CHPID numbers may be different for each system. If the CHPIDs numbers have not changed on z/OS across the "push/pull", use the links noted in Step 8. Message IXC517I will be issued indicating that XCF has connectivity to the CF. Note: If a policy change was done, the logical state of the paths is their default state (ONLINE), so there is no need to use the VARY command to bring the paths logically online. However, if the same links are to be used and there was no change to the CF definition in the CFRM policy, the logical state will be OFFLINE. Thus, the paths would need to be VARYd ONLINE from all of the z/OS images that remained active.
19	`D XCF,CF,CFNAME=cfname RO *ALL,D CF,CFNAME=cfname`	Verify XCF has the proper CF definition. In particular, if a "push/pull" is being done ensure the serial number for the new CF. `D XCF,CF,CFNAME=cfname` indicates that the CF definition XCF logically knows about. `D CF,CFNAME=cfname` contains the physical information for the CF the image is connected to. The serial numbers must match for XCF to be able to use the CF. 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.
20	`SETXCF STOP,MAINTMODE,CFNAME=cfname`	Take the newly defined CF out of MAINTMODE to allow structure allocations in the new CF.
21	`SETXCF START,REALLOCATE`	Relocate structures to the desired CFs. XCF will seek to resolve the pending policy changes.
22	`D XCF,REALLOCATE,REPORT` (available on z/OS Version 1 Release 12)	Verify that all structures reside in the desired CFs. Correct any errors noted by the report.
23	Verify that structures reside in preferred CFs. Review output from z/OS Health Check `XCF_CF_STR_PREFLIST`. Use 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 most desirable CFs, which 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 desired CFs, as needed.
24	IPL z/OS images that reside on the CPC that was PORd or reside on the new CPC.