Migration

If you install a new release of the AD CD-ROMs, you potentially lose all the customization you have done with your old release. This includes:

򐂰 Changes made to RACF. The RACF database is on the OS39M1 volume. If you have defined new users or groups, changed or added general resource profiles, protected data sets, and so forth, you are unlikely to want to repeat all these steps again for a new release.

򐂰 Catalog entries in the master catalog. As distributed, any data sets that you catalog will be cataloged in the OS/390 master catalog.:fn.If your data sets have HLQs that match those used for catalog aliases defined in the AD system, such as DLIB, then these would be cataloged in one of the predefined user catalogs. Of course, these AD user catalogs are on volumes that are replaced by a new release, so they are also lost.

򐂰 Spool contents. This is usually not considered a serious problem.

򐂰 Normal configuration data sets such as SYS1.PARMLIB, SYS1.VTAMLST, TCP profiles, procedure libraries, and so forth.

򐂰 Modules you may have added (or altered) in various system load libraries.

Some (but not all) of these areas are handled by the migration jobs included with OS/390 AD CD-ROM releases. However, the migration jobs are designed only for moving from release n to release n+1; that is, they assume you install every new release. Because of this, and because the migration jobs do not automate all the release-to-release transition, you may want to manage your own release transitions and not use the migration jobs.

4.10.1 Managing your own migration

Moving to a new OS/390 or z/OS release can be a major undertaking in a large, complex installation, and there are many ways to go about it. Even in a small P/390-size installation there can be many ways to go about it. One way is embodied in the migration jobs that are supplied with the AD CD-ROM systems. If you plan to move to every new release of the AD CD-ROMs, you should consider using the migration jobs—this should require less effort than managing your own migration to new releases.

Managing your own migration to new releases may not be difficult if you establish some early

discipline in managing your OS/390 system. To use the process described here, you must: 򐂰 Keep track of all changes you make to SYS1.PARMLIB, SYS1.VTAMLST, system

procedure libraries, TCP/IP profiles, and so forth. For example, every time you change one of these members, you could copy the changed member to a TSO library on one of your local volumes.

򐂰 Isolate all catalog activities for your users into one (or more) user catalogs. In practice, this means adding an ALIAS to the master catalog for every TSO user (or major application suite) you define. It means ensuring that there are no entries in the master catalog for any locally-defined data sets. Establishing a user catalog and ALIAS

definitions should be done before defining any local TSO userids; otherwise, these new

userids will generate entries in the master catalog and you will not be able to define an ALIAS for them.

򐂰 Keep a list of the ALIAS names you have added to the master catalog.

򐂰 Keep all local data sets off the volumes provided by the CD-ROMs, so that they can be replaced without losing any of your files.

򐂰 Create your own /u file system on one of your local volumes; that is, your own HFS data set with the mount point /u.

򐂰 Establish and use your own RACF database. (You may be required to run one or two of the AD migration jobs, to update your old RACF data base with any new RACF class

descriptions and new profiles. These job(s) are the most valuable migration jobs provided

with the AD system.)

If you have established the disciplines just described, then moving to a new release is fairly simple:

򐂰 Delete the old release volumes, or keep them if you have sufficient disk space.

򐂰 Install your new release from the CD-ROMs and IPL it.

򐂰 Log on as userid P390 and take the following steps:

– IMPORT your user catalog. (See “How to migrate your user catalog” on page 134.) – Add your list of ALIASs to the new master catalog.

– Reapply your changes to SYS1.PARMLIB, SYS1.VTAMLST, and so forth. This will take some time, since you may need to verify that some of the changes are appropriate for the new release. If you maintained sufficient discipline to record your changes, as outlined previously, this step should go fairly smoothly. When finished, re-IPL to ensure there were no drastic errors. At this point, you can recover by simply unzipping the SCPMV5 volume (which contains parameter data sets you are updating) from CD-ROM again.

– Uncatalog the distributed RACF data bases (main and backup), and catalog your old RACF data bases. (This assumes they have the same names.)

This process will lose any new RACF profiles that are included with the new OS/390 release. This may or may not be a problem for you, and a resolution will depend on manual action. If your P/390 OS/390 system is used in a well-controlled environment (where no one is actively attempting to attack the system), you can probably ignore missing RACF profiles for new product data sets. If you know the HLQs for new product data sets, you can easily add a RACF generic profile to protect the product data sets.