Skip to main content

Automation by Function and Layers

Joseph Gulla explores the software stack, systems management and automation concepts, and relevant historical background.

Last week, I started a new series on automation, beginning with a focus on IBM Z Service Automation Suite (tagline: “automate and control a large range of system elements spanning both the hardware and software resources of enterprises in a sysplex”). This week, I am going to refine the discussion and move up the software stack. Before I do that, let me discuss systems management and automation concepts and history.

In IT management, where automation implementation began, there’s a history relating to “what is important.” First, the system was important. As the network evolved, it because important too. One didn’t replace the other, we just had two domains: system and network. Interestingly, IBM had an automation platform, with offerings and products that came later, that reflected this difference in domains. 

After this came applications. IBM’s focus on applications was fueled by the management challenges associated with client/server applications. You remember—components were spread out in the network and sometimes the left hand didn’t know what the right hand was doing. For IBM, this is where Tivoli came in as this was a big focus of the company IBM acquired. 

Tivoli took an application-centric approach and even had a management standard called the application management specification focused on these tasks that frequently had an automation dimension:

  • Application distribution
  • Application installation
  • Application monitoring
  • Application configuration
  • Operational control
  • Deploying updates and new releases
  • Application component relationships
  • Security management
  • Application response time management

Just as in the past, nothing went away. We had system, network and application management with a focus on automation. This is a relatively historical perspective. There was another view that somewhat ignored these divisions and sought to exploit interfaces in the OS and the management platform to do whatever needed to be done. This approach started out as a collection of automation samples to do "this or that” and eventually evolved into a set of procedures organized around operational needs like “start up the entire system” or “shut down the entire system” or “recover this resource.” By “entire system,” the developers meant everything running on the OS— JES, ICSF, OMVS, Automation Manager, NetView, SDSF, SDSFAUX, RMF, RACF, TSO, HSM, HZSPROC, TCPIP, VTAM and on and on—dozens of started tasks and jobs brought up (or down) in a completely organized manner. No human could do it faster or more error-free. 

Eventually, these two approaches converged. Rigorously tested commercial products, like IBM System Automation for z/OS, emerged with support for key subsystems and middleware. This product offers best practices in the form of automation policies. These products continue to change and evolve as evidenced by the presence of the IBM Z Automation Suite including the IBM Service Management Unite free-of-charge component. Automation just keeps getting better. 

What’s ‘up the Stack?’ 

By “up the stack,” I mean, “How is automation handled for CICS, IMS and Db2?” This isn’t the sum of middleware, just examples. Handling middleware is important because middleware, by nature, is close to the application, so failures or poor performance are noticed immediately by application users. Let’s look at IMS, CICS and Db2 automation.  

The IMS, CICS and Db2 policy provided with System Automation for z/OS includes all the definitions necessary to support the startup, shutdown and recovery of systems and resources during operation. The recovery of resources is special and unique within each system and requires understanding and some decision-making as it likely impacts current operational support procedures.

IMS automation provides automated recovery for transactions and programs and also enables monitoring of online log data sets, recovery control data sets, VTAM access method control block and IMS connections to the external subsystems, Db2 and IBM MQ. 

CICS automation provides automated recovery for application components, including transaction recovery and short-on-storage conditions. It also supports monitoring of CICS connections to the external subsystems Db2 and IBM MQ. 

CICS Automation of SA z/OS allows the monitoring of events that are issued by CICSPlex System Manager, including support of status programs, allowing you to make definitions so that a program is executed periodically and sets one of the CICSPlex SM severities.

Db2 automation provides automated recovery for specific critical events that may occur during normal day-to-day running of Db2, including handling these key messages:

Db2 automation also comes with an automation utility that can be invoked by operators. The INGDB2 utility lets you:

  • Start or stop a table space
  • Terminate active threads
  • Inform TSO users that their thread is about to be terminated
  • Check for indoubt threads

What’s Next?

Next week, I’ll continue developing the automation story, with a specific focus on application automation.  

IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →