There are some sysplex recovery scenarios that require a member to be brought up in XCF-local mode. RACF® will not come up when the data set name table asks for at least data-communication and the system is in XCF-local mode. (This is called failsoft -- see Failsoft processing.) RACF is designed this way because there is a significant possibility of RACF database corruption when 1 member is up in XCF-local mode and other member(s) are up in sysplex communication or data sharing mode.

Guideline: Sysplex customers should use the TSO/E user attributes data set (UADS) to authorize at least one ID. This gives you a way to log on to TSO/E. But the system will have limited functionality due to the absence of RACF.

If a user logs on to TSO/E and you have not defined a TSO segment for that user, TSO/E checks the SYS1.UADS data set for the information it needs to build a session. If TSO/E does not find an entry for the user in SYS1.UADS, the user is denied access to the system. You must maintain entries in SYS1.UADS for emergency use (at least IBMUSER and one system programmer is recommended). This allows you to log on to TSO/E when RACF is not up (failsoft).

It is better to define UADS emergency IDs without RACF TSO segments. If you have a TSO segment, information from there (such as password) is used to log on when RACF is active. However during an emergency when RACF is not up, UADS information is used (which might not be the same).

TSO/E provides the UADS mechanism to allow users to be defined that can log on in this situation. If one or more IDs are not set up this way, in advance, there is no way to log on to any TSO/E user ID should you need to bring a member up in XCF-local mode.