On 12-Sep-2014 14:15 -0500, Gqcy wrote:
On 9/12/2014 2:05 PM, Gqcy wrote:
in our QINTER subsystem, we have an entry:
Seq Nbr Program Library Compare Value
9999 PGMEVOKE QGPL *ANY
and that program does a RTVUSRPRF of INLPGM and INLPGMLIB
and then does a:
TFRCTL &INLPGM.&INLPGMLIB
program and entries were created back in 1987, I am sure it was
just migrated from s/38....
is this process redundant?
if I would remove the routing entry, would the signon process and
job start process work the same?
sorry,
Not _remove_ that 9999 routing entry, but change it to:
Seq Nbr Program Library Compare Value
9999 QCMD QSYS *ANY
So: CHGRTGE SBSD(TheSbsdLib/QINTER) SEQNBR(9999) PGM(QSYS/QCMD)
The effect of the user program PGMEVOKE [as described] is slightly
different than what QCMD would effect as a routing program. The
differences may not be noticed by any interactive user routed via that
Routing Entry (RTGE), even if that change were made. Possibly, no user
profile has their Routing Data (RTGDTA) [in their Job Description
(JOBD)] that would effect anything other than Program To Call (PGM)
being QCMD; in that case, no UsrPrf will notice any difference, because
they already experience QCMD as a routing program.
The effects from ensuring QCMD will be the routing program as the
catch-all, instead of the user program, are likely only positive [except
possibly if the QDSIGNON allows, the change would allow users to start
overriding\specifying the Initial Program]. One potential caveat to the
currently defined routing program, is that as a catch-all, the routing
program does not make any decision based on the job being activated as
Interactive versus Batch [or ¿any other job type that uses the
routing?]; the Retrieve Job Attribute (RTVJOBA) [or a similar API] for
the Job Type (TYPE) indicator variable might be appropriate, given the
general assumption that the INLPGM establishes only an interactive
environment, to decide if appropriate to even invoke the initial program.
While the user-defined routing program currently does the calling of
the Initial Program (INLPGM) just as does QCMD, though the program that
is called [actually: program to which control is transferred] will only
ever be defined by that INLPGM() attribute of the User Profile. That
user-defined program however, does not similarly:
• CALL the initial program, as specified on the sign-in display, or
as specified on the user profile if no value came from the Sign-on
Display File (SGNDSPF) of the Subsystem Description (SBSD)
• establish\activate the Attention Program (ATNPGM); that can be
added using Set Attention Program (SETATNPGM)
• establish the Special Environment (SPCENV); that can be done using
Start S/36 Environment (STRS36) [¿only as the effective last request
though?]
• set the Initial Menu (INLMNU); that can be done using Go To Menu
(GO) [¿only as the effective last request though?]. Using QCMD also
allows establishing the Initial Menu specified\overridden at the Signon
screen if that capability is defined in that display file.
On a production system, I would ensure [via auditing] that the
current catch-all [the /otherwise/] routing entry is not being used,
before making that change. If currently the PGMEVOKE in QGPL is being
used by anyone for their [interactive] routing, then I would verify with
at least someone of those, that they will see no negative effects having
made that change; /the change/ in this case, for testing purposes,
instead of the Change Routing Entry (CHGRTGE) request to change the
Subsystem Description (SBSD), would be done with a Change Job
Description (CHGJOBD) request to limit the effect to just those users
who would be testing the effects of the proposed change [in advance of
the subsystem change], such as probably the request:
CHGJOBD JOBD(TheJobdLib/UsrPrfJobD) RTGDTA('QCMDI')
<
http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/rzaks/rzaksintactvjbroutingcontrol.htm>
_Programs that control the routing step_
"To determine the best approach for a particular job, you must first
determine which program should control the routing step.
_Using QSYS/CMD for interactive jobs_ - benefits [sic: ed: QSYS/QCMD]
...
_Calling a user program directly for interactive jobs_ - benefits
..."
midrange.com
