Migrating an ADCD z/OS release to the next release: OMVS

Start here:Migrating an ADCD z/OS release to the next release.

There are several parts to migrating OMVS.

  • Making your user file systems available to the new level of z/OS
  • Making data from your old system file systems available to the new level of z/OS. Files I updated and copied include
    • /etc csssmtp.env this is used in the mail protocol procedure CSSMTP
    • /etc/hosts this is used in TCPV4 name query lookup
    • /etc/pkiserv/… for the PKI Server for managing digital certificates
    • /etc/resolv.conf this is used in TCPIP DNS
    • /etc/gskssl/… for system ssl.
    • /etc/syslog.conf for managing the SYSLOGD daemon, and where (TCPIP) Unix tasks write their output in the file system
    • /etc/zexpl/… for use with RSEAPI procedure, and z/OS Explorer
  • Copying any customisation from the old system to the new system. This should be in the /etc directory, or in the JCL procedures.
  • Checking your overall OMVS configuration is consistent

The ZFS for /etc is ZFS.S0W1.ETC. This is the same on the Z31A, and the Z25D systems, so cannot you use both copies on the same system. This means you need to use backup and restore; or copy the files to a ZFS which can be used on both systems.

Making your user file systems available to the new level of z/OS

This should just be a matter of making sure your BPXPRMxx with your mount statements is used in the new system, and IPLing with the correct IEASYS member.

HFS is not supported on z/OS 3.1 so you will need to migrate these to ZFS before you try to migrate; and remove and HFS definition statements.

Making your old system file systems available to the new level of z/OS.

On the old system I found all the files I had changed in /etc, and backed them up to a PAX file. I could have copied the directories to a user ZFS file system.

The potential directories of interest are

  • /etc this has configuration files for system tasks such as syslogd
  • /var this contains log files etc as used by system tasks. You usually do not want to copy the files across.
  • /opt program product information which you usually do not want to copy across

How do you find changed files?

See How do I diff on Z/OS with Unix files and directories for a full description.

You can use the command ls -ltr . to list files in the current directory, with the latest changes at the bottom of the list. Or you can use the find command

find . -mtime -100 -a -type f

which lists the files within the last 100 days (-mtime -100); -mtime 100 is exactly 100 days ago; -mtime +100 is over 100 days ago. This way is not very helpful. You can say find files newer than ‘this’ file.

You can create an empty file and set the date on it using

touch -t 2401181400 ~/Jan182024.file    

Where the -t value is yymmddhhmm

You can list files changed more recently than this file file using

find . -newer ~/Jan182024.file  -a -type f

This gives you a list of files

You can use a command to do more processing. The following also lists information about the files.

find . -newer ~/Jan182024.file   -a -type f -exec ls -al {} \;   

How to backup files

You can pipe the information from the find command into other commands such as pax. This takes the stream of filenames, and copies the file contents into a PAX fiile.

find . -newer ~/Jan182024.file  -a -type f | pax -W "seqparms='space=(cyl,(30,30))'" -wzvf "//'COLIN.PAX.TEST2'" -x os390

On the other system you can read the pax file and load the files.

How to see what’s in a pax file

You can see what is in the pax file use

pax   -vf "//'COLIN.PAX.TEST2'" 

Note of warning. You should be careful backing up and restoring when using absolute path names. See Oh p*x, I’ve lost my changes.

How to restore the data

pax -rfk  "//'COLIN.PAX.TEST2'"  

Where the -k option means do not overwrite.

Checking your overall OMVS configuration is consistent

You can use the D OMVS,PFS command to display the in use physical file systems. Issue this command on both old and new systems, and compare the output

z/OS 2.5D D OMVS,PFS output

The -FS GFSCINIT data is for an HFS file system. You need to remove any FILESYSTYPE TYPE(HFS) ENTRYPOINT(GFSCINIT) … entries from systems before using z/OS 3.1

OMVS     0010 ACTIVE             OMVS=(TC,00,01,BP,IZ,RZ,BB,ZW,US)                               
PFS CONFIGURATION INFORMATION
PFS TYPE ENTRY ASNAME DESC ST START/EXIT TIME
-FS GFSCINIT N/A U 2024/08/29 12.56.04
INET EZBPFINI N/A SOCKETS I
-FS GFSCINIT N/A U 2024/08/29 12.56.03
ZFS IOEFSCM N/A LOCAL A 2024/08/29 12.55.59
AUTOMNT BPXTAMD N/A LOCAL A 2024/08/29 12.55.59
UDS BPXTUINT N/A SOCKETS A 2024/08/29 12.55.59
CINET BPXTCINT N/A SOCKETS A 2024/08/29 12.55.59

PFS TYPE DOMAIN MAXSOCK OPNSOCK HIGHUSED
UDS AF_UNIX 10000 2 2
CINET AF_INET6 50000 4 4
AF_INET 64000 8 9

SUBTYPES OF COMMON INET
PFS NAME ENTRY START/EXIT TIME STATUS FLAGS
TCPIP EZBPFINI 2024/08/29 12.56.24 ACT SC
TCPIP2 EZBPFINI INACT
TCPIP3 EZBPFINI INACT
TCPIP4 EZBPFINI INACT

z/OS 3.1A D OMVS,PFS output

Note the missing entry for -FS GFSCINIT.

OMVS     0010 ACTIVE             OMVS=(TC,00,01,BP,IZ,RZ,BB,ZW,US)      
PFS CONFIGURATION INFORMATION
PFS TYPE ENTRY ASNAME DESC ST START/EXIT TIME
INET EZBPFINI N/A SOCKETS I
ZFS IOEFSCM ZFS LOCAL A 2024/08/29 13.00.24
AUTOMNT BPXTAMD N/A LOCAL A 2024/08/29 13.00.24
UDS BPXTUINT N/A SOCKETS A 2024/08/29 13.00.24
CINET BPXTCINT N/A SOCKETS A 2024/08/29 13.00.24

PFS TYPE DOMAIN MAXSOCK OPNSOCK HIGHUSED
UDS AF_UNIX 10000 2 3
CINET AF_INET6 50000 4 4
AF_INET 64000 8 8

SUBTYPES OF COMMON INET
PFS NAME ENTRY START/EXIT TIME STATUS FLAGS
TCPIP EZBPFINI 2024/08/29 13.01.05 ACT SC
TCPIP2 EZBPFINI INACT
TCPIP3 EZBPFINI INACT
TCPIP4 EZBPFINI INACT

One thought on “Migrating an ADCD z/OS release to the next release: OMVS

Leave a comment