Preparing to use automatic direction

Check your RACF® exits, naming conventions table, templates, and dynamic parse tables.
If you are keeping profiles synchronized between multiple nodes, the above items on these nodes should be examined to see if they could cause unsynchronized conditions. See z/OS Security Server RACF System Programmer's Guide for more information.
Decide which updates to automatically direct and which profiles to keep synchronized. Updates can be made by command, password changes, and applications. Decide which ones you want to send to target nodes.
There are many considerations to synchronizing profiles because many profiles in the RACF database are related in important ways. An installation's goal should be to have RACF updates execute with the same results on each node (to minimize error conditions and unsynchronized conditions). Here are some guidelines to help prevent unsynchronized conditions.
Guidelines:
1. Use automatic direction to keep USER and GROUP profiles synchronized:
  - The same user IDs and groups need to exist on each node, because updates are automatically directed to the same user IDs.
  - The RACF authorities for each user ID authorized to automatically direct updates on a node should be equivalent to that same user ID's authorities on each node. This includes user authorities (such as SPECIAL and CLAUTH) and group authorities (which users are connected to which groups).
    For example, if SYSPROG on NODEA is SPECIAL and automatically directs commands to SYSPROG on NODEB, SYSPROG on NODEB should have SPECIAL authority also.
  - For automatic direction of commands:
    - If commands such as PERMIT or other commands that specify a group name or a user ID as an operand are being kept synchronized, the specified group names or user IDs must exist on both nodes.
    - If the CONNECT command is automatically directed, the GROUP class should be kept synchronized. Otherwise, the automatically directed CONNECT commands are likely to fail.
  - If the USER class is being kept synchronized, it should be noted that the RACLINK command is not eligible for automatic direction. Because the RACLINK command adds information to the USER profiles, an installation should consider whether to manually establish the user ID associations on each node; otherwise the USER profiles do not remain synchronized.
  - If the USER class is kept synchronized and you use distributed identity filters, be aware that the RACMAP command is not eligible for automatic direction. Because the RACMAP command adds information to USER profiles and affects profiles in the IDIDMAP class, you should implement automatic direction of application updates. For details, see RRSF considerations for distributed identity filters.
  - If the USER or GROUP class is kept synchronized and you use CSDATA segments in USER or GROUP profiles to store data in custom fields, you should also synchronize profiles in the CFIELD class. (For information about custom fields, see Defining and using custom fields and RRSF considerations for custom fields.)
2. Synchronize profiles by class rather than by command:
  - If RDEFINE DASDVOL is automatically directed and RALTER DASDVOL is not, the DASDVOL profile becomes unsynchronized.
  - If ADDSD is automatically directed, but PERMIT DATASET is not, the DATASET profile becomes unsynchronized.
  - If RDEFINE TAPEVOL is automatically directed, but application updates for the TAPEVOL class are not, the TAPEVOL profiles become unsynchronized.
3. Keep SETROPTS command settings synchronized:
  - This can be done manually (using command direction) if SETROPTS is issued infrequently.
  - Make sure that general resource classes on both nodes are active if updates are being automatically directed for the class.
4. Considerations for running the IRRRID00 utility:
  Because the DELUSER and DELGROUP commands do not automatically delete access list entries from resource profiles, you can use IRRRID00 to generate commands to clean up the profiles for a user or group that has been deleted. If the PERMIT command is being automatically directed, the user who runs the generated list of commands from IRRRID00 must be authorized to automatically direct the PERMIT commands. Otherwise, the resource profiles on the remote system will not be cleaned up.
5. When synchronizing a particular kind of profile between nodes, it is better to give all users who can update the profiles controlling those profiles the authority to direct updates automatically. To do this, you can give them READ authority to the appropriate RRSFDATA profiles, for example.
  If there are users who can cause updates to occur locally but cannot direct them automatically, some updates are not automatically directed, and the profiles do not remain synchronized. There are special considerations for automatic direction of application updates for the DATASET class. For these, see Considerations for the DATASET class.
Synchronize specified profiles:
- Run IRRRID00 on each RACF database to remove references to user IDs and group names that no longer exist.
- Synchronize databases. You can do this by manually copying the database from one system to the other, or by using a tool that can help you synchronize databases. For information on how to get this tool and others, go to the RACF home page.
Create AUTODIRECT profiles in the RRSFDATA class as desired to specify which updates should be automatically directed. Remember to create the profiles on each node from which automatic direction should occur. For example, the following commands cause all password and password phrase updates, commands, and application updates for the user class to be automatically directed to all remote nodes:
```
SETROPTS GENERIC(RRSFDATA)   (required if you use generic profiles)

RDEFINE RRSFDATA AUTODIRECT.*.USER.* UACC(READ)
```
For automatic password direction only, RDEFINE commands are:
```
RDEFINE RRSFDATA AUTODIRECT.*.USER.PWSYNC    UACC(READ)  (for passwords)
RDEFINE RRSFDATA AUTODIRECT.*.USER.PHRSSYNC  UACC(READ)  (for password phrases)
```
Note: The RRSFDATA profile PWSYNC.nodename is not required for using automatic password direction.
Activate the RRSFDATA class on each node, if it has not already been activated. It is recommended that the class be RACLISTed for performance reasons. If the class has already been RACLISTed, refresh the profiles. For example, use one of the following commands:
```
SETROPTS CLASSACT(RRSFDATA) RACLIST(RRSFDATA)
SETROPTS RACLIST(RRSFDATA) REFRESH
```
Decide who should be notified of the automatic direction results and output.
Activate automatic direction when you are ready by issuing the SET command with the options corresponding to automatic command direction, automatic password direction, and automatic direction of application updates, with output and notification options appropriate to your installation's needs:
```
SET AUTODIRECT(...)
SET AUTOPWD(...)   
SET AUTOAPPL(...) 
```
Guideline: Use a RACF parameter library as specified for RACF subsystem initialization. The SET command should be in the default IRROPTxx member of this library so that these options are reinstated when the subsystem is restarted or the entire system is reIPLed.
At a later date, to temporarily or permanently deactivate one or more automatic direction functions, issue the SET command with the options corresponding to automatic command direction, automatic password direction, and automatic direction of application updates:
```
SET NOAUTODIRECT
SET NOAUTOPWD 
SET NOAUTOAPPL
```
See the note in Step 7 regarding the RACF parameter library.
It is possible to fail while attempting to execute a command issued on an uplevel system and manually or automatically directed to a downlevel system through RACF remote sharing. This can occur if the command references a class unknown to the target system (class descriptor tables are different), if it references a segment or field unknown to the target system (templates or dynamic parse definition are different), if it uses a command keyword unknown to the target (dynamic parse definitions or command processor code is different), or if it specifies a profile or member name that is unacceptable to the target system (class descriptor tables have different syntax requirements for profile name length or syntax).
Guideline: Be sure that your class descriptor tables, including dynamic classes, are compatible across all systems participating in automatic direction.

If an unsynchronized condition occurs while using automatic command direction, a RACF TSO command can be directed with the ONLYAT option to fix the condition. The command runs on the node specified on the ONLYAT option and is not propagated to any other node. (Note that if the AT keyword is used, the command can be propagated by automatic command direction to other nodes.) For information on the ONLYAT option, see Directing commands using the ONLYAT option. For a complete list of RACF commands that are eligible for automatic command direction, see z/OS Security Server RACF Command Language Reference.