The first step must be determining the cause of the *MSGW status because that status can arise from two different conditions.
- A job may send a message that requires a response.
- A job may issue RCVMSG (or call the QMHRCVM API) against a non-program message queue.
Both of those will put the job in *MSGW, but you should only be interested in the first condition. You need to know when to ignore the second condition.
Further, even for the first condition, there won’t necessarily a useful MessageID. It might simply be an impromptu message:
SNDUSRMSG MSG('Enter some reply (y/N)?') VALUES(Y N)
From a batch program, that would show CPA2401in QSYSOPR (or whatever message queue was assigned.) It would also show CPA2401 as the ‘sender copy’ in the joblog of the batch job.
In general, you would use the List Job Log Messages (QMHLJOBL) API to see what messages have been sent within a job. You would need to use the Open List of Job Log Messages (QGYOLJBL) API (and the associated Process Open List APIs) if the joblog messages exceeded a user space limit.
You first find a job in MSGW status. You then run through its messages to see if the MSGW status came because of an *INQ (Inquiry) message. That means that an *INQ has been sent but not yet replied to. (You need to skip over and ignore any that have previously been answered.) If no unanswered *INQ messages exist, then it’s not a MSGW job that you’re interested in.
When you find an unanswered *INQ message, you’ll be able to extract the related message identifier. Be aware that the message might have been answered between the time you resolved the joblog messages and the time you located a message of interest to you.
These are not trivial APIs. If you run into specific problems, it will be best to create a new question and include code for comment.