opinion: Why You Don't Need a z/OS Monitor
At a recent customer's site I saw something that caught me by surprise: there was no z/OS monitor. Sure, they Tivoli
Omegamon XE looking after CICS, DB2 and Websphere MQ. They also had Compuware Strobe to x-ray applications, and other tools
for network monitoring. But no z/OS monitor - no Tivoli Omegamon XE for z/OS, BMC MAINVIEW for z/OS, ASG TMON for z/OS or
CA-SYSVIEW. And that's smart.
Don't get me wrong: I love monitors. They're essential when you're working with CICS, IMS and DB2. But although they were
an essential z/OS (MVS or OS/390) administration tool in the past, today they don't offer much that can't be done with plain
old z/OS. Let's break it down by functionality.
View Storage
If you're an old school systems programmer like me, you're always looking at mainframe storage and control blocks.
Sometimes you want to see what module is at a certain address, or get some information from a control block that you can't
get anywhere else.
In the past this could only be done with a z/OS monitor. Today there are a lot of other options like the free ISPF utility
TASID, downloadable from the z/OS website. Hopping through current storage in your TSO/E address space is as simple as any of
the commercial monitors. IPCS that comes free with z/OS does all this and more. Recent changes allow authorised users to see
not only the storage of their TSO/E address space, but storage in other address spaces as well. Commercial z/OS monitors often
have the added option of updating this memory. But let's be honest: no-one really uses this.
View System Information
Finding out the z/OS version, hardware model, APF list and LPA list used to be the bread and butter of z/OS monitors. But
today, it's no longer the case. TASID comes in again with some basic z/OS information, including processor model and z/OS
version. Gilbert St Flour's free SHOWMVS utility gives you more information than you will ever need. And even simple z/OS
commands show you libraries in the APF list, linklist and LPA list, as well as other information like z/OS version.
The ISPF ISRDDN utility that comes free with z/OS is a far better way to see the APF list, linklist and LPA list than any
z/OS monitor. You can also search for modules within them.
Viewing LOGREC records online is another example. If you don't want to run the batch EREP utility, the free LOGREC viewer
downloadable from the IBM website can take care of this for you.
For those that don't mind coding, IBM provides many APIs to get a lot of systems information from most programming languages.
Our Free Tools and Code section shows some examples.
The RMF Monitor II displays have been updated to show IEAOPTxx parmlib values. And z/OS display commands can take care of
most others.
Update System Resources
Adding a library to the Linklist, LPA list or APF list was once something that only a monitor could do. Today, these are
easily updated using the z/OS SETPROG console commands. SVCs are a little different.
Existing SVC modules can be updated at any time using the z/OS SETPROG LPA console command. However z/OS doesn't have a
command to dynamically add a new SVC. But this is easily avoided by scheduling IPLs to add SVCs. Alternatively; assembler
programmers can write a program to use the SVCUPDATE facility to dynamically add a SVC routine.
View DASD Information
Finding out information about DASD space and performance were once exclusive monitor-only territory. Today the free ISMF
is better at viewing DASD volume, dataset, catalog, and a range of other disk related information. For batch processing, the
IDCAMS DCOLLECT statement will quietly go and get disk and dataset related information - a utility used by many software
products. Standard software such as Merrill MXG, CA-MICS and Tivoli Decision Support can be used to process this information,
or you can write your own. Some REXXs to process DCOLLECT can also be found on the CBT Tape website.
For performance, that wonderful set of RMF monitors will show just about anything a z/OS monitor can.
Cancel Jobs
I remember many times in the distant past when I relied on a monitor to cancel a job that a simple z/OS cancel command
couldn't handle. A monitor's cancel command was often more effective, and avoided that dreaded FORCE,ARM parameter needed
to get rid of stubborn looping programs.
But to be honest, I haven't needed to do this for about 20 years, and I haven't heard of anyone who has. Today it's hard to
fault the reliability of z/OS.
See Performance Information
For many years RMF monitor I has provided performance-related information at periodic intervals. However a batch job is
needed to access this information, and by that time the information is old. z/OS monitors have provided excellent real-time
screens about the performance of jobs running in z/OS, and z/OS itself.
Today, other RMF tools also achieve this. It's easy to forget about RMF Monitor II, but this has for decades provided
snapshots of basic performance metrics. RMF Monitor III goes further with better screens, and diagnostic tools to find out
why a job is being delayed, how the Coupling Facility is running, and other essential system information.
IBM has further improved this functionality with RMF Distributed Data Server (RMF DDS) - a started task that allows access
to RMF Monitor III information from any connected web-browser. And if this wasn't enough, the RMF Performance Monitor (or RMF
PM) builds on RMF DDS to provide fancy screens that will be the envy of some z/OS monitors. All features included with the base
RMF, or downloaded free from the IBM website.
See What's Happening
Many monitors provide excellent screens to quickly see what's happening, and any potential problems. These screens are based
on pre-canned thresholds that can be tailored, and often are colour coded to make serious problems easier to see. I really like
these screens, but in my experience few sites actually use them. Most rely on automated operations products trapping messages and
raising alerts. And most automated operations packages provide some sort of starter kit with all the important messages already setup.
In the past I have used a dedicated VTAM terminal with one of these screens running. So even if TSO/E failed, I had some
options. But today z/OS is much more stable, and the z/OS console has a lot more options to find out what's going on, and what
to do.
Many monitors also provide some historical information. Using SMF records can usually get you everything and more. Most sites
will have something like SAS/MXG, CA MICS or TDS to look at these records.
RMF Monitor I also provides a lot of historical data, and a batch utility to go and get it. The reports are fairly standard,
but the RMF Spreadsheet Reporter eases the pain of using and processing this information. Nice tables and pretty graphs are
relatively straightforward once you get used to how it works.
Trace
All monitors have some form of easy to use trace, and this is where they do shine. Although standard z/OS trace facilities can
do most of what the monitors can, they're not they're not easy to use. However a lot of the tracing functionality is there - our
z/OS Tracing for Beginners article covers this in more detail.
If you have something like Compuware Strobe, IBM APA or Macro 4 FreezeFrame, you may not need that trace. Although these
don't trace as such, they provide a snapshot of what is responsible for CPU time, wait time and I/O. They even go down to the
individual instruction for COBOL, PL/1, C and other popular languages. And of course CICS and IMS monitors also provide tracing
facilities for applications in their space.
Many application development products also provide very nice utilities in this area. From my experience, few people use the
trace facilities of z/OS monitors.
Conclusion
Valid reasons to keep your z/OS monitor may still exist. For example, users of sophisticated ITM scenarios may still need
Omegamon XE for z/OS working in the background. But from where I stand, most z/OS monitoring software features and functions can now be done
using standard z/OS or RMF features. Those that can't are rarely used. There is no doubt that some systems programmers won't
want to lose their favourite z/OS monitor, but today these are a luxury that may be hard to justify. Adding up software maintenance
costs and CPU consumption may tip the balance away from your z/OS monitoring software.
David Stephens
|
Home
| Press
Room | Contact
Us | Site
Map
