Re: MONMSG issues

The code snippet I gave in the prior message expects to be run as its own separate program\procedure [ideal], or only just after prior messages in the same program message queue were cleared [sometimes acceptable]. I failed to make that point clear in my message and in the code snippet itself. But MMurphy replied to warn of that unstated dependency of the algorithm, in the following message [which had its subject corrupted]:
# Subject: [SPAM] Re: MONMSG issues
# From: "Mark Murphy/STAR BASE Consulting Inc." <mmurphy...
# Date: Thu, 21 Feb 2013 09:28:28 -0500
http://archive.midrange.com/midrange-l/201302/msg00954.html

So if the algorithm is coded inline with other work, and if prior messages in the program message queue are not needed, then the GRTOBJAUT request can be preceded by the following request which will prevent the RCVMSG MSGTYPE(*DIAG) from getting Diagnostic messages that were from requests made before the grant request; review the CLEAR and other parameters of the RMVMSG command to choose what effects are most desirable:
RMVMSG PGMQ(*SAME (*)) CLEAR(*KEEPUNANS /* or *ALL */)

If the algorithm is neither separated into its own call level nor the prior messages removed, as Mike warns due to the FIFO effect of the request to RCVMSG MSGTYPE(*DIAG), the algorithm would need to change to get ordered messages, but then require a change also to ignore the non-Diagnostic messages such as the Informational messages showing what was granted. However that also means the algorithm needs to adjust to know when to stop getting messages :-(

FWiW there is the very undesirable option of ignoring each received Diagnostic that was either not in the 22## range or not sent by QSYGRAUT when using MSGTYPE(*DIAG), if the prior activity in the program for which messages have not been removed were not also /grant/ activity. I only mention that in case someone considers it; by reading this, they can know that doing so is really poor programming :-)