When you are a one-man
administrator for a country-wide distributed network of over 10 aging AS/400s
that run 24x7 with very minimal operator interaction, it is no simple task to
constantly monitor all of them for potential problems. For one thing, events can
happen anytime and anywhere. Unless you perform hourly (or so) checkups on each
machine, you could easily miss out on critical warnings preceding a disaster.
However, if you do the hourly checkups, you won't have time for anything else.
In effect, you just downgraded yourself from an administrator to a mere
You can solve this dilemma by delegating the tedious--yet
critical--monitoring task to a non-human assistant. The solution consists of a
CL program that constantly monitors, in real time, the QSYSMSG message queue and
sends an email to the administrator(s) whenever an error message of interest is
This solution ensures that you have a 24-hour guard watching
over each AS/400 on which you have installed the program. You, the
administrator, need only keep your email client running, and you will receive
email alerts within minutes of any critical event.
Why monitor QSYSMSG?
Why not QSYSOPR?
There are reasons a-plenty:
The operating system loads only critical messages to QSYSMSG. So the CL
monitoring program will have fewer messages to process, and thus consume less
It is much easier to find specific messages in QSYSMSG rather than wade
through volumes of non-critical messages in QSYSOPR.
You avoid conflict with the occasional operator or programmer who wants to
reduce or clear the QSYSOPR message queue via F13 or F16.
Sooner or later, messages in QSYSOPR have to be purged. This is not the case
with QSYSMSG, where critical messages may be retained indefinitely. This is
particularly useful when you are analyzing the history of problems for the
particular AS/400. For example: Which particular disk unit has been failing
regularly, how often has it failed, and when was the last
Some Important Notes:
IBM created QSYSMSG to ensure that critical messages wouldn't get buried in
QSYSOPR and overlooked. However, the QSYSMSG message queue does not exist by
default. You have to create this yourself in library QSYS: CRTMSGQ QSYS/QSYSMSG Once
you've created QSYSMSG, the operating system automatically sends critical
messages to this queue.
This tip assumes that you already have AS/400 SNADS and email working.
In the main RCVMSG command, there is a "wait" parameter set for 180 seconds.
This is purely arbitrary. It only controls how often the program checks for a
controlled job-end condition.
There is no need to run this program in the QCTL subsystem. You may submit
this to QINTER, but if your operations require that QINTER be shut down once in
a while, I suggest that you create a separate subsystem for this program (and
others like it)..
If possible, send the email message to more than one person. You may be the
only administrator in the company, but it helps to have a close colleague who
can tap you on the shoulder in case you are distracted by something less
Once your AS/400's ASP threshold has been reached (CPF0907), email will
cease to function. Your message gets sent only after the disk utilization is
reduced below the ASP threshold! You need something to warn you before this
condition is reached. The solution is to set the following systems values as
illustrated: QSTGLOWACN =
*MSG QSTGLOWLMT = (100 minus
warning-threshold-limit) Example: If you have an ASP threshold of
90% and you want a warning message at 88%, you should
set QSTGLOWLMT = 100 - 88 =
12 Once your disk utilization reaches 88%, the system will send
CPI099C to QSYSMSG, which can be emailed well before the ASP threshold of 90%
Once in a while, especially if your ASP threshold has been reached, you may
have to reset QSNADS and QMSF; otherwise, your email won't
The message-ids that are monitored in this code are not all-inclusive. It is
up to you to add whatever other message-ids you wish to monitor (as long as you
know it is sent by the OS to QSYSMSG).
The sample code works, but it could do with some additional enhancements
(which I leave up to you). Some possibilities:
A routine to stop sending repetitive messages (e.g., CPI1165).
A routine to SNDMSG to selected users whenever CPF0907 is encountered. Once
the ASP threshold is reached, SNADS and email freeze up, but internal
message-sending still works.
If you have an administrative user profile other than QSECOFR, it would be a
good idea to include it in the CPF1393 monitored message.
You might want to consider incorporating pager or cell phone text
Sample CL Program to Monitor QSYSMSG Message Queue
In earlier years, Ric worked as a programmer analyst for a variety of IBM midrange machines. Most of his experience was with inventory systems for construction companies, book stores, and pharmaceutical distributors.
Since 1995, his experience has centered on operations support and systems management for a network of AS/400s. His passion is in developing automation software to ease the tedious day-to-dayoperations tasks, such as networked monitors for alerts, security logs, leased-line performance, UPS-shutdown/restarts, and disk-utilization. His most satisfying achievement is an automated source and object code change-management system that can work over any number of AS/400, iSeries, or System i systems.
Currently, Ricis a private contractor hired by a large IT company to perform and monitor operations over a large number of AS/400 operations for a big client.