On 27 Sep 2013 03:01, Jane Taubman wrote:
I have a custom menu program RPGLE (5250) which calls other RPG
programs using QCMDEXEC <ed: QCMDEXC> with the CALL command.
However when you look on WRKACTJOB they all show with the name
of the menu program, so you get pages of people in MEZ008. You can
of course see what program they are in using the display Call stack,
but it would help if the program they called was shown.
I seem to remember it's something to do with "invocation levels",
but I can't find anything with a Google search as I suspect I am
remembering it wrong.
Please could someone point me in the right direction.
Nothing directly to do with invocation levels, per se, nor Request
Processors. It is instead, the effect provided by whatever system
interface decides to update the job "Function". For example, a visited
menu updates the function to identify the MNU-name [as effected by the
MN\Menu component of the OS], a CL command-line CL command request
invocation updates the CMD-name [as effected by the CA\Command-Analyzer
component of the OS], etc. Including... The PGM-name appears whenever a
CL CALL command invokes a program [likely also, _as effected by_ the
CA\Command-Analyzer component of the OS], but *only* as an /effective/
command-line program-call; i.e. a CALL coded in a CLP or a CALL invoked
within QCMDEXC will *not* effect that same update to the job "Function".
However, there is a /simple/ resolution; "simple" being a relative
term :-) Change from using the QCMDEXC API to using the more robust
QCAPCMD API. The latter API offers more function, including the
capability to perform the CL request as an effective Command Line
invocation. Thus the same component that recognizes the command-request
as a command-line invocation will perform its normal function of
updating the job's "Function" to reflect the PGM-name. Note
specifically, the /Type of Command Processing/ of x'00000002' in the
following documentation; both its functions and its potential caveats or
limits, although all are probably typically acceptable or positive effects:
http://pic.dhe.ibm.com/infocenter/iseries/v6r1m0/topic/apis/qcapcmd.htm
_i Process Commands (QCAPCMD) API i_
"...
Type of command processing. The type of command processing to be
performed by the system. The following processes can occur:
0 Command running. The processing for this type is the same as
that performed by the QCMDEXC API. Commands processed must have a value
of *EXEC on the ALLOW parameter of the Create Command (CRTCMD) or the
Change Command (CHGCMD) command.
1 Command syntax check. The processing for this type is the same
as that performed by the QCMDCHK API.
2 Command line running. This processing is like that provided by
the QCMDEXC API but with the following additions:
* Limited user checking is performed.
* Prompting for missing required parameters is performed.
* If the System/36™ environment is active and the commands are
System/36 commands, the System/36 environment runs the commands.
This type processes commands with entry codes of Job: I (value of
*INTERACT on the ALLOW parameter of the CRTCMD or CHGCMD command). While
this type is meant to implement an interactive command line, it can be
used in batch. When used in a batch job, the entry code for the command
must be Job: B. Limited user checking and System/36 environment
processing is done while prompting options are ignored.
..."
FWiW: To effect a quick test, compare the difference between the two
invocations; having chosen a MYLIBRNAME/MYPGM_NAME that either goes into
a wait state or which can be stopped in debug via a serviced job, long
enough to review the effect in Work With Active Jobs:
call qsys/qcmdexc ('call MYLIBRNAME/MYPGM_NAME' 26)
/* effects PGM-QCMDEXC from a menu or command-entry */
call qsys/qcapcmd ('call MYLIBRNAME/MYPGM_NAME' x'0000001A'
x'00000002F0F0F000000000000000000000000000' x'00000014'
'CPOP0100' ' ' x'00000000' x'00000000' x'0000000000000000')
/* effects PGM-MYPGM_NAME irrespective whence */
midrange.com
