Migrating an ADCD z/OS release to the next release.

With traditional z/OS you upgrade products one at a time. For example, you use one release of CICS, install the next release of CICS, and check it works. You then roll it out to all z/OS images. You take the next product and repeat it.

With z/OS you create a new IPL image, using all of the old components, such as master catalog, page sets etc, do a test IPL and resolve any problems.

With ADCD you have one complete system for example with system data sets on volumes beginning with D4, and the next “release” has volumes beginning with D5. It is not just a matter of IPLing the new system because your data, and any configuration you did will not be on the new system.

In this post, I’ll cover some of the steps you need to take to be able to run on a newer level of ADCD. The list will not be complete or detailed enough, so please let me have any suggestion and comments to improve it.

What to you need to think about?

There is a series of pre-requisites that are needed in the migration process.

My initial thoughts list is

  • Define the zPTD devmap configuration file with the new disks, so the new and old systems can see all of the DASD volumes
  • In any old configuration you want to use, change explicit volumes to their symbolic volume. The operator command D SYMBOLS gives you the symbol names. For example change ….Z24C… to …&SYSVER… This means it will pick up the current level which ever system you have IPLed
  • Import any user catalogs
  • Define the alias for COLIN.* data sets into the new master catalog. You can now use COLIN.* data sets from the new system.
  • Use your old RACF database, or make a copy for the new system to use
  • Copy system Unix files. For example in /etc/. It is easiest to backup and restore them
  • Copy user Unix files. If you have a ZFS for all your files, this may be as simple as mounting it on the newer system. If you have files in the system provided file system, you will have to backup and restore them, or move them to your ‘user ZFS’.
  • Copy across your members in USER.* members. it is worth reviewing these and deleting old ones which are not used. I compared the USER.old.parmlib members with the ADCD.old.parmlib member to see what changes I had made. 
  • Once you IPL the new system it will use your new members
  • Copy across ICSF definitions
  • Check out all started tasks.

First steps

You need to copy data sets and files from the old system to the new system, for example user.z24c.proclib to user.z25d.proclib. It is easiest to have the volumes from both systems available to the z24 and z25 systems.

The user.z24c.proclib will be cataloged on the z24 system, and the user.z25d.proclib will be cataloged on the z25 system, so you’ll need to cross catalog the data sets. These configuration data sets will be on the xxCFG1 volume, so you can use ISPF 3.4, specify the volume and use the ‘C’ line command to catalog the datasets so they can be seen on both systems.

User data – for example all my RACF define jobs are in a PDS under COLIN. These are in a user catalog which can be imported into the newer system.

You need to create an alias in the master catalog

DEFINE ALIAS (NAME(COLIN ) RELATE('A4USR1.ICFCAT') )

With this, I can now refer to COLIN.* data sets from the older system.

Detailed instructions

TCPIP

I had to change the TCPIP Resolver (of IP names and addresses).

In ADCD.Z31A.TCPPARMS(GBLTDATA) I changed the commented LOOKUP statement. Then I stopped and restarted the RESOLVER. Without this change requests to lookup caused 30 second delays.

; LOOKUP DNS LOCAL 
; Colin's change 
  LOOKUP     LOCAL 

Using the RACF DDS server I got messages

ICH420I PROGRAM GPMDDSRV FROM LIBRARY SYS1.SERBLNKE CAUSED THE
ENVIRONMENT TO BECOME UNCONTROLLED.

I also needed to do the RACF commands

RALTER PROGRAM * ADDMEM('SYS1.SERBLNKE'//NOPADCHK)
RALTER PROGRAM * ADDMEM('SYS1.SGRBLINK'//NOPADCHK)
SETROPTS WHEN(PROGRAM) REFRESH

Save and copy /etc

2 thoughts on “Migrating an ADCD z/OS release to the next release.

Leave a comment