On 01-Jun-2011 10:30 , Rich Loeber wrote:
A customer was installing some software while in restricted state.
They ran into a minor problem that could have been corrected by a
simple file rename, but they could not get a second logon session
started.
Is there a way, while in restricted state and running from the
console, to get to a command line while a job is active on the
console?
As Mark suggested, the ATNPGM() defined for the user profile or as
[re]defined at the current call level via SETANTPGM is the typical
choice for resolving the issue that is described. That feature allows a
user to get to a new call level [and sometimes group jobs], but only
when the session is neither input inhibited nor prevented from
processing events; specifically, the attention [Attn key] event.
Roger mentioned CPX2313, so I will suggest to avoid changing that
message in QSYS/QCPFMSG or any of QSYS29##/QCPFMSG message files. Also
I recall that there is a System Request exit point which may be more
appropriate to use. The message data is AFaIK just an "implementation
detail" which would be subject to change. While changing the message
remains functional to change the behavior of the System Request
Option-3, changing the DSPJOB to WRKJOB [or to any command-line capable
zero-parameter callable *PGM], the capability to get WRKJOB versus
DSPJOB within restricted state is no different than outside of
restricted state processing. To make the effect available to an
operator, or at the console, then perhaps:
For an operator that either understands call levels or would not
become confused having added call levels [such that they would not
understand how to return] *and* understands the implications of
performing possibly conflicting work while interrupting a task in
progress, if they have activated a request to get a command line while
the job is input inhibited....
Then as part of entering restricted state [e.g. requests to ENDSYS
and ENDSBS *ALL; note that CHGIPLA used to enter into restricted would
not be covered] can be directed to CALL the following CLP, or added [by
CHGRTGE or ADDRTGE] as part of the routing into the controlling
subsystem defined by QCTLSBSD while using device defined by QCONSOLE,
include a CALL to the following CLP:
<code>
// data file(inline_src) filetype(*src) endchar('//ENDINLINE_SRC')
dcl &msg *char 160 /* no recollection verifying this length */
/* more DCLs for controlling subsystem and\or console name? */
affected:
/* determine if this job is to be enabled for this feature */
/* RTVSYSVAL as necessary, RETURN if this job not allowed */
/* -- this "affected:" section is purposely left un-coded -- */
activate:
/* give this job access to CmdLine of WRKJOB via SysReq-3 by */
/* changing DSPJOB to WRKJOB in a copy of the message which */
/* by current implementation controls the SysRqs-3 *CMD name */
crtmsgf qtemp/qcpfmsg
monmsg CPF2112 exec(goto ya_called)
mrgmsgf qsys/qcpfmsg qtemp/qcpfmsg select(cpx2313)
rtvmsg msgid(cpx2313) msgf(qcpfmsg) msg(&msg)
chgvar %sst(&msg 12 10) 'WRKJOB' /* blind assumption\action */
chgmsgd cpx2313 msgf(qtemp/qcpfmsg) msg(&msg)
ya_called:
ovrmsgf qcpfmsg qtemp/qcpfmsg
rmvmsg pgmq(*same) clear(*all) rmvexcp(*yes)
tfrctl qcmd
//ENDINLINE_SRC
dltpgm sysrqscmdl
crtclpgm sysrqscmdl srcfile(inline_src) log(*no) usrprf(*owner) +
aut(*exclude) alwrtvsrc(*no) /* best to obfuscate? */
chgobjown sysrqscmdl *pgm ( usr_aut_to_CRTMSGF ) curownaut(*revoked)
/* Effectively any user authorized to CRTMSGF can do this AFaIK */
/* i.e. all of the commands used in the CLP are *PUBLIC *USE ? */
/* excluding authority to CRTMSGF or CHGMSGD might be desirable */
/* to prevent any user from utilizing this same algorithm even */
/* outside this program; then GRTOBJAUT to owner of this *PGM */
</code>
p.s. While the authority for the *MSGF QCPFMSG was eventually
corrected from *CHANGE to *USE preventing any change message description
by all of *PUBLIC, and thus also preventing this feature from being
activated directly from a *NLVLIBL/QCPFMSG message file, AFaIK the
capability of the above algorithm remains generally available to
*PUBLIC. The more "public" this capability becomes, the more likely
someone will complain about the availability, and thus more likely that
the "implementation detail" will be sufficiently changed so as to make
the algorithm [and so the above program] obsolete. Apologies in
advance, to myself first, since I have relied tremendously on this
capability being available generally. I am unsure, but I believe the
last I used the algorithm with success was on v6r1; for sure on v5r4.
Regards, Chuck
midrange.com
