SET

Purpose

Use the SET command to:
  • List information related to RRSF on the local node
  • Specify the name of a member of the RACF® parameter library to be processed by RACF
  • Set tracing on or off for specified RACF subsystem facilities
  • Specify and enable options for automatic direction
  • Improve performance for generic profiles by specifying options for generic anchors.

After an IPL, all SET command settings are reset to their default values. Once the RACF subsystem starts, reissue the SET command to specify your desired settings.

Between IPLs, if you stop and restart the RACF subsystem address space, the settings associated with only the TRACE and GENERICANCHOR operands remain in effect. All other settings are reset to their default values.

You might find it useful to fill out the "RRSF node configuration worksheet" in the z/OS Security Server RACF System Programmer's Guide to help you determine the information you need to issue certain options of the SET command.

Issuing options

The following table identifies the eligible options for issuing the SET command:

As a RACF TSO command? As a RACF operator command? With command direction? With automatic command direction? From the RACF parameter library?
No Yes No No Yes

For information on issuing this command as a RACF operator command, see RACF operator commands.

Related commands

To define an RRSF node, see TARGET (Manage RRSF nodes).

Authorization required

You might require sufficient authority to the proper resource in the OPERCMDS class. For details about OPERCMDS resources, see Controlling the use of operator commands in z/OS Security Server RACF Security Administrator's Guide.

Syntax

For the key to the symbols used in the command syntax diagrams, see Syntax of RACF commands and operands. The complete syntax of the SET command is:

For information on issuing this command as a RACF operator command, see Rules for entering RACF operator commands.

Parameters

subsystem-prefix
Specifies that the RACF subsystem is the processing environment of the command. The subsystem prefix can be either the installation-defined prefix for RACF (1 - 8 characters) or, if no prefix has been defined, the RACF subsystem name followed by a blank. If the command prefix was registered with CPF, you can use the MVS command D OPDATA to display it or you can contact your RACF security administrator.

You must specify the subsystem prefix when issuing the SET command.

AUTOAPPL | NOAUTOAPPL
AUTOAPPL
Specifies that automatic direction of application updates is to be activated. Profiles in the RRSFDATA class control which application updates get automatically directed to which remote nodes. See z/OS Security Server RACF Security Administrator's Guide for more information on using the RRSFDATA class to control automatic direction of application updates and for planning information that is necessary before using it.

The operands on the AUTOAPPL keyword specify who gets the result and output from automatically directed application updates.

NOAUTOAPPL
Specifies that automatic direction of application updates is to be deactivated. This option prevents application update requests from being directed to remote nodes.

The initial value is NOAUTOAPPL.

When SET NOAUTOAPPL is issued, the settings of OUTPUT and NOTIFY are saved. Subsequently, if a SET AUTOAPPL command is issued with no other operands, those settings are restored.

AUTODIRECT | NOAUTODIRECT
AUTODIRECT
Specifies that automatic command direction is to be activated. Profiles in the RRSFDATA class control which commands and password synchronization requests get automatically directed to which remote nodes. See z/OS Security Server RACF Security Administrator's Guide for more information on using the RRSFDATA class to control automatic direction and for planning information that is necessary before using automatic command direction.

The operands on the AUTODIRECT keyword specify who gets the results and output from automatically directed commands.

When SET AUTODIRECT is issued, the settings of OUTPUT and NOTIFY are saved. Subsequently, if a SET AUTODIRECT command is issued with no other operands, those settings are restored.

If you want to issue the SET AUTODIRECT command to activate both the NOTIFY and OUTPUT settings, both NOTIFY and OUTPUT must be specified on the same command for both to be in effect. If specified on two separate commands, the settings on the first invocation are lost when the second is issued. For example, if you issue SET AUTODIRECT OUTPUT and then enter SET AUTODIRECT NOTIFY, the OUTPUT setting is lost when the second command is processed. Note that AUTODIRECT NOTIFY and OUTPUT settings are independent of the AUTOAPPL, AUTOPWD, and PWSYNC settings. See z/OS Security Server RACF Security Administrator's Guide for the Effects of using OUTPUT and NOTIFY and the following examples for more information.

When the OUTPUT, NOOUTPUT, NOTIFY, or NONOTIFY keyword is specified, the previous values of all of these keywords is overwritten. For example, if the previous setting was:
OUTPUT(FAIL(NODEA.ANDREW)) NOTIFY(FAIL(NODEA.ANDREW))
and you wanted to also have the command issuer receive FAIL output and command results, you must use:
OUTPUT(FAIL(NODEA.ANDREW &RACUID)) NOTIFY(FAIL(NODEA.ANDREW &RACUID))
If you just specified:
OUTPUT(FAIL(&RACUID))
then NODEA.ANDREW would be removed from OUTPUT and NODEA.ANDREW would lose his NOTIFY(FAIL) setting and the value would return to NONOTIFY. Note, however, that these settings for AUTOAPPL, AUTODIRECT, AUTOPWD, and PWSYNC are independent of each other. Continuing the previous example, consider the subsequent settings for SET AUTOPWD:
OUTPUT(FAIL(NODEA.ANDREW) NOTIFY(FAIL(NODEA.ANDREW))
This resets the table for AUTOPWD, but leaves the previously specified AUTODIRECT table with its &RACUID intact. AUTODIRECT, AUTOPWD, and PWSYNC are all independent in this way, with regard to the OUTPUT and NOTIFY settings and also about the request's processing.
NOTIFY(notify-level(list-of-notify-users))
Specifies that the user is to be notified (through TSO SEND command) of the results of this RRSF request. The information sent indicates whether the command was successful or unsuccessful, but does not include other details about the request's processing.
Note: The TSO SEND command updates the broadcast data set. This can either be a single data set used for all users, such as SYS1.BRODCAST, or a user-specific data set. The use of a global data set like SYS1.BRODCAST can result in heavy contention and deadlocks within the RACF subsystem address space, and even across systems in a sysplex. See the IKJTSOxx documentation in z/OS MVS Initialization and Tuning Reference for information on defining individual user logs.
ALWAYS
Specifies that results or output from all requests of this RRSF function are to be returned to specified users. This option should be used if the users are interested in the results of every request. Output includes informational, warning, and error messages.
WARN
Specifies that, in the case of AUTODIRECT, results or output from automatically directed commands are to be returned to the specified users only when the return code from the command is 4 or greater. In the case of AUTOAPPL, AUTOPWD, and PWSYNC, WARN is equivalent to FAIL.
FAIL
Specifies that, in the case of AUTODIRECT, results or output from automatically directed commands are to be returned to the specified users only when the return code from the command is 8 or greater. For AUTOAPPL, AUTOPWD, and PWSYNC, results or output from the request are to be returned to the specified users whenever the return code from the request is non-zero.
The list-of-notify-users value specifies up to four users who are to receive output and/or notification of results. A user can be specified in one of the following ways:
node.userid
The node and user ID separated by a period.

An 8 character user ID should not be specified unless the specified node is at z/OS V2R3 or above and has enabled 8 character User ID support in TSO. Doing so may produce unexpected results during output delivery, including lost output and error messages on the console.

.userid
The name of the user ID on the local node preceded by a period.

An 8 character user ID should not be specified unless the local node is at z/OS V2R3 or above and has enabled 8 character User ID support in TSO. Doing so may produce unexpected results during output delivery, including lost output and error messages on the console.

&RACUID
Original issuer with regard to node and user.
When &RACUID is specified, where the results and output are sent depend on the situation. Consider the following scenarios:
  • For password synchronization, automatic password direction, and automatic direction of application updates, results and output go to the specific system. For automatic command direction, the results and output go to the MAIN system. For a multisystem node, the MAIN system might not necessarily be the specific system of that issuing node.
  • A user on node A directs a command to node B which results in automatic command direction to node C. &RACUID specified on node C for AUTODIRECT NOTIFY or OUTPUT sends data to node A.
  • A user on node A directs a command to node B which results in a password change. This password change is propagated by password synchronization to node C. &RACUID specified on node C for PWSYNC NOTIFY or OUTPUT sends data to node B.
  • A user on node A changes a password, such that automatic password direction updates the corresponding user ID on node B. This user ID propagates the password change to a peer association on that same node B. &RACUID specified on node B for PWSYNC NOTIFY or OUTPUT would send data to the original user ID on node B (not A).
Note: If &RACUID is specified along with the user ID from which you are issuing the command, password change (covered by password synchronization or automatic password direction), or application update, that user ID receives the output or notification twice.
If you plan to use &RACUID for application updates, be aware of the following:
  • Guideline: Do not use &RACUID for AUTOAPPL output or notification. This might allow application updates to be done for undefined users, revoked user IDs, or the user ID of the RACF address space, and produce unexpected results during output delivery, including lost output and error messages on the console.
  • Ensure all possible user ID destinations through &RACUID have the authority to create data sets. For example, an installation would not want to use &RACUID for AUTOPWD or PWSYNC if the original issuer of a password change could be a CICS® user, who is unlikely to have authority to create the RRSFLIST output data set.
  • If the ACEE keyword is used on the RACROUTE request, the output goes to the user ID associated with the ACEE keyword, not to the user ID of the task or address space that issued the request.

The SET command does not perform existence checking for either the user ID or node.

The combination of users specified in the list of notify users variables can be up to a maximum of four different users. In other words, the cumulative total of unique users cannot exceed 4 in both the OUTPUT and NOTIFY keywords. The same four users can be specified in each list; however, if four users are specified on one of the keywords, a fifth user cannot be specified on the other keyword. For example, if four users are specified on the OUTPUT keyword, a fifth user cannot be specified on the NOTIFY keyword.

NONOTIFY
Specifies that no TSO SEND commands are issued with the results of the RRSF request.

The initial value is NONOTIFY.

The allowed values for notify-level are:

OUTPUT(output-level(list-of-output-users))
Specifies that the output from the RRSF request should be put in the RRSFLIST data set for the user named on this keyword. If the output cannot be put in the RRSFLIST data set for any reason, the output is transmitted to the user.

Because LIST-type commands are ineligible for automatic command direction, the output usually contains messages issued during command processing, such as informational, warning, or error messages.

The valid values for output-level are the same as those described for notify-level with the NOTIFY keyword.

The valid values for list-of-output-users are the same as those described for list-of-notify-users with the NOTIFY keyword.

NOOUTPUT
Specifies that no output, warning, or error messages are kept or sent to anyone.

The initial value is NOOUTPUT.

NOAUTODIRECT
Specifies that automatic command direction is to be deactivated.

This option prevents commands from being automatically directed to remote nodes.

The initial value is NOAUTODIRECT.

When SET NOAUTODIRECT is issued, the settings of OUTPUT and NOTIFY are saved. Subsequently, if a SET AUTODIRECT command is issued with no other operands, those settings are restored.

AUTOPWD | NOAUTOPWD
AUTOPWD
Specifies that automatic password direction is to be activated. Profiles in the RRSFDATA class AUTODIRECT.nodename.USER.PWSYNC control which automatic password directed requests get directed to which remote nodes. See z/OS Security Server RACF Security Administrator's Guide for more information on using the RRSFDATA class to control automatic password direction and for planning information that is necessary before using automatic password direction.

The operands on the AUTOPWD keyword specify who gets the result and output from automatically directed passwords. Refer to the descriptions of OUTPUT and NOTIFY under the AUTODIRECT keyword.

NOAUTOPWD
Specifies that automatic password direction is to be deactivated.

This option prevents passwords from being automatically directed to remote nodes.

The initial value is NOAUTOPWD.

When SET NOAUTOPWD is issued, the settings of OUTPUT and NOTIFY are saved. Subsequently, if a SET AUTOPWD command is issued with no other operands, those settings are restored.

FULLRRSFCOMM
Specifies that full communication paths are available between all systems in an RRSF multisystem node and all systems in other RRSF multisystem nodes. Use this in preparation to perform a dynamic MAIN switch with the TARGET PLEXNEWMAIN and TARGET NEWMAIN command. When FULLRRSFCOMM is in effect, the DORMANT and OPERATIVE keywords of the TARGET command will behave the same way for any remote system, including the case where both the local and remote systems are non-MAIN members of a multisystem node. In brief, DORMANT and OPERATIVE will allocate workspace files for the remote target if they do not already exist, and OPERATIVE will, in addition, establish a network connection. You must enable SET FULLRRSFCOMM and make connections between non-MAIN systems OPERATIVE before you can successfully use the PLEXNEWMAIN or NEWMAIN keyword of the TARGET command to perform a dynamic MAIN switch. If you never intend to switch MAIN systems dynamically, then you should not enable FULLRRSFCOMM, as it will simply allocate more resources (VSAM workspace files and network connections) for no reason.

SET FULLRRSFCOMM is not required on any system in a multisystem node if it is the only multisystem node in the network. It is never required for a single system node.

See z/OS Security Server RACF System Programmer's Guide for details on the dynamic MAIN switch capability. See the TARGET command for details of the DORMANT, OPERATIVE, PLEXNEWMAIN and NEWMAIN keywords.

GENERICANCHOR
Specifies the number of generic anchors that RACF maintains for each address space and for each MVS TCB that has its own ACEE.
A generic anchor is a list of generic profile names associated with either one of the following:
  • The high-level qualifier (HLQ) of a data set
  • A general resource class that is not processed in storage by the SETROPTS RACLIST or GENLIST command.

If you do not specify GENERICANCHOR, RACF maintains four generic anchors for each address space and four for each MVS TCB that has its own ACEE.

SYSTEM | JOBNAME
You must specify SYSTEM or JOBNAME. Only one SYSTEM setting is in effect at a time. Multiple JOBNAME settings can be in effect at the same time.
SYSTEM
When you specify SYSTEM with a COUNT value, the COUNT value indicates the number of generic anchors RACF maintains for any job for which no applicable JOBNAME setting is in effect.

When you specify SYSTEM with RESET, the SYSTEM setting is reset to the default value of 4.

JOBNAME(jobname ...)
When you specify JOBNAME with a COUNT value, the COUNT value indicates the number of generic anchors RACF maintains for the specified job name.

The specified COUNT value applies separately to the ACEE for the address space and to each MVS TCB that has its own ACEE. For example, if the specified job has an address space ACEE and two MVS TCBs that each have an ACEE, and you specify a COUNT value of 5, RACF keeps up to 15 generic anchors for the job.

When you specify JOBNAME with RESET, the specified job name and its associated COUNT setting are removed, and the number of generic anchors maintained for the specified job name is determined by the SYSTEM setting.

Specify one or more job names. Include an asterisk (*) as the last character of a jobname value to specify a set of similarly named jobs. For example, to specify the number of generic anchors for a job named MAPES, MAPES2, or MAPES3, you might specify JOBNAME(MAPES*).

When you include an asterisk as the last character of a jobname, such as MAPES*, the COUNT setting applies to any job name beginning with MAPES, unless a more specific job name setting is in effect. For example, if you issue two SET GENERICANCHOR commands, one specifying JOBNAME(MAPES*) and another specifying JOBNAME(MAPES2), the COUNT setting specified for MAPES* applies to a job named MAPES3 but not to a job named MAPES2.

COUNT | RESET
You must specify a COUNT value or RESET.
COUNT(nn)
Specifies the number of generic anchors (4 - 99).
RESET
When specified with SYSTEM, the number of generic anchors is reset to the default value of 4 for any job for which no applicable JOBNAME setting is in effect.

When specified with JOBNAME, the specified job name and its associated COUNT setting are removed, and the number of generic anchors maintained for the specified job name is determined by the SYSTEM setting.

INCLUDE(member-suffix ...)
Provides the ability to specify that the contents of one or more members of the RACF parameter library are to be processed. The INCLUDE keyword provides a convenient mechanism to process a previously defined set of RACF commands, such as SET and TARGET.
One or more suffixes can be specified with the INCLUDE keyword. Each specified suffix must be:
  • 1 - 2 characters in length
  • In the alphanumeric character set (A - Z, 0 - 9, # (X'7B'), $ (X'5B') or @ (X'7C'))
such that when the suffix is appended to IRROPT it results in the name of a member of the RACF parameter library.

SET INCLUDE commands can be nested in members of the RACF parameter library. For example, if member IRROPT01 contains a SET INCLUDE IRROPT02 command, then member IRROPT02 can contain a SET INCLUDE IRROPT03 command.

Be careful to adhere to a hierarchical order when nesting SET INCLUDE commands. For example, if IRROPT01 contains a SET INCLUDE IRROPT02 command, then IRROPT01 cannot contain a SET INCLUDE IRROPT01 command. Also, if IRROPT02 contains a SET INCLUDE command for any other parameter library members, those members cannot contain a SET INCLUDE IRROPT01 command. This restriction exists to prevent a never-ending loop of inclusion.

If a suffix appended to IRROPT does not result in the name of a member of the RACF parameter library, a message is issued and that suffix is ignored.

If the INCLUDE keyword is specified with any other SET keywords, the included members are processed first. The values specified for the other keywords override any values specified for the keywords in the included members. For example, the values specified for TRACE override any trace values specified in the included members.

No authorization checking or auditing is done for the commands in included members.

JESNODE(nodename)
Specifies the name of the node needed by RRSF in the cases where returned output from the directed commands must be transmitted to the user. RRSF queries the primary JES system during initialization in an attempt to obtain this name automatically. This keyword should be used in the cases where RRSF cannot automatically obtain this name.

No validity checking is done on the value specified with the JESNODE keyword.

LIST
Lists the attributes of an RRSF node and trace options.

The LIST keyword provides the ability to obtain information about the RRSF node's configuration, status related to the RACF subsystem, and status of TRACE and other options enabled by the SET command.

The LIST keyword can be specified alone or in combination with other SET command keywords. When used in combination with other SET command keywords, the information displayed reflects the results after processing the other keywords.

The information for the template version that the system is running with is displayed in the output. For details, see RACF database initialization utility program (IRRMIN00) in z/OS Security Server RACF System Programmer's Guide.

Note: LIST is the default if the SET command is issued with no keywords.
PWSYNC | NOPWSYNC
PWSYNC
Specifies that password synchronization is to be activated. See z/OS Security Server RACF Security Administrator's Guide for more information on using the RRSFDATA class to control password synchronization and for planning information that is necessary before using password synchronization. For information about how to establish password synchronization between user IDs, see the RACLINK command.

The operands on the PWSYNC keyword specify who gets the result and output from password changes covered by password synchronization. Refer to the descriptions of OUTPUT and NOTIFY under the AUTODIRECT keyword.

NOPWSYNC
Specifies that synchronized password processing is to be deactivated.

The initial value is NOPWSYNC.

When SET NOPWSYNC is issued, the settings of OUTPUT and NOTIFY are saved. Subsequently, if a SET PWSYNC command is issued with no other operands, those settings are restored.

TRACE
Specifies whether tracing is to take place for the following events, using the generalized trace facility (GTF).

If the TRACE keyword is specified, at least one subkeyword must be specified to indicate whether or not tracing is to be turned on or off for each of these events. There are no defaults for these event types. For example, if APPC is the only operand specified, then the current setting for tracing IMAGE events is not changed. If IMAGE tracing was in effect, it remains in effect. Likewise, if NOIMAGE had been in effect, it would remain in effect.

The initial values are NOAPPC, NOASID, NOCALLABLE, NOCLASS, NODATABASE, NOGENERICANCHOR, NOIMAGE, NOJOBNAME, NORACROUTE, NOSYSTEMSSL, and NOUSERID.

The SET LIST command should always be used to verify the trace parameters have been set as expected.

The trace records are intended for use in consultation with the IBM® support center when diagnosing potential RACF subsystem problems. For more information, see z/OS Security Server RACF Diagnosis Guide.

Important: Trace records might contain passwords and therefore trace output data sets should be appropriately protected.

 
APPC | NOAPPC
APPC
Enables tracing for APPC events. The trace information contains the APPC transaction return code and reason code.
NOAPPC
Disables tracing for APPC events.
ASID(asid ...) | NOASID | ALLASIDS
For CALLABLE, DATABASE, GENERICANCHOR, and RACROUTE event traces, the following options enable and disable tracing based on one or more address spaces.
ASID(asid ...)
Enables tracing for the specified address space. When ASID(asid ...) is specified, by consecutive invocations of the SET command, the asid list is deleted and rebuilt with the current specification each time the command is issued.
ALLASIDS
Enables tracing for all address spaces.
NOASID
Disables tracing based on address space.
CALLABLE | NOCALLABLE
CALLABLE
Use to trace z/OS UNIX calls.
Tracing for events related to z/OS UNIX calls occurs only for jobs selected by at least one of the following trace options:
  • ASID or ALLASIDS
  • JOBNAME or ALLJOBNAMES
ALL | NONE | TYPE
Use to control the degree of tracing.
ALL
Use to enable tracing of all z/OS UNIX calls.
NONE
Use to reset tracing.
TYPE(type ...)
Use to enable tracing of one or more specific z/OS UNIX calls. The TYPE operand is cumulative; issuing NOCALLABLE or CALLABLE(NONE) will reset the trace.
The request types that are supported are listed in Table 1.
Table 1. Callable services and associated function numbers
Callable service Function number Callable service Function number
IRRSIU00 1 IRRSFK00 28
IRRSDU00 2 IRRSMI00 29
IRRSMF00 3 IRRSKI00 30
Reserved. 4 IRRSCI00 31
IRRSMM00 5 IRRSC200 32
IRRSKA00 6 IRRSGE00 33
IRRSKP00 7 IRRSDI00 34
IRRSUM00 8 IRRSDK00 35
IRRSGM00 9 IRRSUD00 36
IRRSGG00 10 IRRSDA00 37
IRRSSU00 11 IRRSIA00 38
IRRSEU00 12 IRRSEQ001 39
IRRSSG00 13 IRRSIM00 40
IRRSEG00 14 IRRSDL00 41
IRRSCO00 15 IRRSMK00 42
IRRSCF00 16 IRRSPK00 43
IRRSCA00 17 IRRSPX00 44
IRRSEX00 18 IRRSCH00 45
IRRSAU00 19 IRRSPY00 46
IRRSKO00 20 IRRSCL00 47
IRRSQS00 21 IRRSSB00 48
IRRSQF00 22 IRRSWP00 49
IRRSCS00 23 IRRSGS00 50
IRRSKF00 24 IRRSAX00 51
IRRSMR00 25 IRRSGI00 52
IRRSPT00 26 IRRSPS00 53
IRRSUG00 27 IRRSPW00 54
1 Callable service IRRSEQ00 (R_Admin) has its own trace facility. For more information, see z/OS Security Server RACF Diagnosis Guide.
NOCALLABLE
Use NOCALLABLE to reset the trace; equivalent to CALLABLE(NONE).
CLASS | ALLCLASSES | IFCLASS | NEVERCLASS | NOCLASS
For DATABASE and RACROUTE event traces, use the following options to enable and disable tracing based on the names of one or more general resource classes.
CLASS(class-name ... | *)
Enables tracing for events associated with the specified class. The class-name value is an asterisk (*) or a list of one or more classes.

Specifying CLASS(*) enables tracing for events associated with any class. This option is equivalent to the ALLCLASSES option.

You can include an asterisk (*) as the last character of the class-name value to specify a set of similarly named classes. For example, to enable tracing for events associated with a class named CLS$D1, CLS$DS, or CLS$DPT, you might specify CLASS(CLS$D*).

When CLASS(class-name ...) is specified by consecutive invocations of the SET command, the class-name list is deleted and rebuilt with the current specification each time the command is issued.

ALLCLASSES
Enables tracing for events associated with any class. This option is equivalent to specifying CLASS(*).
IFCLASS(class-name ... | *)
Enables tracing only when the event is associated with the specified class.

Specifying IFCLASS(*) enables tracing only when the event is associated with a class, regardless of class name.

You can include an asterisk (*) as the last character of the class-name value to specify a set of similarly named classes. For example, to enable tracing only when the event is associated with a class named CLS$D1, CLS$DS, or CLS$DPT, you might specify IFCLASS(CLS$D*).

When IFCLASS(class-name ...) is specified by consecutive invocations of the SET command, the class-name list is deleted and rebuilt with the current specification each time the command is issued.

NEVERCLASS(class-name ... | *)
Disables tracing only when the event is associated with the specified class.

Specifying NEVERCLASS(*) disables tracing only when the event is associated with a class, regardless of class name.

You can include an asterisk (*) as the last character of the class-name value to specify a set of similarly named classes. For example, to disable tracing only when the event is associated with a class named CLS$D1, CLS$DS, or CLS$DPT, you might specify NEVERCLASS(CLS$D*).

When NEVERCLASS(class-name ...) is specified by consecutive invocations of the SET command, the class-name list is deleted and rebuilt with the current specification each time the command is issued.

NOCLASS
Disables tracing based on class name.
DATABASE | NODATABASE
DATABASE
Use to trace RACF database manager requests.
Tracing for events related to RACF database manager requests occurs only for jobs selected by at least one of the following trace options:
  • ASID or ALLASIDS
  • CLASS, ALLCLASSES, or IFCLASS
  • JOBNAME or ALLJOBNAMES
ALL | NONE
Use ALL to enable tracing of all requests.

Use NONE to disable tracing.

ALTER | NOALTER
Use ALTER to enable tracing all RACF database manager calls that change the database. Calls included are RENAMEs, ALTERs, ADDs and DELETEs. No further granularity is provided for calls that change the database.

Use NOALTER to disable tracing of all RENAMEs, ALTERs, ADDs and DELETEs.

ALTERI | NOALTERI
Use ALTERI to enable tracing all RACF database manager calls that change fields in the database that use ALTERI as the request.

Use NOALTERI prevent the tracing of these requests.

READ | NOREAD
Use READ to enable tracing all RACF database manager RACF calls that locate profiles in the database.

Use NOREAD prevent the tracing of these requests.

NODATABASE
Use NODATABASE to disable tracing database manager requests; equivalent to DATABASE(NONE).
GENERICANCHOR | NOGENERICANCHOR
GENERICANCHOR
Enables tracing for events related to generic anchors. For each profile list that RACF creates for a generic anchor, RACF records a trace record that includes the high-level qualifier (HLQ) or class name, the number of profile names in the list, the number of generic anchors present for the job, and, if applicable, the HLQ or class name of the profile list that RACF is replacing.
Tracing for events related to generic anchors occurs only for jobs selected by at least one of the following trace options:
  • ASID or ALLASIDS
  • JOBNAME or ALLJOBNAMES
  • USERID, ALLUSERIDS, or IFUSERID
NOGENERICANCHOR
Disables tracing for events related to generic anchors.
IMAGE | NOIMAGE
IMAGE
Enables tracing of IMAGE events. The trace information contains the command image being processed.
NOIMAGE
Disables tracing for IMAGE events.
JOBNAME | ALLJOBNAMES | NOJOBNAME
For CALLABLE, DATABASE, GENERICANCHOR, and RACROUTE event traces, the following options allow you to enable and disable tracing based on one or more job names.
JOBNAME(jobname ...) | *)
Enables tracing for events associated with the specified job name. The jobname value is an asterisk (*) or a list of one or more job names.

Specifying JOBNAME(*) enables tracing for events associated with any job name. This option is equivalent to the ALLJOBNAMES option.

You can include an asterisk (*) as the last character of the jobname value to specify a set of similarly named jobs. For example, to enable tracing for events associated with a job named MAPES, MAPES2, or MAPES3, you might specify JOBNAME(MAPES*).

When JOBNAME(jobname ...) is specified, by consecutive invocations of the SET command, the jobname list is deleted and rebuilt with the current specification each time the command is issued.

ALLJOBNAMES
Enables tracing for events associated with any job name. This option is equivalent to specifying JOBNAME(*).
NOJOBNAME
Disables tracing by job name.
PDCALLABLE | NOPDCALLABLE
PDCALLABLE
Use to trace IBM Policy Director Authorization Services SAF calls.
ALL | NONE | TYPE
Use to control the degree of tracing.
ALL
Use to enable tracing of all IBM Policy Director Authorization Services SAF calls.
NONE
Use to reset tracing.
TYPE(type ...)
Use to enable tracing of one or more specific IBM Policy Director Authorization Services SAF calls. The request types that are supported are listed in the following table:
Callable service Service / type number
IRRSZA00 1
IRRSZC00 2

The TYPE operand is cumulative; issuing NOPDCALLABLE or PDCALLABLE(NONE) will reset the trace.

NOPDCALLABLE
Use NOPDCALLABLE to reset the trace; equivalent to PDCALLABLE(NONE).
RACROUTE | NORACROUTE
RACROUTE
Use to trace RACROUTE calls.
Tracing for events related to RACROUTE calls occurs only for jobs selected by at least one of the following trace options:
  • ASID or ALLASIDS
  • CLASS, ALLCLASSES, or IFCLASS
  • JOBNAME or ALLJOBNAMES
  • USERID, ALLUSERIDS, or IFUSERID
ALL | NONE | TYPE
Use to control the degree of tracing.
ALL
Use to enable tracing of all RACROUTE calls.
NONE
Use to reset tracing.
TYPE(type ...)
Use to enable tracing of one or more specific RACROUTE calls. The request types that are supported are listed in the following table:
RACROUTE REQUEST type Service / type number
AUTH 1
FASTAUTH 2
LIST 3
DEFINE 4
VERIFY 5
EXTRACT 6
DIRAUTH 7
TOKENMAP 8
VERIFYX 9
TOKENXTR 10
TOKENBLD 11
EXTRACT, BR=YES 12
AUDIT 13
STAT 14
SIGNON 15
TOKENMAP, XMEM 16
TOKENXTR, XMEM 17

The TYPE operand is cumulative; issuing NORACROUTE or RACROUTE(NONE) will reset the trace.

NORACROUTE
Use NORACROUTE to reset the trace; equivalent to RACROUTE(NONE).
RRSF | NORRSF
RRSF
Enables tracing for RRSF events. The trace information contains the relevant API return code and reason code, where applicable.
NORRSF
Disables tracing for RRSF events.
SYSTEMSSL | NOSYSTEMSSL
SYSTEMSSL
Use to trace RACF's use of z/OS® System Secure Sockets Layer (SSL) services. The actual trace records are created by the System SSL component itself; RACF only requests that the trace records be created. SSL services are used by RACF to create PKCS #7 envelopes for user passwords and password phrases. For more information, see z/OS Security Server RACF Security Administrator's Guide.

When SET TRACE(SYSTEMSSL) is in effect, all trace functions except EBCDIC and ASCII data dumps are requested. The trace records are written to a UNIX file with the path name /tmp/gskssl.racf.pid.trc, where pid is the UNIX process ID assigned to the RACF thread that attempted the enveloping operation (initial creation during password or password phrase change, or retrieval with the R_admin callable service). It is difficult to determine the pid for a given enveloping operation because it exists transiently. To debug a reproducible problem, look at the trace files that already exist in /tmp starting with gskssl.racf, or delete all the trace files, initiate the enveloping operation, find the new file that was created, and look within that file for the trace data. For more information on creating trace records, see z/OS Cryptographic Services System SSL Programming.

NOSYSTEMSSL
Deactivates tracing for RACF's use of System SSL services.
USERID | ALLUSERIDS | IFUSERID | NEVERUSERID | NOUSERID
For GENERICANCHOR and RACROUTE event traces, use the following options to enable and disable tracing based on one or more user IDs.
The USERID trace options apply to RACROUTE requests of only the following types:
  • RACROUTE REQUEST=AUTH (type 1)
  • RACROUTE REQUEST=FASTAUTH (type 2)
  • RACROUTE REQUEST=VERIFY (type 5)
  • RACROUTE REQUEST=VERIFYX (type 9)
USERID(userid ... | *)
Enables tracing for events associated with the specified user ID. The userid value is an asterisk (*) or a list of one or more user IDs.

Specifying USERID(*) enables tracing for events associated with any user ID. This option is equivalent to the ALLUSERIDS option.

You can include an asterisk (*) as the last character of the userid value to specify a set of similarly named user IDs. For example, to enable tracing for events associated with user ID ADMIN1, ADMIN2, or ADMIN3, you might specify USERID(ADMIN*).

When USERID(userid ...) is specified by consecutive invocations of the SET command, the userid list is deleted and rebuilt with the current specification each time the command is issued.

ALLUSERIDS
Enables tracing for events associated with any user ID. This option is equivalent to specifying USERID(*).
IFUSERID(userid ... | *)
Enables tracing only when the event is associated with the specified user ID.

Specifying IFUSERID(*) enables tracing only when the event is associated with a user ID, regardless of user ID.

You can include an asterisk (*) as the last character of the userid value to specify a set of similarly named user IDs. For example, to enable tracing only when the event is associated with user ID ADMIN1, ADMIN2, or ADMIN3, you might specify IFUSERID(ADMIN*).

When IFUSERID(userid ...) is specified by consecutive invocations of the SET command, the userid list is deleted and rebuilt with the current specification each time the command is issued.

NEVERUSERID(userid ... | *)
Disables tracing only when the event is associated with the specified user ID.

Specifying NEVERUSERID(*) disables tracing only when the event is associated with a user ID, regardless of user ID.

You can include an asterisk (*) as the last character of the userid value to specify a set of similarly named user IDs. For example, to disable tracing only when the event is associated with user ID ADMIN1, ADMIN2, or ADMIN3, you might specify NEVERUSERID(ADMIN*).

When NEVERUSERID(userid ...) is specified by consecutive invocations of the SET command, the userid list is deleted and rebuilt with the current specification each time the command is issued.

NOUSERID
Disables tracing based on user ID.

Examples

Example Activity label Description
1 Operation User ADMIN wants to enable automatic command direction and establish that LAURIE at POKMVS and the command issuer receives output and notification when an automatically directed command receives a return code of 8 or greater.
Known The RACF subsystem prefix is @.
Command
@SET AUTODIRECT (OUTPUT (FAIL (POKMVS.LAURIE &RACUID))
         NOTIFY (FAIL (POKMVS.LAURIE &RACUID)))
Defaults None.
2 Operation User ADMIN wants to enable automatic command direction and establish that:
  • ACDERROR at POKMVS will receive warning and error output, but no TSO SEND messages.
  • ANDREW at POKMVS will receive warning output, error output, and TSO SEND messages for error conditions.
  • LAURIE at POKMVS will not receive any output, but will receive TSO SEND messages for error conditions.
  • The command issuer gets no notification of automatically directed commands.
Known The RACF subsystem prefix is @. LAURIE at POKMVS has the ability to browse the RRSFLIST data set of ACDERROR at POKMVS to determine what needs to be fixed.
Command
@SET AUTODIRECT (OUTPUT (WARN (POKMVS.ACDERROR POKMVS.ANDREW))
         NOTIFY (FAIL (POKMVS.LAURIE POKMVS.ANDREW)))
Defaults None.
3 Operation User ADMIN wants to enable automatic direction, automatic password direction, automatic direction of application updates, but not password synchronization. User ADMIN wants to be notified and receive output for all failures. The command issuer needs to always receive notification and output for automatically directed commands (but not for automatic password direction or automatic direction of application updates).
Known The RACF subsystem prefix is @.
Commands
@SET AUTODIRECT(OUTPUT(FAIL(POKMVS.ADMIN &RACUID))
NOTIFY(FAIL(POKMVS.ADMIN &RACUID)))
@SET AUTOPWD(OUTPUT(FAIL(POKMVS.ADMIN))
NOTIFY(FAIL(POKMVS.ADMIN)))
@SET AUTOAPPL(OUTPUT(FAIL(POKMVS.ADMIN))
NOTIFY(FAIL(POKMVS.ADMIN)))
Defaults None.
4 Operation User ADMIN wants to enable tracing for all VERIFY requests issued in a particular address space.
Known The RACF subsystem prefix is @.
Command @SET TRACE(RACROUTE(TYPE(2,5,9)) ASID(17))
Defaults None.
Output See Figure 1
5 Operation User ADMIN wants to obtain information concerning the RRSF node's configuration and status related to the RACF subsystem. User ADMIN also wants to turn on tracing for IMAGE events.
Known Because the LIST keyword is used in combination with the TRACE keyword, the information displayed reflects the results after processing the TRACE keyword.

The RACF subsystem prefix is @.

Command @SET LIST TRACE(IMAGE)
Defaults None.
Output See Figure 1.
6 Operation User ADMIN wants to enable tracing for the aznAccess SAF callable service for job name IBMUSER.
Known

The RACF subsystem prefix @.

Command @SET TRACE(PDCALLABLE(TYPE(1)) JOBNAME(IBMUSER))
Defaults None.
Output IRRH004I (@) RACF SUBSYSTEM SET COMMAND HAS COMPLETED SUCCESSFULLY.
7 Operation User ADMIN wants to verify that tracing has been enabled for the aznAccess z/OS Policy Director SAF callable service.
Known

The RACF subsystem prefix is @.

Command @SET LIST
Defaults None.
Output SET LIST output indicates that tracing has been enabled for PDCALLABLE service request type 1 (aznAccess SAF callable service). See Figure 1.
8 Operation The system programmer wants to set the number of generic anchors to 10 for job names that begin with the characters MAPES, such as MAPES2 and MAPES3, to 8 for the job named MAPES9, and to 6 for all other jobs.
Known

The RACF subsystem prefix @.

Commands
The system programer might enter the following operator commands:
@SET GENERICANCHOR (JOBNAME(MAPES*) COUNT(10))
@SET GENERICANCHOR (JOBNAME(MAPES9) COUNT(8))
@SET GENERICANCHOR (SYSTEM COUNT(6))
Defaults None.
Output IRRH004I (@) RACF SUBSYSTEM SET COMMAND HAS COMPLETED SUCCESSFULLY.
Figure 1. Output for SET LIST command
IRRH005I (@) RAC1 SUBSYSTEM INFORMATION:
            TRACE OPTIONS                   - NOIMAGE
                                            - NOAPPC
                                            - NOSYSTEMSSL
                                            - NORRSF
                                            - NORACROUTE
                                            - NOCALLABLE
                                            - NOPDCALLABLE
                                            - NODATABASE
                                            - NOGENERICANCHOR
                                            - NOASID
                                            - NOJOBNAME
                                            - NOCLASS
                                            - NOUSERID
            SUBSYSTEM USERID                - RRSFUSER
            JESNODE (FOR TRANSMITS)         - THISJES
            AUTOMATIC DIRECTION IS ALLOWED
                  OUTPUT IS IN EFFECT FOR:
                          MVS01.SECADM      - FAIL
                          MVS01.SYSPRG      - FAIL
                          MVS02.SECADM      - FAIL
                  NOTIFY IS IN EFFECT FOR:
                          MVS01.SECADM      - FAIL
                          MVS01.SYSPRG      - FAIL
                          MVS02.SECADM      - FAIL
            FULL RRSF COMMUNICATION IS *NOT* ENABLED
            RACF STATUS INFORMATION:
                  TEMPLATE VERSION          - HRF7708  00000020.00000030
                  DYNAMIC PARSE VERSION     - HRF7708