Re: Submitted job "job name" default to program name

On 13-Nov-2013 11:49 -0800, Scott Schollenberger wrote:

You might be able to use the technique of sending a program message
and then receiving it. The program name is part of the &SENDER parameter
information.
Scott Klement documented it in this posting:

http://iprodeveloper.com/rpg-programming/how-retrieve-programs-name-cl

If you also combined it with a RTVJOBA command and referenced the
&TYPE parameter/variable (Type = 1), you could test that the job is
an interactive job first.
Then issue the SNDPPGMMSG and RCVMSG commands, get the name from the
&SENDER variable and use it on the JOB parameter of the SBMJOB.
The CL program would submit itself.

Note the limitation on receiving the library name using that specific technique. If the command-line request were CALL MYLIB/THE_PGM, and all that the &SENDER reveals is the name THE_PGM, then how can one be sure the /correct/ THE_PGM will get submitted; i.e. the unqualified PGM() specification CALL THE_PGM [translates (library-qualified) to *LIBL/CALL PGM(*LIBL/THE_PGM)] is not necessarily going to effect the same as the original request: CALL MYLIB/THE_PGM

Then as a batch job (Type = 0), you skip the SNDPGMMSG/RCVMSG and
SBMJOB section of the CLP.

FWiW: Besides best to ensure getting the library name of the program to prevent any possible confusion and\or undesirable effects...

Although the concept of designing a CLP as submit-self-if-interactive is workable and often useful, and even if less easily accomplished, the possibility exists also from a non-CLP, doing so would likely require modifying the [design of the] programs from the scenario in the OP to implement that technique. If the programs are just [automated] test-case programs being called vs application programs being called, then probably making such a change is an option; though I would make a parameter available to override the behavior. However if application programs are getting tested directly by CMD(CALL...) via SBMJOB, then there may be no desire to force those programs to run in batch; possibly with hard-coded work management. Such changes are unlikely to be desirable for generic testing of programs by simple CALL invocations. And impossible to effect that change for a CALL of a program for which there is no source available; e.g. a call of a 3rd-party or IBM program\API might be /tested/ in that manner to verify its effects separately, such that the following might be desirable to have run as JOB(QSQXRLF):
SBMJOB CMD(CALL QSYS2/QSQXRLF (DLT MYLIB))