Re: Problem receiving a message using qmhrcvpm

Robert Rogerson wrote:

CRPence wrote:

Or if the "passing 'ProgC'" implies the ProgD is logging
the noted SNDPGMMSG as "TOPGMQ(*SAME ('ProgC'))"

yes this is the case. In my original post

SNDPGMMSG MSGID(WDC0145) MSGF(TFMMSG) MSGDTA(' ')
TOPGMQ(*SAME ('WIM331')) KEYVAR(&W@MSGNO)

WIM331 refers to ProgC. ProgC (WIM331) is passing the program
queue name to ProgD which is then sending the message
TOPGMQ(*SAME ('WIM331'))

then probably the best fix is to just change ProgD to use
"TOPGMQ(*PRV (&PassedPgm))"

The vendor program WIM331 (ProgC in my scenario) mentioned above may be run interactively (so the error messages are displayed) or
in batch (where the messages are disregarded).

What I am attempting to do is call the program in batch but use the messages generated to give a better indication when an error
occurs. So my question is now if I changed ProgD to
"TOPGMQ(*PRV (&PassedPgm))"
as suggested would the message still be sent to WIM331 if run
interactively. Would it not be sent to the caller of WIM331?

The result would indeed be to have the message sent to the caller of the named program.

I have not done much interactive programming, so I suppose that the program sending a message to itself interactively might be desirable. In general however I expect that the caller is the target of any messaging, not the callee; i.e. if I code ProgB to call ProcC, I expect that ProgC or any program that it calls, will /percolate/ the messages back to my ProgB so my program ProgB can monitor for any exceptions and receive any of the diagnostic, informational, or completion messages.

If the recipient of the message must be ProgC when running interactively, then one possible solution would be to make the value of the "Relationship" element of the TOPGMQ() parameter dependent on whether the program is running in batch or interactively; see TYPE() parameter of RTVJOBA. I believe that would require IF\THEN\ELSE for two distinct SNDPGMMSG requests; although changing to use the send message API would allow variable specification. Of course less change to the vendor program is best; choose whichever is the lesser poison I guess ;-)

A worse solution [ugly and difficult to infer why it is coded that way] would be to make the change in ProgD to use *PRV relationship, but then also change ProgC to pass 'ProgD' [the called] program name when running interactively, and pass the 'ProgC' when running in batch.

Regards, Chuck