TAA Tools
SYSRQSCMD      ACCESSING COMMAND ENTRY FROM SYSRQS         TAAMSGE

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
					

Added to TAA Productivity tools April 1, 1995


Home Page Up to Top