Started tasks: This step can be quite complicated. You may encounter started tasks with shared IDs, started tasks with the same name performing different functions, and identical started tasks with differences in attributes such as TRUSTED, OPERATIONS, OMVS uids, and permissions across the system images. You may be forced to rename tasks, reassign IDs, or change permissions to avoid conflicts. IPLs may be necessary to implement changes because some started tasks only initialize at system start-up.

User profiles: Ensure USERIDs found on multiple databases have identical profile and segment attributes such as default group, PROTECTED, RESTRICTED, OMVS uid, and Customer Information Control System (CICS) OPIDENT. Be mindful of products or user interfaces that rely on information in the installation data field such as ViewDirect (a.k.a. INFOPAC) Recipient IDs. If you’re forced to change OMVS uids on one database, you may need to make corresponding changes to HFS permissions.

Group profiles: Like user profiles, identically named groups will need consistent attributes. These include Superior Group, Installation Data, TERMUACC, and OMVS gid. If a group with the same name is found in multiple databases but used for different purposes, for instance to grant different sets of users access to dissimilar resources, it will be necessary to implement a replacement group on one or more of the databases.

User/group collisions: You may discover a user on one database is defined as a group on one of the other databases and you’ll be forced to convert one of them. The conversion process is more complicated if the user/group has data set profiles because RACF won’t let you delete an ID until you have first deleted these profiles. When data set profiles exist, you must delete the data set profiles, delete the user or group, create the replacement user or group, and then re-create the data set profiles. If PROTECTALL is active, you may want to temporarily deactivate it during the collision conversion. Use the IRRRID00 Remove ID utility to help find and delete all unnecessary references to the ID being converted.

Data set profiles: When synchronizing data set profiles, the first task is to identify HLQs common to multiple databases and integrate their profiles to form a single identically matching list. As you add profiles from one database to another, you’ll be undercutting the existing profiles and may disrupt existing access (see Figure 2). Be sure to copy the access lists of the existing profiles into the new undercutting profiles as you create them. Once you have matching profiles on all databases, equalize their attributes. You’ll need to set UACC, WARNING, AUDIT, access permission lists, and all other profile and segment attributes to be the same. To speed up the merge effort, you may need to set UACCs to the highest level found and wait until after the merge to retighten access.

General resource profiles: The task of synchronizing general resource profiles is largely similar to data set profiles. There are, however, a few key differences. When databases contain grouping class profiles, you need to synchronize the resource members in the profiles as well as the profiles themselves. If resource members have been defined to more than one profile, careful analysis is required to see what access permissions will be granted in the newly combined RACF database. Similarly, when the same RACFVARS variable is defined on multiple databases but used for different purposes, it may be necessary to replace it with a different variable on some of the databases, and you’ll need to change all the profiles that incorporate the variable. For some RACFVARS profiles, &RACLNDE, for example, you’ll need to integrate the variable text strings. There are a few creative things you can do to avoid having overlapping, interfering profiles with general resources. Profiles in Job Entry Subsystem (JES)- related classes (e.g., WRITER) are prefixed with the name of the JES subsystem. If JES is named JES2 on multiple images, the resulting resource names and associated profiles might collide. Simply changing the names of the JES subsystems will segregate the various sets of resources. When CICS regions supported by different databases use the same set of resource classes (perhaps the default classes TCICSTRN and GCICSTRN), you can separate them by creating new sets of classes with unique names and have the CICS regions reference different classes. One of the more complicated analysis tasks you’ll face is synchronizing profiles in the FACILITY class, since these profiles will affect many software functions and products common to all system images. (For more on this, see the article “Security’s Multi-Purpose FACILITY Classes in the April/May 2006 issue of z/Journal.)

Administrative authorities: As you synchronize profiles on the different databases, you may need to change profile ownership and group hierarchy. If you use group-level authorities (e.g., Group-SPECIAL), these changes could expand or contract the scope of their authority, prompting you to redesign portions of the group structure. Attempts to synchronize permissions to profiles in the FIELD class or the IRR.PASSWORD.RESET profile in the FACILITY class may force you to alter the administrative responsibilities of certain staff to avoid having their scope of authority become too broad. Also, consider possible changes in the scope of authority for users with Class Authorization (CLAUTH) when setting class POSIT values.

As you complete the process of synchronizing each set of overlapping profiles, ensure they stay synchronized until the final merge and implementation. Institute a strict change management procedure and diligently review RACF commands entered each day. For critical classes and profiles, it may be wise to review their synchronization just prior to implementation.

At the conclusion of the synchronization process, you’ll have either completed the migration of all the profiles from one RACF database to the other, or you’ll be ready for the final merge process using a utility such as IRRUT400.

5 Pages