|
IBM Tivoli System Automation for z/OS V2R3—A Primer to Monitor Resources
from CCR2, Issue 4 - 2005
An interview with the author—Paul Quigley of IBM Tivoli Worldwide Education
Monitor Resources (MTRs) are a new function in IBM Tivoli System Automation for z/OS® V2R3. These policy objects allow you to obtain the health state of other resources—typically applications or application groups—so that you can see how well they are performing. To learn more, CCR2™ recently sat down with Paul Quigley, a zSeries® and system automation expert from IBM Tivoli Worldwide Education. After the interview, you can download his new primer on how to write monitor routines, create MTR policy definitions, and use the System Automation for z/OS operator interface to manage your monitor resources.
CCR2: Let's start with a quick word about your background and role in the Tivoli Education organization.
Quigley: OK. I'm a member of the Tivoli Technical Education Course Development organization. I have worked on mainframe-based systems and network management, monitoring, and automation for 24 years and have an extensive background using Tivoli NetView® for z/OS and now System Automation (SA) for z/OS. During my career, I have held various positions ranging from software test to product development to product support and have worked with many customers worldwide to understand their requirements and solve their problems. I have also presented many technical topics at conferences and customer locations.
My current role in the education organization is to develop customer classes related to the SA z/OS product.
CCR2: You're calling your new white paper a primer. Who did you write it for, and what do you hope they will take away from the paper?
Quigley: The document is intended for use by both SA z/OS operators and system administrators. The system administrator will be responsible for creating MTR policy definitions and writing the monitor routine(s), if necessary.
The operator will be using the SA z/OS operator interface to view the Health Status of resources and will need to understand, at a high level, the monitor resources, monitor routines, and what the health states for a monitor resource mean.
The main reason for writing a white paper such as this is to help the customer get started with using the function, in this case, monitor resources. My personal goal for anyone reading the white paper is to save time and effort. I want the reader to learn from my experiences.
CCR2: Can you highlight some of the key technical features of Monitor Resources? Why were they added to SA z/OS 2.3?
Quigley: The primary feature of monitor resources is that it allows non-SA z/OS sources to affect the status of resources being monitored and automated by SA z/OS. Those sources most likely will have additional data that pertains to a problem or outage that can be used to supplement the data already collected by SA z/OS.
For example, a monitor resource can be used as part of an escalation process. The customer can define the monitor resource and set its status differently over time if a problem is not handled appropriately.
Another example may be to issue a command to test how well an application is performing and then set its Health Status based on a range of values. I've included an example of monitoring TCP/IP performance in the appendix of the white paper.
CCR2: Finally, where should our readers go for more training resources on monitor resources and IBM Tivoli System Automation for z/OS?
Quigley: Tivoli Worldwide Education has developed two classes currently available to customers. They are:
|
