Is message queue QSYSMSG still viable at releases V6R1 and above
With all the new technology is message queue QSYSMSG still viable at releases V6R1 and above
Software/Hardware used:
8204-E8A - V6R1
Software/Hardware used:
8204-E8A - V6R1
ASKED:
January 7, 2011 8:24 PM
UPDATED:
January 9, 2011 3:06 AM
Answer Wiki:
QSYSMSG is viable at least through i 7.1 with no indication that it will ever not be viable. Many of the messages that the system sends to QSYSMSG are duplicated in QSYSOPR. Some messages are sent to both message queues. There are messages that will only be sent to QSYSMSG when the related SRC is appropriate.
New technology is kind of irrelevant. QSYSMSG exists in order to avoid lock conflicts with QSYSOPR and to provide a less cluttered view of the critical system messages that may be sent. Some of the messages that the system may send are caused by hardware failures that new technology will be unlikely to work around.
For example, technology has some trouble with CPF510E, "Network interface &9 failed while doing a read or write to device &4." Or CPF5342, "Line &9 failed on device description &4, remote location &5." When network interfaces or communications lines are failing, it can be tough sending anything anywhere outside of the system.
Tom
To see all answers submitted to the Answer Wiki: View Answer History.
Also, does this message get sent to any other message queues if QSYSMSG has not been created? I am with a new company and being the new guy I don’t want to make waves. I have always created the QSYSMSG message queue on every system I have worked on but currently working as a contractor I don’t want to step on toes or cause problems. I just don’t understand why anyone would not create the QSYSMSG message queue because of the benefits. This was something I learned early on working with IBM engineers over 20 years ago. Is this still good practice or have I lost touch?
Is this still good practice or have I lost touch?
Also, IMO, it is indeed good practice to create the QSYS/QSYSMSG message queue and then to monitor it. Even if the QSYSOPR message queue isn’t expected to be allocated somewhere else, having QSYSMSG already prepared is good preparation for when it might be needed unexpectedly.
Tom