Hope this helps.

First, AFAIK, RPG programs usually don’t go into MSGW status. Let me explain my reasoning…

MSGW usually comes from one of three sources as far as RPG is concerned.

RPG can call the Receive Nonprogram Message (QMHRCVM) or Receive Program Message (QMHRCVPM) APIs with wait times, and those APIs can then go into a message wait state while the RPG is in a kind of wait for the API to return. Now, I’m pretty sure that’s not the kind of MSGW you’re interested in.

Or some function such as output to a printerfile can hit some system limit such as maximum spooled records, and that function can wait on an operator response for guidance on how to proceed. (The operator might be the requester.)

Finally, an actual error in coding might trigger an exception that isn’t handled by a condition handler, e.g., divide by zero. An inquiry message asking what option to take (e.g., ‘C’, ‘R’ or ‘D’) can be sent to an operator.

One of those last two would be likely for you because you likely know if the RPG is trying to process a program or non-program message queue or not. That is, you should know if message queue monitoring is part of the normal program function or not. If you don’t know, then it can get complicated because you have to retrieve enough job info to determine what kind of MSGW is going on.

In all three cases (AFAIK), the MSGW status is attached to the job rather than the program itself. So, you need to know first what job the RPG is running in. Then you need some secondary process (some secondary thread?) that can run while the RPG job is concurrently running. That thread can’t be blocked while the RPG job is running. It would periodically retrieve the job status and make decisions when MSGW showed up.

As for what it would do when MSGW was seen…?

Am I making any sense in this?

Tom