Given what you say you can send a *INFO message to the *EXT message queue stating which item is being processed. If the program is run interactively the message will display on the screen and Enter must be pressed to continue.
If the program is run in batch the message will be in the job log.
Notification of what was processed accomplished in either case.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John R. Smith, Jr.
Sent: Tuesday, March 24, 2015 1:07 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Sending a message in CL
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.
--
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
