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')
midrange.com
