Mainframe installations managing multiple RACF databases serving separate z/OS images may find significant advantages in merging them to form a single shared database. Chief among these advantages is establishing consistent security across multiple system images. Another is reducing and simplifying security administration by eliminating multiple executions of the same commands. Furthermore, when a shared database is implemented in a Sysplex, the installation can activate several valuable performance tuning features.

The creation and implementation of a common shared database can be quite complex depending on the extent to which profiles overlap and implementation philosophies differ between the existing separate databases. For example, we’ve encountered situations where the JESSPOOL profiles are designed to be sysout owner-centric (second qualifier in the resource name) on one database and job name-centric (third qualifier) on another. These two profile design approaches don’t mesh well and remediation is required. The entire merge effort must be performed with great care to ensure current production work isn’t disrupted on any of the affected systems. This article outlines the process for merging databases and provides tips and strategies for successfully completing the effort.


First, consider the ultimate objective of the project. Are you:

• Building a merged database to be shared by several system images?

• Merging z/OS images along with RACF to form a single z/OS image?

• Migrating certain applications and their RACF profiles from one image to another?

• Building a merged database that will be copied to multiple systems and maintained using RACF Remote Sharing Facility (RRSF)?

Your objective will determine the level of coordination and staff participation necessary and dictate the sequence of tasks to be completed.

Now you need to obtain management commitment. This may be the most important step because senior management must understand that significant staff resources may be needed to prepare the databases for merger and that multiple Initial Program Loads (IPLs) may be required to implement changes. This may force management to forego certain Service-Level Agreement (SLA) commitments. Management directives also may be needed to suspend non-essential RACF administrative work and unrelated RACF projects, allowing staff to focus on this effort and avoid the added complexity caused by a constantly changing RACF environment.

5 Pages