Re: Problem receiving a message using qmhrcvpm

[CRPence <CRPbottle@xxxxxxxxx>]

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