Re: receiving message from QSYSOPR msgq

Arco Simonse wrote:

Sorry, I mixed answer and question and made a mess of the question. I should have asked: So the MSGID retrieved in this particular code is every time just only the last one that has
been put on the message queue?

IIRC non-exception messages are received in FIFO order, so the RCVMSG MSGTYPE(*INFO) would have always found the same, the first, informational message each time it was invoked. Thus since the RCVMSG invocation followed a SNDUSRMSG MSGTYPE(*INFO), the RCVMSG request should have been receiving that just-sent message every time. FWiW, that is why I noted [although I do not feel it is an appropriate attempt at /resolution/] that having coded RMV(*YES) would have seen the code operating similar to before having added the SNDUSRMSG; albeit then also waiting unnecessarily the coded twenty seconds on that message and with the additional side effect of having removed the message that was so recently sent.

And if I want to take the one before the last retrieved I should
use *PRV if I started with *LAST. Is that right?

Correct, that is one approach. Since the "restricted state" message CPF0968 is likely [but not guaranteed] to be the last message, then that is probably a reasonable approach for using RCVMSG; i.e. versus some other means like the QWCRSSTS API. However, either clear the message queue before the SNDUSRMSG or ensure to establish a limit for the loop to avoid searching beyond [i.e. prior to] that just-sent message. The approach I would choose if using RCVMSG, would be to use a send message interface that returns the key of the message sent, against which the key of the later received messages can be compared; e.g. using SNDPGMMSG KEYVAR(&K) TOMSGQ(*SYSOPR) instead of SNDUSRMSG

Regards, Chuck