Shutting Down a z/OS systems in a GDPS Environment

SA z/OS® allows you to shut down z/OS systems either through the INGREQ ALL command in a GDPS® production environment or from a GDPS controlling system.

In any case, SA z/OS invokes a shutdown request against the GDPS STOPAPPL. The STOPAPPL resource is define in advanced automation option (AAO) AOF_AAO_SHUTDOWN_STOPAPPL. For more information about the GDPS STOPAPPL and AAO AOF_AAO_SHUTDOWN_STOPAPPL, see Read/Write Variables.

There are three distinct phases in the final shutdown processing that are defined using the special message ID SYSTEM_SHUTDOWN in MESSAGES/USER DATA policy item for the MVS Component entry type:
Phase 0
This phase is entered prior to shutting down the resource that is identified by the GDPS STOPAPPL parameter (the STOPAPPL resource). In this phase, you can perform any action before the actual system shutdown starts.
Phase 1
This phase begins when the resource that is identified by the GDPS STOPAPPL parameter (the STOPAPPL resource) has been terminated. In this phase, you can specify additional INGREQ stop commands or any other NetView commands to terminate any subsystems that are still present.
In addition, GDPS invokes INGRGDPS to process both primary (PAM) and secondary Automation Managers (SAM) hosted on the local system.
  • If no Automation Manager runs on the local system, control returns to the caller.
  • If only a SAM runs on the local system, no action is taken.
  • If the local system hosts the PAM, INGRGDPS checks whether an available SAM is running on a system that is not included in the list of systems scheduled for shutdown.
  • If so, INGRGDPS switches the PAM to that system, using the same behavior as moving the PAM with the INGAMS panels. As a result, the currently active PAM terminates, and SA reports that it was shut down outside of automation. This condition is harmless because it is either corrected by subsequent processing or adjusted by the initial monitoring process after the system is reIPLed, assuming the Automation Manager is started using the COMMNDxx parmlib member.
  • If no other SAM is eligible to take over the PAM role, the PAM shutdown is delayed until all other systems are shut down and then terminated gracefully.
Phase 2
This phase begins after the termination of any local automation manager (PAM and SAMs) and OMVS. Only NetView commands or z/OS commands can be specified. For example, the INGSHRES SMF_REC command.
Note:
  1. OMVS and all local automation managers are always shut down by SA z/OS automatically. Do not specify termination commands for OMVS or automation managers in PHASE1 or PHASE2. When running in a JES3 environment, consider triggering the command MVS F BPXOINIT,SHUTDOWN=FORKS via routine INGRYSHU in the JES3 SHUTINIT phase. INGRYSHU will issue the command only when a system shutdown is detected. Likewise, you can trigger command MVS F BPXOINIT,SHUTDOWN=FILESYS in the JES3 SHUTFINAL phase.
  2. Be aware that the NetView address space is still present and must stay up in order to signal to GDPS that the system is ready to be taken out of the SYSPLEX.
  3. Whenever NetView is ended without its CLOSE command being invoked, it cannot automatically archive recent messages in its active Canzlog. To accomplish the archiving of these messages, use CANZLOG CUE command during phase 2.
The scenario is based on the provided best practice policies *BASE and *GDPS. For more details, refer to the MVC entry GDPS_SYSTEM_SHUTDOWN in the *GDPS best practice policy.