Using QSYSMSG on your IBM i

By Rich Loeber

If you’ve been around the IBM i for any length of time, you already know that the system operator message queue, affectionately known as QSYSOPR, can be a melting pot of important and not so important information about your system operations.  This is helpful if your are diligent about carefully monitoring the message queue.  Unfortunately, in many shops, the queue does not get the respect it deserves and messages are frequently cleared, especially when they are not demanding an operator response of some sort.

This can lead to problems when important informational messages are processed but, since they don’t demand a response, get deleted before being recognized for what they represent.  A typical example might be the CPF0907 message.  The text for this message is “Serious storage condition may exist”.  Since the IBM i lives and literally dies on the availability of storage, a low storage condition should be a red flag for you.  If you miss this warning message, the results could be catastrophic.

Fortunately, there is a solution for this problem.

IBM’s i/OS has an optional secondary message queue that you can set up to catch critical messages.  When these critical messages are issued to the QSYSOPR message queue, the i/OS checks to see if the secondary queue exists on your system and, if it is there, a second copy of the message is also sent there.

To implement this optional feature, just run the following command on your system:

CRTMSGQ  QSYS/QSYSMSG TEXT(‘Optional MSGQ to receive specific messages’)

With the QSYSMSG message queue created in the QSYS system library, now specific critical informational messages will be duplicated to this secondary message queue.  By monitoring this additional message queue, you can catch important messages from the system and be assured of reacting properly to them.

The best way to do this is to set up a monitor for the message queue.  My company, Kisco Information Systems, has two such products available that include message queue monitoring capability.  SNDTWEET will relay these messages out to a list of contacts via Twitter.  Our WebReport/i software will do the same using email notices.  If you want to create your own monitoring program, you can find a sample program at the IBM Information Center.  Just search on your version of the i/OS for “QSYSMSG”.

To get a better idea of what kind of messages you can expect to intercept using the QSYSMSG message queue, here is a partial list of these important messages.  As you can see, many of these messages are security related, including devices that have been varied off-line because of illegal sign-on attempts, and call for a quick response:

Message ID    Description
CPD4070    Negative response received for remote location &5, device description &4.
CPF0907    Serious storage condition may exist.
CPF1269    Program start request received on communications device was rejected with reason codes.
CPF1393    User profile has been disabled because maximum number of sign-on attempts has been reached.
CPF1397    Subsystem varied off workstation.
CPF5244    Internal system failure for remote location &5, device description &4.
CPF5251    Password or user ID not valid for request for remote location &5.
CPF8AC4    Reserved library name &7 in use.
CPF9E7C    i5/OS grace period expired.
CPI091F    PWRDWNSYS &1 command in progress.
CPI0948    Mirrored protection is suspended on disk unit &1
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 &1 not operating
CPI0998    Error occurred on disk unit &1
CPI0999    Storage directory threshold reached.
CPI1117    Damaged job schedule &1 in library &2 deleted.
CPI1136    Mirrored protection still suspended.
CPI1138    Storage overflow recovered.
CPI1139    Storage overflow recovery failed.

And there are many, many more critical situations that can be monitored using this method.  Since it is so easy to loose these messages in the QSYSOPR message queue, setting up the QSYSMSG message queue and then monitoring it programmatically is a good practice for all IBM i shops.

Comments are closed.