By Rich Loeber
Updated September 1, 2020
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 you 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. I continue to be surprise that so many IBM i shops do not use this feature in the OS.
To implement this optional feature, just run the following command on your system:
CRTMSGQ MSGQ(QSYS/QSYSMSG) TEXT(‘Optional MSGQ to receive specific messages’)
With the QSYSMSG message queue created in the QSYS system library, 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 an affordable event monitoring software product called iEventMonitor that will watch a message queue and issue alerts by email, text or break message. 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 lose 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.
If you have questions about details of this tip, feel free to contact me directly by email: rich at kisco.com.