1. 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.
2. It is much easier to find specific messages in QSYSMSG rather than wade through volumes of non-critical messages in QSYSOPR.
3. You avoid conflict with the occasional operator or programmer who wants to reduce or clear the QSYSOPR message queue via F13 or F16.
4. 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:

1. 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.
2. This tip assumes that you already have AS/400 SNADS and email working.
3. 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.
4. 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)..
5. 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.
6. 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.
7. 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!
8. 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).
9. The sample code works, but it could do with some additional enhancements (which I leave up to you). Some possibilities:
10. A routine to stop sending repetitive messages (e.g., CPI1165).
11. 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.
12. If you have an administrative user profile other than QSECOFR, it would be a good idea to include it in the CPF1393 monitored message.
13. 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.