DASD volume migration
The zPDT package includes a client-server utility for moving 3390 volumes from a remote z/OS or z/VM system to zPDT. The server portion of this utility runs under z/OS or z/VM on the remote z System. The remote is typically a large z System, but it could be another zPDT system. The client portion runs on the base Linux of your zPDT machine.1 The client and server are connected via TCP/IP. This utility is especially useful when transferring many volumes to a zPDT system.
The server portion (on the remote z/OS or z/VM) reads all the tracks on a selected volume and sends them to the client (on the local base Linux). The client transforms it into the emulated 3390 format used by zPDT and writes it as a Linux file. You then use this file as an emulated volume under zPDT.
There is no “reverse migration” function available through this client/server operation. If you need to copy a 3390 volume from zPDT to a “real” 3390 you can use the ADRDSSU program, as described in 12.11, “Moving 3390 volumes” on page 232.
One volume is processed for each client command that is sent to the server. You can create a Linux script with multiple invocations. The server portion (on z/OS) requires specific RACF authorizations. It can copy active volumes, although the usefulness of the copy might be questionable, depending on the volume activity at the time. The z/VM version requires that the server program has access to the full volumes being sent.
The speed of the copies depends on the TCP/IP bandwidth between the client and server, and the contents of each track. A considerable amount of data is involved on a typical 3390 volume; the transmission may take some time.
A conceptual overview is shown in Figure 15-1 on page 296.
Figure 15-1 Volume migration overview (z/OS version)
15.1 Warnings
There are limitations on simply copying and using volumes from a z/OS system (and also from a z/VM system, with slightly different details). These limitations are not related to zPDT or to the migration utility described in this chapter. A z/OS disk volume is not necessarily a stand-alone entity, depending on what is on the volume. In particular, if the volume contains VSAM data sets of any type (including catalogs) then the volume contents are usable only if the complete VSAM metadata is available. Volume AAA may contain a VSAM data set that is cataloged on volume BBB. The VSAM information on volume AAA (including metadata in the VVDS) must be synchronized with the catalog information on volume BBB. In this simple example, migrating (copying) both volumes might suffice, provided the catalog on volume BBB is later properly connected to the master catalog on the target system.
In general, volumes that do not contain VSAM data sets (or VVDS material) are safer to migrate in a stand-alone fashion. Migrating all the volumes of a z/OS system should be safe because this includes all the relevant catalogs and VSAM data volumes.
A special warning is related to the migration utility described in this chapter. No enqueue or serialization functions are used by this utility. Transferring an active volume is probably not a good idea. If the volume is active, it might have logical errors when the transferred copy is used. For example, the VTOC might not reflect an additional extent that was allocated after the tracks containing the VTOC were copied, or the contents of a z/VM minidisk on the volume might be changing as the associated tracks are copied.
With a z/VM system, the VM directory must be synchronized with any migrated DASD volumes containing minidisks.
15.2 Operational characteristics of the migration utility
The following characteristics of this utility are important:
•Complete volumes are transferred. This includes IPL text, volume labels, VTOC, and unallocated space. The logical contents of the volume are not examined. Data sets on the volume are not recognized. The utility simply copies and transfers all the tracks on the volume. It does not check whether the tracks are allocated (VTOC or VM equivalents) or in use (ENQ) or linked to a specific catalog (for VSAM, for example).
•A read track CCW is used to read the data on each track of a CKD volume. The amount of data on each track is variable. This means the time to transmit a volume is variable, depending on how much data is on each track.
•Track data is not compressed for transmission.
•The source z/OS or z/VM (where the server component runs) is typically a large z System, but this is not required. It could be a zPDT system. The receiving Linux side must be a Linux system with zPDT installed (but probably not active). The received copy of the source disk volume is stored in the awsckd (or awsfba if appropriate) format used by zPDT.
•Specific RACF definitions are required for the source z/OS side. These definitions can protect the utility from misuse.
•The utility server program must reside in an authorized library for z/OS.
•The utility server program is typically started as a batch job. It automatically terminates after 10 minutes of inactivity.
•The utility client program is run as a normal Linux command. It is possible to create a script file with multiple transfer commands so that multiple volumes may be transferred in an unattended manner.
•TCP/IP port 3990 is used by default.2 The port number may be changed when starting the server and client.
•Both 3380 and 3390 volumes, any size, can be migrated. This includes 3390 EAVs (“large volumes”).
•In practice, this utility is likely to run unattended because copying multiple volumes can take considerable time. We suggest you first try a single volume and monitor the operation while it is running.
•Only one transfer may be active for the server. It is possible to run multiple servers in parallel (with different IP port numbers for each) but the usefulness of this is questionable.
•The z/OS version is only for the migration of CKD DASD volumes. The z/VM version can migrate CKD and FBA DASD volumes.
15.3 Installation of the migration utility for z/OS
Several steps are required to install the migration utility:
1. Upload the server module (named ZOSSERV.XMIT) and install it in an authorized z/OS library. (The server module is provided in the /usr/z1090/bin directory that contains all the zPDT executables. It is an unloaded PDS member that has been processed by the TSO XMIT command.)
2. Provide the required RACF definitions.
3. Determine whether TCP/IP port 3990 (on the z/OS side and the Linux side) has been assigned for other purposes and ensure that the port can pass through any firewalls.
4. Create a batch job to run the server.
15.3.1 Server installation
File /usr/z1090/bin/ZOSSERV.XMIT must first be uploaded (binary) to a z/OS data set with DCB characteristics RECFM=FB, LRECL=80, BLKSIZE=3120. This XMIT file contains an unloaded PDS load library with one member. You can begin restoring this material by preallocating two data sets with the following job:
//OGDEN77 JOB 1,BILL,MSGCLASS=X
// EXEC PGM=IEFBR14
//A DD DISP=(NEW,CATLG),UNIT=3390,VOL=SER=ZBSYS1,SPACE=(TRK,5),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120,DSORG=PS),
// DSN=IBMUSER.SEQ.HOLDING
//B DD DISP=(NEW,CATLG),UNIT=3390,VOL=SER=ZBSYS1,SPACE=(TRK,(3,3,3)),
// DCB=(LRECL=0,BLKSIZE=32760,RECFM=U),DSN=IBMUSER.PDS.HOLDING
(The volser and DSNs are arbitrary. An experienced z/OS system programmer can handle this upload and installation in multiple ways. We present a basic example here. You can, for example, use ISPF to create these two holding data sets.)
After the receiving data set is ready, use binary mode and either IND$FILE3 or FTP to transfer /usr/z1090/bin/ZOSSERV.XMIT to IBMUSER.SEQ.HOLDING. It is a relatively small file. Be certain to use a binary transfer.
After the module is uploaded to the sequential holding data set, issue the following TSO commands (using the appropriate data set names, of course):
RECEIVE INDATASET('IBMUSER.SEQ.HOLDING')
INMR901I DATASET ......
INMR906A Enter restore parameter or 'DELETE' or 'END' +
DATASET('IBMUSER.PDS.HOLDING')
INMR001I Restore successful ....
The name of the executable module, once restored, is ZPDTMSRV. You must select an authorized library (preferably on the LNKLST) to contain the server module. You must have authority to update this library. We use USER.LINKLIB as an example of an authorized library in the LNKLST, but your system is probably different. Userid IBMUSER typically has update authority for all system libraries and we use this userid in our example. Again, your system may be different.
Copy member ZPDTMSRV from your holding PDS to your authorized library. The easiest way to do this is by using ISPF option 3.3. In the first panel (of ISPF 3.3), make this selection:
Option=====> c
....
(“from” data set name)
Name. . . . . . . ‘IBMUSER.PDS.HOLDING’
(press Enter)
(“to” data set name)
Name. . . . . . .’USER.LINKLIB’
(press Enter)
. ZPDTMSRV (overtype the period with the letter S and Enter)
This completes the server installation. The holding data sets can be deleted.
15.3.2 RACF requirements
|
Important: Consult with the RACF administrator for your server z/OS system before making any RACF changes. This is especially important if the DASDVOL class is active in the installation.
|
The server program requires RACF class DASDVOL to be active and the server program must have at least READ access to all volsers to be transferred. You must determine whether the DASDVOL class is active and used on the system where you install the migration utility server. You can do this by logging on to TSO with a userid having RACF SPECIAL authority and issuing these TSO commands from a READY prompt or ISPF option 6:
SETROPTS LIST (check the list of active classes)
RLIST DASDVOL * (see if any profiles are defined)
If these checks are negative, you can assume that the DASDVOL class is not being used.
DASDVOL not already in use
The next step is to decide whether only certain volumes should be subject to copying by this migration utility or whether all volumes might be accessed for migration. If you elect to potentially allow migration of all volumes, enter these TSO commands:
SETROPTS CLASSACT(DASDVOL) (activate the DASDVOL class)
SETROPTS RACLIST(DASDVOL) (optional, but recommended here)
RDEFINE DASDVOL ** UACC(ALTER) (allow universal alter access)
SETROPTS RACLIST(DASDVOL) REFRESH (if you RACLISTed the class)
Be aware that the DASDVOL class is used only by a selected group of utility programs, such as dump/restore. Allowing UACC(ALTER) does not open all your data sets to access by all users. Whatever RACF data set protection you have in place (via ADDSD and PERMIT commands) is still effective.
This is all the RACF setup requires if DASDVOL was not initially active and if you want to allow the migration server to access any volume. If you want to limit the volumes subject to migration, you should work with an experienced RACF administrator. The general technique is to restrict global access to DASDVOL (perhaps with a UACC(NONE) condition) and then issue PERMIT commands to cover the volumes you want to migrate. For example:
PERMIT VOL123 CLASS(DASDVOL) ID(IBMUSER) UACC(READ)
PERMIT ADCD* CLASS(DASDVOL) ID(IBMUSER) UACC(READ)
SETROPTS RACLIST(DASDVOL)REFRESH (if you RACLISTed DASDVOL)
In this example, volser VOL123 and any volser beginning with ADCD can be accessed by the migration utility.
The use of the DASDVOL class might have side effects on other utility programs. If DASDVOL was not active before your migration activities, you might want to deactivate it when the migration activities are completed:
SETROPTS NORACLIST(DASDVOL)
SETROPTS NOCLASSACT(DASDVOL)
DASDVOL already in use
If you find that the DASDVOL class is active on your server system, we strongly suggest that you discuss the situation with the system programmers managing that system. Your requirements are simple: you (meaning the userid who will run the migration server program) need DASDVOL with READ access to whatever volsers you intend to migrate.
TCP/IP port
By default, the migration programs use TCP/IP port 3990, but this can be changed. You can look at the TCP/IP PROFILE on the z/OS system to see whether port 3990 is reserved for another application. However, another application could dynamically acquire the port. There is no easy way to prevent this. We suggest specifying a different port number only if there are error messages when you try to start the migration server or client. Someone must also verify that whatever firewalls are active will allow port 3990 communication.
15.4 Operation of the server under z/OS
The server should not be started until you are ready to use it. It automatically terminates after ten minutes of inactivity. The following JCL could be used to start the server:
//MIGSERV JOB 1,OGDEN,MSGCLASS=X,TIME=1440
//ZPDTMIG EXEC PGM=ZPDTMSRV,REGION=0M,PARM='3990'
//SYSUDUMP DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTCPD DD DISP=SHR,DSN=ADCD.Z21Z.TCPPARM(TCPDATA)
Consider the following notes:
•The TIME=1440 parameter is suggested because transmitting a full volume (or several volumes) can take considerable time. (It is much less than 1440 minutes!)
•The PARM field specifies the TCP/IP port number to be used. We suggest port 3990 unless you have a specific reason to use a different port.
•The SYSTCPD statement must point to the DATA used by the z/OS TCP/IP stack. You must determine the correct data set name for your z/OS system. One way to do this is to examine the procedure used to start TCP/IP on your system.
•If your authorized library is not in LNKLST, you will need a JOBLIB or STEPLIB statement that references only authorized libraries.
•The user submitting this job must have a userid that has at least READ access to the appropriate volsers in DASDVOL.
15.5 Installation of the server under z/VM
The z/VM system must be Release 5.4 or later.
The ZVMSERV.XMIT file is located with other zPDT binary material in /usr/z1090/bin on the zPDT system. This must be uploaded in BINARY, FIXED LRECL 80 format to a CMS user’s A disk. (This file essentially contains a card deck.)
After this is complete, use the following steps from CMS:
1. Issue the CP SPOOL PUN command.
2. Issue the PUNCH ZVMSERV XMIT A (NOH command.
3. Issue the RDRLIST command.
4. Beside the file in your RDRLIST, issue RECEIVE command.
This results in the reconstructed executable file on your CMS A disk, and completes the server installation.
15.6 Operation of server under z/VM
Your z/VM must have TCP/IP active and connected to the appropriate network. The CMS user running the migration utility must have access to the volumes to be migrated.
The CMS user starts the utility by issuing a ZVMSERV command; a single operand specifies the TCP/IP port number and this defaults to port 3990. When started, the server should indicate that it is waiting for a client connection. The server will time out after 10 minutes without a client connection.
If a z/VM mini-disk is migrated, it will appear as a small 3390 volume on the receiving system. That is, it will no longer be a mini-disk on a larger z/VM volume.
15.7 The client commands
There are two client commands:
•hckd2ckd: Used with both z/OS and z/VM to migrate a CKD DASD volume.
•hfba2fba: Used only with z/VM to migrate a FBA DASD volume.
This general syntax of the client commands (entered on the Linux client machine, using a normal Linux command window) is as follows:
hxxx2xxx host[:port] outfile [-v xxxxxx][-u aaaa]
[--volser xxxxxx][--unit aaaa]
Where:
host is the TCP/IP name of the system with the matching server program. This might be a dotted-decimal address or a name that can be resolved by Linux TCP/IP.
:port is a TCP/IP port number to be used by both the client and server program. It defaults to 3990. Note: recent experience indicates the port number does not default correctly; we suggest you always include the port number in your command.
outfile is a file name (on the current Linux) system where the migrated volume is placed (in awsckd, awsfba, or awstape format).
-v or --volser indicates the 3380/3390 volume (on the remote z/OS system) that is to be copied (migrated).
-u or --unit indicates the address (device number) of the volume that is to be copied (migrated).
Either the -u or -v parameter must be supplied for DASD, but not both; the -u parameter is normally used for tapes.
After the server is started on the z/OS or z/VM system, the client may be started on the Linux system. Remember that zPDT need not be operational for this. (We generally suggest that it not be operational, because the migration utility can place a heavy load on the LAN interface.) Examples of commands that could be used to run the client are as follows:
$ hckd2ckd 192.168.1.99:3990 /z/VOL123 -v VOL123
$ hckd2ckd BIG.ZOS.ADDR:3990 /z/VOL678 -u A8F
$ hckd2ckd 192.168.1.99:3990 /z/host.WORK23 -v WORK23 --norestart
The first operand is the IP address of the z/OS system where the server is running. The TCP/IP port number can be changed as shown in the examples, where we use port 3990. (The server must have been started using the same port number, of course.) The second operand is the Linux file name used to store the migrated volume. Either the -v or -u parameter must be specified. The -v parameter is a volser and the -u parameter is a device address (device number) on the server system; these determine which volume is to be processed.
15.8 Additional notes
After a volume is migrated to Linux, you can add it to your devmap and access it from zPDT. You should check the permission bits for the file. (The zPDT system must have read/write access to it.) Our examples are in terms of z/OS volumes, but the volume could be for z/VM, z/VSE, or Linux for z Systems.
Linux volumes
We discovered an interesting situation when migrating Linux for z System volumes. Our particular experience was with SLES-10 SP1 (for z System), but it might apply to other distributions.
With many Linux distributions, several fstab options can be selected for controlling disk volume mounts. These include mounting by device name, volume label, UUID, device ID, or device path. The default is often to mount by device ID. This produces a boot parameter list (and fstab) something like this:
parameters='root=/dev/disk/by-id/ccw-IBM.750000000M1881.2c23.1c-part1'
This disk identification is unique to the original disk drive and is useless when the volume is copied or migrated to another disk. In this situation, the migrated Linux volumes could not be booted. This identification is best changed when installing Linux by selecting the use of a volume label (for example, LABEL=rootfs) or device name (for example, /dev/dasda1) when initially creating the disk partitions. The naming can be changed later by carefully editing /etc/zipl.conf and /etc/fstab. In any event, the naming should be changed before migrating the volumes. Unfortunately, it is not always obvious how to select which disk naming convention should be used when installing Linux.
Multiple TCP/IP stacks
A z/OS system with multiple TCP/IP stacks presents an additional complication. In this situation, an additional step is needed in the server job:
//MIGSERV JOB 1,OGDEN,MSGCLASS=X,TIME=1440
//STEP0 EXEC PGM=BPXTCAFF,PARM='TCP342'
//*
//ZPDTMIG EXEC PGM=ZPDTMSRV,REGION=0M,PARM='3990'
//SYSUDUMP DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTCPD DD DISP=SHR,DSN=ADCD.xxxx.TCPPARM(TCPDATA)
The BPXTCAFF program is used to associate a specific TCP/IP stack with the current address space. The PARM value is the job name used to start the desired TCP/IP stack.
Typical client usage
A typical use of the client might be as follows:
$ hckd2ckd 192.168.1.81:3990 /z/ZBRES1 -v ZBRES1
AWSHTC090I Host name : 192.168.1.81:3990
AWSHTC091I Restart : No
AWSHTC095I Vol-Ser : ZBRES1
AWSHTC096I Output : /z/ZBRES1
AWSHTC097I Transferring 3990 vooume of 3339 cylinders
AWSHTC098I Cylinder nnnn ...
We found that transferring a fairly full 3390-3 volume on a private 100 Mbps LAN took approximately 11 minutes. This consumed roughly 150 processor seconds on the source z/OS system (which was a different zPDT system on a moderate-performance PC).
When the migration is complete, the cylinder number displayed is one less than the actual number of cylinders transferred. Also, there might be a delay (perhaps up to 30 seconds) between the last message and the time the command ends. Both these conditions are normal.
Migrating a list of volumes
Using gedit or another editor, you can create a Linux file named, mig, for example. The mig files contains this information:
hckd2ckd 192.168.1.81:3990 /z/ZOS111/ZBRES1 -v ZBRES1
hckd2ckd 192.168.9.01:3990 /z/ZOS111/ZBRES2 -v ZBRES2
hckd2ckd 192.168.9.01:3990 /z/ZOS111/ZBSYS1 -v ZBSYS1
hckd2ckd 192.168.9.01:3990 /z/ZOS111/ZBUSS1 -v ZBUSS1
hckd2ckd 192.168.9.01:3990 /z/ZOS111/backup/MYVOL1xx -v MYVOL1
You can start the server program on the z/OS host and then run the commands that are in your .mig file:
$ ./mig (execute the commands in file named mig)
This transfers all the volumes that are listed, without any further manual intervention.
1 zPDT need not be operational while this utility is being used. Due to expected LAN and disk activity, it is probably better to use the migration utility when zPDT is not active.
2 Recent experience suggests that the default is not working. You should specify a port number; use port 3990 unless you have a reason to use a different port number.
3 IND$FILE is a z/OS program that works with the “file transfer” function present with many 3270 emulators.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.