Your final step is to complete the merge and implement the combined database across all system images. The tasks involved here will be determined by the merge technique you’ve chosen. If you’ve simply copied profiles using commands generated by IBM’s free DBSYNC utility, all changes will probably have been done well before implementation. Then, all you need to do on implementation day is copy passwords to the new combined database using IBM’s free PWDCOPY utility. If you’re using IRRUT400 to perform the final merge to combine databases, note that this utility wasn’t designed for use in merging dissimilar databases. Immediately after combining the databases, you’ll need to perform additional steps to correct database integrity errors that will emerge. Examples of such errors are broken group connects and dropped access list entries.
Here are some general guidelines to follow in implementing the merged database:
• Execute the final merge steps and implement the shared database during a system maintenance period dedicated to the merge effort while all other system activity is suspended
• Before proceeding, confirm you can log onto and execute RACF commands at the system console so you can enter commands to change RACF options or profiles to recover from mistakes that might prevent Time Sharing Option (TSO) or JES from initializing
• Ensure IRRUT200 backups are prepared and accessible
• Have RVARY command passwords readily available
• Test, test, test
• Be on-call and standing by for rapid problem resolution through at least the first full normal workday and production batch cycle.
Once your z/OS images are running with the new merged database, ensure all performance-enhancing options have been implemented so no system is delayed waiting for RACF to service another. At a minimum, make full, effective use of the Global Access Table, RACLIST, and RACGLIST classes. (For more on this, see the article “10 Ways to Improve RACF Performance” in the October/November 2006 issue of z/Journal.)
Conclusion The process of building a merged, shared RACF database isn’t simple; it requires painstaking analysis. Synchronization of systems and their databases will often require substantial adjustments, which must be implemented with great care. Nonetheless, any RACF administrator who has progressed from managing separate databases to maintaining a single merged one will tell you that the effort was worthwhile. Your management also will be pleased to see the savings in staff resources resulting from the reduction in administration and database maintenance. Finally, your auditors will appreciate the control consistency and ease of auditing inherent with a single RACF database. This is definitely a win-win project. Z