AntiVirus

Protection for IBM i, AIX & Linux. 01

Messenger

Monitoring, notification & consoling. 02

Security

Security monitoring & audit for IBM i 03

RecycleBin

File protection & instant recovery. 04

QSYSMSG message queue

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.