RRSF considerations for automatic ID assignment

RACF® does two things to facilitate automatic ID assignment in a RACF remote sharing facility (RRSF) environment in order to prevent different nodes from arriving at the same ID values independently for different users and then propagating these updates on the network.

RACF suppresses propagation of its own internal updates to the BPX.NEXT.USER profile. This prevents RACF from altering the BPX.NEXT.USER profile on other RRSF nodes when you are using automatic direction of application updates for the FACILITY class.
RACF alters the command image on the source node before propagating it out to other RRSF nodes. RACF inserts the generated ID value into the command image so (from the perspective of the target node) an explicit ID assignment is being requested. This protects you when automatic command direction is in effect for user and group profiles.

Example: Suppose you issue the following command on the source node in an RRSF environment:

ADDUSER SEYMOUR OMVS(AUTOUID HOME(/u/seymour) PROGRAM(bin/sh))

If RACF processes this ADDUSER command and arrives at a UID value of 4120 through unique ID processing, RRSF propagates the following command image to the target node:

ADDUSER SEYMOUR OMVS(AUTOUID UID(4120) HOME(/u/seymour) PROGRAM(/bin/sh))

As a result, no unique ID processing is done at the target node because it was already done at the source node. When the ADDUSER command executes at the target node, the AUTOUID option is ignored because UID is specified.

Guidelines: To avoid ID collisions when multiple nodes on your RRSF network are enabled for automatic assignment of unique IDs, take one of the following actions:

Use non-overlapping ID ranges on each of the RRSF nodes to avoid conflicts when an automatic ID request is made on a given node and propagated to any other node.
Because you do not want APPLDATA updates being propagated between nodes, be careful when defining and altering BPX.NEXT.USER if automatic command direction is active for the FACILITY class. Using the ONLYAT operand (on the RALTER and RDEFINE commands) when you change BPX.NEXT.USER prevents propagation of a node's APPLDATA. ONLYAT must be used whether you are creating the BPX.NEXT.USER profile on a local or remote node.
Example: To define the BPX.NEXT.USER profile on the local node, issue:
```
RALTER FACILITY BPX.NEXT.USER 
   APPLDATA('10000-19999/10000-19999') 
   ONLYAT(.MYID)
```
Example: To define the BPX.NEXT.USER profile on a remote node called NODEB, issue:
```
RALTER FACILITY BPX.NEXT.USER 
   APPLDATA('20000-29999/20000-29999') 
   ONLYAT(NODEB.MYID)
```
Ensure that user and group updates (specifically, those involving UID and GID requests) be performed on a single node, and propagated to other RRSF nodes from this node. Though you do not have to be concerned with the contents of BPX.NEXT.USER on any node other than the source node (whether or not automatic command direction or automatic direction of application updates is being used), all nodes should be running with SHARED.IDS implemented.