In this blog, we’ll talk briefly about NetView program as well as System Automation program that are commonly used on z/OS for automation, we’ll see how they are there to help on the z/OS system startup and shutdown process, and how to monitor z/OS system by working with NetView/System Automation (NetView/SA for short).
What You Need to Know First
About NetView/SA
NetView/SA is commonly seen and used on z/OS platform for system automation works including system startup (i.e. system IPL), system monitoring, and system shutdown. NetView and SA (System Automation) for z/OS are two products that need to be installed separated, while SA is the major system automation product which is based on NetView. In other words, the implementation of SA as well as its execution need the support from NetView as base.
For simplicity reason, in the context of z/OS automation, engineers are using the words NetView, NetView/SA, or simply SA interchangeably, all meaning the automation implemented on the z/OS platform.
About z/OS Automation
In NetView/SA, before any automation is implemented and performed, all kinds of system resources are to be defined in something we call SA Automation Policy, these include each system components, subsystems, features or sub-functions, system applications, as well as systems themselves. Each of these things is defined in the policy as an entry of certain type and is given certain relations or dependencies with others. These dependencies take import role in the system startup/shutdown automation process.
Among all types of entries, the Application entry (APL for short) is perhaps one of the most often used if not the most. Many of the aforementioned system resources are defined as APL (one APL entry for each resource) as the basic automation unit that could be grouped into Application Group (APG), specified where to used by donating the System entry, or given the relationships with other APL resources. These are all what to define in the SA policy.
It is worthy to note that there are six flags there (usually for APL) associated with certain impacting the granularity of system automation control, which are Automation flag, InitStart flag, Start flag, Recovery flag, Terminate flag and Restart flag. Each APL resource will have these six flags and the Automation flag is the overall switch to control whether the automation is turned on or off for the resource while the other five control the respective phase during automation processing. Generally speaking, NetView/SA has full automation control of the resource only when all six flags are turned on.
NetView console is commonly used for monitoring and managing the automation work. By opening a NetView Session (via console) operators do most automation works there.
About the Sequence during System Startup or Shutdown By Automation
As stated previously, the relations and dependencies among system resources are vital, in that they determine the sequence to start or stop during system startup or shutdown. One of most used relations is HP – HasParent. This relation would eventually form a “Tree” among the resources being automated, for example:
In the above Figure, parent-child relations are displayed in top-down manner with indention of the child nodes to the right. When system startup (during IPL), the automation ensures the sequence of starting each resource by strictly following this “Tree” structure, starting parents before children, thus staring NETVSSI for all the others, starting JES before SDSF or RRS, starting VTAM before TCPIP or TSO etc., while shutdown process will follow the exact reverse order. This also means that when system starting, once one resource cannot start up properly, all of its children will be pending without starting; the same is to the system shutdown process, once resource cannot stop properly, its parent will not be able to stop.
The Process of System Startup and Shutdown by NetView/SA
System Startup Process by Automation
In z/OS, system startup process is called IPL (Initial Program Load). Generally speaking, starting NetView as well as System Automation is implemented by utilizing the COMMNDxx parmlib member. When NetView/SA itself is up, all the following system components, subsystems, features as well as applications are brought up by automation in sequence, according to the relations or dependencies defined in the automation policy, and no other manual intervention or operation is required.
System Shutdown Process by Automation
This would require operator to issue INGREQ command from the NetView console. After that, NetView/SA will bring down everything, again following the relations or dependencies defined in the automation policy.
System Monitoring with Automation
NetView console is mainly used for monitoring the system status for the whole process of system startup or shutdown, catching instantaneous status of each resource. This is usually done by using DISPSTAT command in the console, and this will display the DISPSTAT panel showing the real time status of every APL or APG resource, like below:
As can be seen in the above figure, all resources are “UP” which usually means ok – no problem, the green color of each resource entry also indicates good status. There are some function keys provided at the bottom of this panel, they are to be used for various purposes, but here FP9 is used to have NetView refresh the status in time. Note that the “STATUS” showing may vary during the process of system startup or shutdown, normally in the following way:
System startup: AUTODOWN -> STARTING -> ACTIVE -> UP
System shutdown: UP -> AUTOTERM -> AUTODOWN
A Comparison with The Traditional Way
Here takes a brief comparison between the way of system startup/shutdown by NetView/SA and the traditional way of doing the same thing without the automation.
When applying NetView/SA, it saves the works to define startup command of each system resource in the COMMNDxx parmlib member. In the meanwhile, efforts are to be made for defining the automation policy for each resource, but it’s worthy. Why? Take IPL process as an example, there’s not much control there with COMMNDxx as what it does is just to issue the MVS commands and that’s all, no further way to see whether the resource is actually started properly or not. People usually need to go to SDSF to check or use further MVS commands like “D A,L” in order to get the exact status. If it needs to restart a resource, people would the startup command again manually. What’s more, there’s no control of the dependencies among the resources to start, thus one may fail to start simply because of the failure of its depending resource. All of these can be well controlled with the help of NetView/SA. Same is true when system shutting down.
Summary
NetView/SA has been widely used on z/OS for all kinds of system automation work. It provides a convenient way to control and monitor the system from various aspects. We talked about some of details of how the automation help the z/OS startup and shutdown, comparing with the traditional way, NetView/SA provides more powerful way of controlling the resource relations and dependencies and better way of monitoring the process, which in turn ensures the system starts or stops in a more appropriate way that is under our control.
References:
System Automation for z/OS User's Guide
System Automation for z/OS Defining Automation Policy