The System Request menu does not support an entry for accessing the
command entry display. This provides for both security and integrity
protection. There are however, some desirable programmer functions
which can be achieved if this is allowed.
You can achieve this function by using a special message queue and
using the system request capability to send a message to the message
queue. A break handling program is needed for the special queue.
You can either cause special functions to occur (e.g. WRKSPLF) or
just display the command entry display (QCMD).
Caution: There are exposures to interrupting a job and executing
commands within the same job. Be sure you understand the
exposures discussed later.
Assume you create a special message queue named XXXX and the break
handling program provided by this tool (TAAMSGEC in TAATOOL).
As part of your job, you would specify (This would normally be done
in an initial program):
CHGMSGQ MSGQ(XXXX) DLVRY(*BREAK) PGM(TAATOOL/TAAMSGEC)
While you are performing some function, you decide to access command
entry within the same job. The keyboard may be locked or unlocked.
You would press the System Request key (the special line at the
bottom of the display would appear) and then press enter.
The System Request Menu would appear and you would request option 5
and press Enter. The prompt for SNDMSG would appear. Press F10 for
additional parameters and enter:
SNDMSG MSG(X) TOMSGQ(XXXX)
The command entry display would appear. After you have performed
your function, press F3 to end. This will return you to the System
Request Menu. Press F3 to return to your normal function.
A better alternative is to enter the command directly on the System
Request Line such as:
5 X TOMSGQ(XXXX)
This would display the command entry display immediately. When you
are done with the command entry function, pressing F3 would
immediately return you to your normal function.
Sending the message causes the break handling program TAAMSGEC to be
invoked. It removes the message from the message queue and calls
QCMD which displays the command entry display.
In general, this function is not needed for many things that you can
do with a Group Job or the System Request option to transfer to a
secondary job.
However, the Group job or a secondary job cannot affect the
attributes of the job that is being interrupted. For example, things
that you can only do within a job include:
- Debug (Start, End, Set breakpoints etc.)
- Modify the library list
- Allocate and deallocate objects
- Modify objects in QTEMP
The debug case can be of particular value. It is possible to enter
into debug for a program which is already in execution. For example,
assume you call a program and it is either running or has presented a
display and is waiting for input. You can use the technique
described to invoke command entry and issue STRDBG, ADDBKP, etc.(You
can also use the TAA tool BKP).
Conversely, if you were using debug and forgot to end it and now use
SEU, you may be confronted with the message on the exit display which
says you cannot update the member because of debug mode (assuming
UPDPROD(*NO)). At that point, you can use the technique to access
command entry and enter ENDDBG.
The technique is similar to the use of an Attention Key Handling
program where you invoke a function directly rather than transferring
to a group job. For example, you could have an Attention key menu
where one of the options invokes command entry within the same job.
However, the use of the system request line allows you to interrupt
while a function is in operation (the keyboard is locked). The
Attention key can only be used when the keyboard is unlocked.
There are exposures with this technique relative to what function you
are interrupting and what commands you perform when you interrupt.
** Anytime you interrupt a program when it is not waiting for
input, you run the risk of retaining a lock on an object that
is needed for other users. This exposure is approximately the
same as transferring to a secondary job during the execution
of some function.
** There is an additional exposure which differs from the
transfer to secondary job function. When you transfer to a
new job, the new job cannot influence locks that are being
held in the suspended job. However, when you invoke command
entry within the same job on an interrupt basis, you are
exposed to changing functions that are normally not
anticipated by either user or system programs. In addition to
locks, this includes QTEMP, the library list etc. While
programs can be written to assume they will be interrupted,
hardly any program (user or system) will be written to protect
against a change in the environment in which it is operating.
Therefore, you should limit what you do during the interrupt
and avoid executing functions that may be in conflict with the
function that was interrupted.
Many of the functions that appear desirable to do on an
interrupt from a convenience viewpoint would be better off
done in a separate group job or secondary job.
You should only interrupt a function and execute commands in
the same job when there is no other alternative to achieve
your requirements.
** If you allow any user to change functions during the execution
of a job, there are also security exposures. If you are
interested in a secure system, you should prevent end users
from utilizing this technique and prevent programmers from
accessing production functions.
The break handling program operates independently of your job
relative to the use of program adopt. When the program gains
control, it is operating only under the user and any group authority.
The TAAMSGEC program shown ignores the message that caused the
interruption. It describes how to include special handling so that
you can send a 1 character code to perform special functions. For
example, you could use the following convention:
Message Function
text
S WRKSPLF
W Display your personal OUTQ
E End debug
Any other Call QCMD (Displays command entry)
For example, keying the following on the system request line:
5 S TOMSGQ(XXXX)
would cause WRKSPLF to occur.
To modify the TAAMSGEC program, you should copy the code to your own
library and create a unique program for your situation.
Another alternative would be to allow a full command to be entered on
the system request line. The message would be received and executed
using a call to QCMDEXC.
Use with group jobs
-------------------
The system will automatically transfer the workstation message queue
and the user message queue to a new group job. If you want to
transfer your message queue to achieve the System Request Command
function, you must name the message queue on the CHGGRPA command.
Prerequisites
-------------
None.
Implementation
--------------
None. To modify the tool, see the recommendations with CRTTAASRCF.
Objects used by the tool
------------------------
Object Type Attribute Src member Src file
------ ----- --------- ---------- -----------
TAAMSGEC *PGM CLP TAAMSGEC QATTCL
|
