Re: Sending a message in CL -- MIDRANGE-L

On 24-Mar-2015 10:32 -0500, John R. Smith, Jr. wrote:

I have program A that repeatedly calls program B with different
parameters (both are CLLE). Program B does its task based on the
parameter and then needs to send a message that will show up at the
bottom of the screen when program A is complete so we can see what
all happened by scrolling through the messages.

So the Program-A apparently either presents a Display File (DSPF) or a UIM object [e.g. Panel Group (PNLGRP)]?

I tried having Program B do a SNDPGMMSG *PRV *COMP and if I call
program B from the command line, it works.

So having eliminated the Program-A, apparently there is no longer a user-defined display [controlled by Program-A] at which messages are presented as presumed; i.e. my initial interpretation was apparently incorrect.

In the scenario involving just system command-lines, the messages will appear in the effective message subfile of the MENU or PNLGRP [maybe some DSPF too] of a system-supplied display that presents a command-line such as one of the programs QUSCMDLN, QUICMD, or QCMD.

However, when program B is called from program A, the messages never
show when program A is complete.

Those messages presumably still would appear in the joblog however, just not in the effective message subfile for the panel presented for the Command Line because they were not directed to the program invoked from that CmdLine.

Can anyone tell me which command and parms need to be used to have
program B send the message all the way back?

If the Program-B were part of an application and known to be called only by Program-A, then the specification essentially would ask that instead of sending messages to the *PRV relative to the (*) [the current stack entry], the Program-B should ask to send messages to the *PRV relative to the Program-A. When the Program-A is the driver of the application presenting the display\panel, that might be typical.

So instead of using the SNDPGMMSG TOPGMQ(*PRV (*)), the request might be composed as SNDPGMMSG TOPGMQ(*PRV (*PGMNAME *NONE Program-A)) [or possibly a variant of that for directing to a specific ILE procedure].

However more generically, the messages might be _moved_ to the message queue of the prior program; with a side effect that Escape messages will since appear as Diagnostic, but that is /normal/ behavior seen at system panels\menus. See:

<http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/qmhmovpm.htm>
_Move Program Messages (QMHMOVPM) API_
"...
The Move Program Message (QMHMOVPM) API moves messages from a call message queue in the call stack to the call message queue of an earlier call stack entry. Moving a message does not change the sender information stored with the message. However, moving an escape message automatically changes it to a diagnostic message.

You can use the QMHMOVPM API to pass messages up the call stack, transferring important information to a previous program. When messages are sent to a call stack entry and the program running in that entry ends without moving its messages up the stack, the programs left in the stack cannot receive those messages ...
..."

Sometimes all but the Exception message would be moved from Program-B to Previous and then an Escape would be directed from Program-B to Previous. In that scenario the Program-A as Previous would also move the non-Exception message to its Previous but then Resend the Escape message. See:

<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/QMHRSNEM.htm>
_Resend Escape Message (QMHRSNEM) API_
"...
The Resend Escape Message (QMHRSNEM) API resends an escape message from the current call stack entry to the previous call stack entry in the call stack or to any call stack entry that is earlier if the optional parameters are used. This API can also be used to resend an escape message from a call stack entry other than the current one.

You can use this API along with the Move Program Messages (QMHMOVPM) API to streamline exception message handling. If a call stack entry is sent diagnostic messages and an escape message but cannot handle the error itself, you can use the QMHMOVPM API to move the diagnostic messages. You can use the QMHRSNEM API to forward the escape message to the previous call stack entry in the call stack. The call stack entry does not need to send an escape message of its own. ...
..."