Using HP OpenView IT/Operations on HP 3000s
Configuration hints help monitor the
3000’s work efficiently in
a heterogeneous environment
By Andreas Schmidt
By updating our HP 9000 HP OpenView IT/Operations (IT/O) server to HP-UX 10.20 and IT/Operations A.03.01, we were able to install IT/O agents to our five HP 3000s running MPE/iX 5.0 with PowerPatch 6. We’ve learned that using IT/O makes monitoring HP 3000s in a diverse environment much easier.
More than 30 Unix systems, including HP 9000s and IBM’s RS/6000s, were already monitored at our site by IT/O, mainly SAP/R3 instances and EDI boxes. But IT/O was not managing a single MPE box. We needed to extend the use of this tool. At our company, Operations has to monitor not only the HP 3000 and Unix environment, but also DEC and IBM mainframes, plus Novell and NT network boxes. A single monitoring tool which can handle a lot of technologies was the goal that started our effort.
It became evident that the IT/O manuals offered only rudimentary coverage of the installation of IT/O agents on HP 3000s. But having colleagues with an excellent Unix background of IT/O, we were able to create from the downloaded files a working IT/O agent on our internal crash-and-burn HP 3000 system, a Series 960. I am glad to share the full details of our HP 3000-oriented installation procedure; just send me an e-mail request.
The first thing we changed was the message filter for the MPE console messages. The default filter for HP 3000 looks only for open replies. So we started to show all messages to the IT/O console. Then we started to filter everything that should not appear. Currently we have 49 conditions to select and deselect HP 3000 console messages. For example, we do not show all invalid logons to the IT/O console, but we show all of Maestro’s job abend messages.
Some special conditions have been created for the one-time messages out of Predictive Support PSS, Mirrored Disk Subsystem, ThresholdManager and ARPA. These conditions will automatically get a special severity to show operations staff the criticality of the event. We also monitor the usage of Samba/iX by enabling the root pre/postexec commands and adopting a condition for this console message.
Having reduced all messages to a meaningful minimum, we started to implement a special for all TELLOPs. On big HP 3000s, TELLOPs can be lost on the console. Therefore, we added five special conditions if a TELLOP follows a simple rule: Whenever a TELLOP OPC-<severity><message> is sent, the IT/O agent shows the right severity on the IT/O console and the message, but not on the MPE time-stamp and sender. The time stamp and sender information is not needed. So the staff that supports applications as well as the IT support people can use TELLOPs to inform Operations about specific actions to be done.
For example, in a database capacity check job we have this statement:
TELLOP OPC-MINORDatabase problem -
please beep (####).
Operations sees only the message
Database problem - please beep
(####)
with a color for a minor message, and knows exactly who to call. The instructions for each condition may also be used by configuring the filter conditions on the IT/O server. If you’d like a dump of the filter and its 49 conditions, send me an e-mail message.
Besides the normal and automatically generated console messages, we wanted to check some unwanted situations: background jobs which do not run; very critical job aborts; N/W bottlenecks (NETTOOL.NET.SYS); number of spoolfiles (since we have Unispool working at our site, we can only have up to 4,000 spoolfiles on the system); JobRescue spoolfile handling (from time to time this tool does not collect all $STDLISTs for a reason unknown to us). To accomplish this, a batch JCL called OPCCTRLJ was created, which feeds IT/O whenever such an unwanted condition exists on the box. You may e-mail me for this JCL as well.
After this effort on the test box, IT/O was installed on the other four HP 3000s (a 995/800, a 995/500, a 995/200 and a 980/100) using the same message filter, the same IT/O “feed” batch, and some command files around each. Since then we have made slight modifications on the filtering and add-ons to the OPCCTRLJ, and we spot problems with the 3000s earlier than our users. This is an obvious benefit to using IT/O. In the past, for example, a background job might not have been started, causing other problems. Putting IT/O to work with the HP 3000s hasn’t increased the workload in Operations, except during the installation and test phase before eliminating messages. Quite to the contrary – we now have the HP 3000s monitored by a minimum of messages, and the Unix message filters were also re-defined and reduced. Our Operations staff sees fewer messages, but only the most important ones from the HP 3000s, 9000s and RS/6000s. The main benefit: The staff no longer needs to execute specific command files to check our systems. All checks are implemented in the special OPCCTRLJ batch JCL.
I encourage you to use this open
solution which covers a lot of
different platforms. It really eases the
monitoring of HP 3000s
in an heterogeneous environment.
Andreas Schmidt is Senior Computer
Technology Analyst at Computer
Sciences Corporation’s Chemical, Oil
& Gas Group in Bad Homburg,
Germany.