Operations › Restrictions on OSF Processing Requests

Restrictions on OSF Processing Requests

You should be aware of certain restrictions that can affect OSF operations. These restrictions apply to OPS/REXX programs, TSO commands, and TSO/E REXX programs or CLISTs that the OSF executes:

• Because the TSO TMP executes in batch mode, the OSF ignores TGET/TPUT requests.
• The OSF returns only those PUTLINE requests that typically would be printed to the SYSTSPRT file.
• Any GETLINE request that typically would result in additional input being read from the SYSTSIN file will cause termination of the TSO command or TSO CLIST that is executing.
• By default, any user settings maintained in the UPT or PSCB are used when an OPSOSF server executes a command. For example, a PROF LIST command executed by an OPSOSF server will reflect the same settings as the user who issued the PROF LIST command.

  Similarly, authorization for the SUBMIT command is carried over from the user who issued the command to the OPSOSF server that will execute it.

• Do not include LOGOFF commands in requests that you want the OSF to process. If you do, then unnecessary termination and restart of the server occurs.

  If the value of the OSFGETJOBID parameter is set to YES, and CA OPS/MVS is running under the master subsystem, then you may include SUBMIT and STATUS commands in your requests.

• Avoid commands that issue long operating system waits, because this ties up the OPSOSF server. If you have a problem that calls for a long wait (for example, if you need to carry on a dialog with the operator), then we suggest you do the following:
  • Create a batch job or started task to run the procedure.
  • Log a console on to the ECF and run the command in the OPSECF address space that is associated with the console.
  • Log on to TSO and run the command under the TSO address space.
  • Create your own OPSVIEW dialog that runs the command under TSO.
  • Use the OPSPARM command in the procedure to dynamically increase the number of OPSOSF servers by one when the procedure begins executing, and decrease the number of OPSOSF servers by one when the procedure finishes its execution.