As you discovered, you can’t allocate QSYSOPR in order to receive messages from it because it’s already allocated somewhere else. (Perhaps at the console where QSYSOPR might be logged on!)
That’s a simple fact of monitoring message queues. Only one job can “receive” messages from a given message queue.
The problem is that your program needs to see messages pretty much as soon as they arrive. There are only a couple ways to do that.
<li>You can WAIT(n) on messages to arrive. The WAIT() time would depend on what you want to do in other parts of your program. As each arrives, you decide if it’s one for you and handle it if it is.</li><li>You can periodically wake up and check to see if anything has shown up since you last looked. You would need to ignore any messages that were handled by someone else. You would likely use WAIT(0) in this case. Most of the time your program would be in DLYJOB until it’s time to wake again.</li>
Either way, an allocation is automatically made to this job. In the first case, the allocation is going to last just about the whole time your program runs… assuming you can get it in the first place. In the second case, the allocation should only last for as long as your program is actually handling a message. The allocation must still be allowed — the message queue can’t be allocated elsewhere, e.g., to an interactive session *BREAK mode.
In other words, don’t expect to be able to handle QSYSOPR unless you also provide a way for QSYSOPR to be handled by any other job that needs it. That can get complicated.
Maybe you should consider not having these messages go to QSYSOPR in the first place. Have them go to a message queue that you create for just this purpose. Then you might have your program receiving all of these messages, handling the ones that you want and relaying others perhaps to QSYSOPR as a kind of notification message. (Lots of possibilities once a program is in the mix.)