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
watchdog.
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
detected.
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
CPU cycles.
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
failure?
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
critical.
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%
is reached.
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
move!
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
messaging.
--Ricardo P.
Ang This email address is being protected from spambots. You need JavaScript enabled to view it.
Sample CL Program to Monitor QSYSMSG Message Queue
Just do it! Got a tip that makes you a star? Send it to This email address is being protected from spambots. You need JavaScript enabled to view it.
Ricardo Ang
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.
This book provides an amazingly comprehensive introduction to the concepts while at the same time delivering enough technical detail to make you productive very quickly.
Today, it's all about input and output. Getting data into the IBM i from non-traditional sources and then displaying it back out again in varied formats. But where can you go to learn all that you need to know about this critical skill?
Too valuable to be classified as merely excellent certification material, this book should also rightly take its place on DB2 DBA bookshelves as a solid day-to-day DB2 reference.
Whether you want to obtain an IBM certified DB2 professional certification or simply become well-rounded in the fundamental concepts of DB2 and general database theory, this is your book.
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from.
>> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online