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

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].