You do not need to authorize any TSO command processors, because CA OPS/MVS provides authorization service while it is running. The only exception to this rule is when any CA OPS/MVS command executes in the address space of a TSO user while CA OPS/MVS is down.
The following table lists the TSO command processors that can be authorized. Both their primary names and their aliases must go into IKJTSOxx.
|
Command |
Alias |
Description |
|---|---|---|
|
OPSCMD |
OC |
Issue z/OS, JES2 or JES3, VM, and IMS operator commands |
|
OPSDOM |
None |
Delete a highlighted message |
|
OPSREPLY |
None |
Reply to WTOR |
|
OPSWTO |
None |
Issue WTO or WTOR messages |
The method used to authorize these TSO commands varies with the release of TSO/E you have installed.
You can set TSO command authorization from the appropriate IKJTSOxx member of the Logical Parmlib Concatenation. For an example, see member IKJTSO00 of SYS1.OPS.CCLXCNTL. You need to restart the system to make these changes effective unless you have CA SYSVIEW. If you have CA SYSVIEW, then you can use it to dynamically add these names to the TSO command tables without restarting the system.
Authorized programs or commands that are directly invoked from a REXX program can access variables created by REXX only if the variable names begin with SYSAUTH. This TSO/E restriction is only applicable if you use the TEXTVAR parameter of the OPSWTO command processor. For more information, see the IBM documentation.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|