× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Program A is basically a CLLE script that pushes data around. There are
several "versions" of program A (program A2, program A3, etc.) that process
different groups of files.

CALL PGM(PROGRAMB) PARM('FILE1')
CALL PGM(PROGRAMB) PARM('FILE2')
CALL PGM(PROGRAMB) PARM('FILE3')
CALL PGM(PROGRAMB) PARM('FILE4')
CALL PGM(PROGRAMB) PARM('FILE5')

From what I have seen from responses, I'm going to make the caller review
the joblog because it does not appear to be possible to send it back to the
command line without additional code in program A and we want program A to
be clean and easily readable like shown above.

Thanks to all that responded. If anyone else has other ideas, let me know.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
CRPence
Sent: Tuesday, March 24, 2015 12:33 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Sending a message in CL

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/QM
HRSNEM.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. ...
..."

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.