Answer Wiki:
In a CL program, you can use the RCVMSG command to read the messages in QSYSOPR.
A simple program to monitor for messages would be something like this:
PGM
DCL &MSG *CHAR 128
LOOP:
RCVMSG QSYSOPR WAIT(*MAX) MSG(&MSG)
your logic here - Either within this CL or call a program with &MSG as a parm.
GOTO LOOP
To see all answers submitted to the Answer Wiki: View Answer History.
The one issue you will run into using RCVMSG is it allocates the object… Also what apps are you referring to? They may be an alternative to using QSYSOPR… -John Andersen
First, there should not be any messages from “custom apps” in QSYSOPR. But you probably can’t do anything about that.
No matter what, you are going to have an “agent on box” (well, unless you pay someone to watch QSYSOPR and manually enter messages somewhere else). You can program the agent yourself, or you can use a 3rd-party agent. For simple work, you can program the “agent”.
But most likely you won’t want to. For a system message queue such as QSYSOPR, it’s not as easy as just using RCVMSG. E.g., as noted above, the automatic allocation of QSYSOPR ensures that no other process can be using the message queue. That means that you can’t even have a logon that has QSYSOPR messages breaking at a workstation as long as the “agent” needs to be running. I.e., you can’t have two processes monitoring QSYSOPR at the same time.
If you are not already familiar with methods of message queue monitor programming, you’re likely to run into conflicts that can take possibly days to resolve while you learn the concepts and the programming. I assume you have a business reason for doing this and for mentioning an “agent” in the first place.
Tom
At a former employer we used ACOpager from DDL systems to monitor message queues, qsysopr, qhst, etc. Fairly cheap(cheaper than others) and easy to setup. It also featured a reply list, ‘ignore’ list for messages. There may be a way to copy new or un-answered messages to a file and let a program read through the file for specific messages. When this process executes, you could remove any un-needed messages. Of course, the best way would be to make your application messages go to another queue or file instead of QSYSOPR then you could still look for messages from your apps without locking qsysopr or removing messages from there. The reason I say this is I’m not sure how large the qsysopr message queue will get on your system before it wraps or is cleared.My two bits.Nick
The reason I say this is I’m not sure how large the qsysopr message queue will get on your system before it wraps or is cleared.
The maximum size of a *MSGQ is 16MB. QSYSOPR should have the default set by IBM. But the queues usually don’t actually hold “messages”; they usually hold message IDs, some minimal replacement values and various definition fields. What you see when viewing the queues is the interpreted content. They can appear to be much larger than they are.
…without locking qsysopr or removing messages from there.
“Removing” (or more likely not removing) messages is one fun part of RCVMSG. The handling of ‘old’ or ‘new’ messages when a message monitor is restarted takes practice. The content of QSYSOPR can be cleared real fast if not done right. Messages can also be processed multiple times after restarts.
For a system message queue, there are various things that can go wrong. Finding problems a week or a month or more later can be messy.
Tom