Creating a message queue called QSYSMSG in library QSYS will cause OS/400 to automatically send certain critical messages to this message queue. This will allow you to respond quickly to what may be a serious condition. 7 shows a sampling of some of the messages that will be routed to QSYSMSG. Simply create the message queue with the following command:

Creating a message queue called QSYSMSG in library QSYS will cause OS/400 to automatically send certain critical messages to this message queue. This will allow you to respond quickly to what may be a serious condition. Figure 7 shows a sampling of some of the messages that will be routed to QSYSMSG. Simply create the message queue with the following command:

CRTMSGQ MSGQ(QSYS/QSYSMSG)

So why create a special queue for this purpose? First, you might wish to isolate the most critical messages into this message queue. OS/400 does this automatically for you as soon as you create the queue. Second, you can put your interactive session into *BREAK delivery mode on the QSYSMSG message queue and be interrupted with a break message only if a serious problem arises. There is a discussion of QSYSMSG in the AS/400 CL Programmer's Guide, which has a sample program and a list of messages sent to QSYSMSG.

You might want to write a program to process these very serious messages. Why would you want to write a program instead of just putting your interactive job into *BREAK delivery mode on QSYSMSG? Probably the best reason is to ensure that these very critical messages are sent to interested parties as early as possible. Let's say that the system operator normally comes to work at 8 a.m. But today, he will be late and won't arrive until 10 a.m. Your program should have a list of user profiles and should try to send break messages (perhaps using the SHOUT command from QUSRTOOL) to someone on the list. If no one is available, the program should put itself to sleep and wake up every so often (perhaps once every 30 seconds) to try sending break messages again to interested parties.

The other reason for the program is to route these messages to QSYSOPR. When you create QSYSMSG, these very critical messages are sent only to QSYSMSG. A program could also send these messages to QSYSOPR-a good idea since the message is then logged in the history file which can be used for future reference. Finally, maintaining messages of this magnitude in two different message queues provides additional insurance that the problem will be noticed as early as possible.

IBM has provided the QSYSMSG mechanism to help isolate critical problems on our machines. When you create the QSYSMSG message queue, you can help to ensure that your system operator's interactive session is interrupted with break messages primarily when critical problems surface-and not every time a new message arrives in QSYSOPR. If you do decide to create the QSYSMSG message queue, you should consider writing a message-handling program to help ensure that interested parties are informed of potential problems as early as possible.

The QSYSMSG Message Queue

Figure 7 Sampling of Messages Sent to QSYSMSG Message Queue

 CPF0907 SERIOUS STORAGE CONDITION MAY EXIST CPF1269 PROGRAM START REQUEST RECEIVED ON COMMUNICATIONS DEVICE WAS REJECTED WITH REASON CODES CPF1397 SUBSYSTEM VARIED OFF WORK STATION CPI0920 ERROR OCCURRED ON DISK UNIT CPI0950 STORAGE UNIT NOW AVAILABLE CPI0953 ASP STORAGE THRESHOLD REACHED CPI0954 ASP STORAGE LIMIT EXCEEDED CPI0955 SYSTEM ASP UNPROTECTED STORAGE LIMIT EXCEEDED CPI0964 WEAK BATTERY CONDITION EXISTS CPI0965 FAILURE OF BATTERY POWER UNIT FEATURE IN SYSTEM UNIT CPI0966 FAILURE OF BATTERY POWER UNIT FEATURE IN EXPANSION UNIT CPI0970 DISK UNIT NOT OPERATING CPI0988 MIRRORED PROTECTION IS RESUMING ON DISK UNIT CPI0898 MIRRORED PROTECTION RESUMED ON DISK UNIT CPI0992 ERROR OCCURRED ON DISK UNIT CPI0996 ERROR OCCURRED ON DISK UNIT CPI0997 NEARLY ALL AVAILABLE MACHINE ADDRESSES USED