I have received some great suggestions on this but I was hoping it would be
something simple like a had parms wrong. I guess not.
I like the module idea but I also run this occasionally for a single file if
I correct data and need to resend just that file. I'm not sure how I would
do that if program B is a module. I guess I would have to create another
version of program A that receives the file as a parm.
Since this is an IT function that will be run once or twice a month at the
most (and the person running it can sometimes be a jerk), I'm going to go
with it as is and have the joblog review be the solution if there are
questions on what was sent.
Thanks again for all of the ideas.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
CRPence
Sent: Tuesday, March 24, 2015 3:52 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Sending a message in CL
On 24-Mar-2015 11:59 -0500, John R. Smith, Jr. wrote:
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.
If updating the Program-A variants would not be too troublesome, then
perhaps the addition of just *one* final request would leave the source code
sufficiently /clean and easily readable/. That one request could move all
of the messages to the previous program message queue. The additional
statement could even be the Include CL Source (INCLUDE), ensuring the
identical statement is included for each; e.g. after all of those successive
CALL statements, the following could be inserted:
INCLUDE SRCFILE(INCLUDELIB/CLSRC) SRCMBR(MOVMSGSUP2)
The CL source in that source member could be [though probably better
documented as to what is called and why, plus what are the arguments being
passed]:
call qsys/qmhmovpm +
(' ' '*COMP *DIAG *INFO *ESCAPE ' +
x'00000004' '*' x'00000002' x'0000000000000000' )
The above coding to move messages up two levels is to get the messages
moved beyond the PEP; i.e. past the _CL_PEP entry that is between the
procedure [of the name of the bound CL program] and the invoker.
Or perhaps instead [but as a similar additional command\statement] that
would help to satisfy "to make the caller review the joblog", insert as the
last common statement in all variants of Program-A, the sending of a message
to remind\suggest "Review the joblog."; e.g.:
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) +
MSGDTA('Review the joblog for results') +
TOPGMQ(*PRV) MSGTYPE(*COMP)
<<SNIP>> If anyone else has other ideas, let me know.
I personally would avoid doing so, but the capability exists to obtain
the program name of the invoker. Retrieved within the Program-B, the
SNDPGMMSG request performed in Program-B could be modified to use that
information to request to send the message directly to the invoker of the
since-identified immediate invoker; i.e. TOPGMQ(*PRV (*PGMBDY *NONE
&who_invoked) which is much like I offered before, but in this case because
&who_invoked is known not to be static, the value would need to be
determined at run-time.
<
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/qwvrcstk.htm>
_Retrieve Call Stack (QWVRCSTK) API_
A [probably even less desirable option] would be changing both the
Program-A variants and the Program-B to be modules instead of bound
programs, and then sending the messages to the *PRV to the *PGMBDY or
*CTLBDY. That would not only require creating Program-B as a *MODULE
instead of a bound *PGM object, but would require changing the invokers to
use the CALLPRC instead of the CALL; then how the variants of Program-A are
created\compiled would either radically change or perhaps created using the
Declare Processing Options (DCLPRCOPT) to specify the binding. The source
for the Program-A variants would look something like the following, wherein
no additional moving of messages nor a separately coded messaging suggesting
to review the joblog would be required because the messages would be
directed properly:
CALLPRC PRC(PROGRAMB) PARM('FILE1')
CALLPRC PRC(PROGRAMB) PARM('FILE2')
CALLPRC PRC(PROGRAMB) PARM('FILE3')
CALLPRC PRC(PROGRAMB) PARM('FILE4')
CALLPRC PRC(PROGRAMB) PARM('FILE5')
--
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.
midrange.com
