Synchronization is the process where you equalize and integrate the configuration, options, and profiles in separate RACF implementations and databases, paying special attention to areas where they overlap and potentially conflict. For example, if the tape data set protection option, TAPEDSN, is active on only one database, the option will either need to be activated on all databases or deactivated on the one to make them all identical. Likewise, if a profile exists on all databases (e.g., SYS1.**), its access list and attributes such as Universal Access (UACC) must be made the same on all. The goal of synchronization is to ensure all the z/OS images that will ultimately share one database can function properly with the same RACF settings. Often, it’s helpful to designate one database as the target into which profiles from the other databases will be copied to build the final merged database. Whenever practical, synchronization changes should be completed on all systems before the final merge and implementation of the shared database.

The synchronization process involves a careful and detailed analysis, looking at all systems on an option-by-option, class-by-class and profile-by-profile basis, including individual profile fields where necessary. Two questions this analysis should attempt to answer are:

• Will an exit, table entry, option, or resource class that’s active on only one system image adversely affect the operation of the others? For example, the JESJOBS controls job submission. It has a default return code of 8, meaning that no access is allowed if there’s no covering profile. If the class is active on one system and not the others, suddenly activating it on the others could seriously impair production batch processing.

• Will a profile and its attributes or access list on one database adversely affect access on the other databases by either granting or denying access? Suppose user SJONES has OPERATIONS authority on one database and not the others. If SJONES isn’t configured with OPERATIONS in the merged database, the user could experience a denial of access on the systems previously served by the one database. Conversely, if SJONES is given OPERATIONS in the merged, shared database, the user may gain inappropriate access authority on the other systems.

Areas to address in the synchronization process include:

System and RACF exits and interfaces: To ensure consistency of functionality, all systems sharing a RACF database should implement the same exit code, security-related z/OS configuration options (e.g., Program Property Table [PPT] NOPASS entries), and RACF interfaces. This encompasses more than just RACF exits. System exits and software that interact with RACF will need to be synchronized, too. While it’s conceivable each z/OS image could have its own unique set of exits and RACF interfaces, this often leads to confusion that can result in security exposures. Try to implement the same code on all systems.

RACF tables: Pay particular attention to the ICHNCV00 naming conventions table, ICHRDSNT data set name table, ICHRRNG database range table, ICHRRCDE CDT as well as its companion CDT class, and the Global

Access Table. ICHNCV00 rearranges data set names before checking profiles and, if not synchronized, could result in unexpected profiles protecting certain data sets. If the database is split into multiple data sets, all images will need the same ICHRDSNT and ICHRRNG configuration. Focus most of your attention on the ICHRRCDE and the CDT class. Identify and resolve inconsistencies in resource class definitions such as profile format, default return codes, OPERATIONS authority, and especially POSIT values.

SETROPTS options: There are two major areas to address. First is resource class status. Prior to the merge, set every class in all databases to the same level of activation, including CLASSACT, GENERIC, GENCMD, AUDIT, STATISTICS, LOGOPTIONS, GLOBAL, and RACLIST or GENLIST. If a class such as OPERCMDS is active with a full complement of profiles on only one database, it may be necessary to embark on a major side project to implement it on the other databases. Be particularly wary of default return code 8 classes, such as JESSPOOL, because you’ll need to create profiles to permit access before activating the class the first time. The other major area involves control and audit options. PROTECTALL, Enhanced Generic Naming (EGN), password controls, and OPERATIONS Audit (OPERAUDIT) will need to be the same. For each option, you can choose to revert to the least restrictive setting on all databases or you can implement the option where currently inactive.

5 Pages