Special considerations for installation

This section describes the following FDRPASVM consideration. 

• Special considerations
• Supported DASD hardware considerations
• PAV considerations
• GDPS considerations
• FlashCopy considerations
• Smaller to larger migration considerations

Special considerations

• Review the FDRPAS Special Hardware Considerations. These apply to z/VM as well as z/OS.
• The physical devices involved in a SWAP must be supported by the underlying z/VM HyperSwap support, and by the FDRPAS z/OS main SWAP task. See Supported DASD hardware for more details.
• FDRPASVM supports EAV volumes. For systems prior to z/VM 6.2, refer to IBM APAR VM64709 for the PTF numbers required to add this support to your system.
• Due to legacy DASD volume serial number handling in z/VM, the volume serial number of the original source volume from a completed SWAP, the target volume of an incomplete SWAP, or the target volume of a completed SWAPDUMP is not displayed correctly. When the volume label record is read by the z/VM DASD label routines, if the VOL1 field does not contain the characters VOL1, the 6 character volume serial number is taken from the six bytes starting at the beginning of the VOL1 field. The first three characters of the volume serial number are FDR, the fourth is the number 2, 3, or 4, followed by the first two characters of the actual volume serial number. This keeps the volumes offline because z/OS does not mount DASD devices that do not have a “proper” volume label. For volumes in this state that need to be reused, you can use RESETVOL from the z/OS version of FDRPAS instead of fully initializing the volume. Refer to the MONITOR RESET and VARYONLINE Statement for instructions on how to do a RESETVOL.

Supported DASD hardware considerations

FDRPAS and FDRPASVM support any kind of DASD volume that can be brought online to a z/OS system, from any manufacturer. This includes the following:

• DASD attached by FICON or ESCON channels
• DASD in CKD or ECKD format
• Full-volume Linux DASD in Compatible Disk Layout (CDL) format
• Extended Address Volumes (EAV), i.e. volumes with more than 65,520 cylinders)

The following DASD types are not supported:

• Those attached by Fibre Channel Protocol (FCP) channels
• Those in Fixed Block Architecture (FBA) format - this includes z/VM emulated devices
• Full-volume Linux DASD in Linux Disk Layout (LDL) format

Definitions Using Real Unit Addresses

Review your User Directory and SYSTEM CONFIG File for any DEDICATE statements or ATTACH commands specifying a REAL unit address instead of a volume serial. When a volume is swapped, the unit address is changed, so these definitions would point to the source device instead of the target. They must be updated before the next IPL of the virtual machine (for DEDICATE) or the next use of the ATTACH command.

Example, before SWAP:

Volume LFDATA is swapped from real source device 4620 to real target device 1620.

Volume MYVOL2 is swapped from real source device 3481 to real target device 5237.

You could change the above to: 

In most cases, it is preferable to specify volume serials instead of device addresses.

If you change to volume serials, you can make the change in advance of the SWAP.

PAV considerations

If PAV or HYPERPAV is defined to any source or target disks, FDRPASVM  fails the SWAP/SWAPDUMP operation. FDRPASVM follows the same rules that HyperSwap follows.

Turning PAV/HYPERPAV off and on with z/VM must be done at the SSID level. You can query the SSIDs on your system with the CP QUERY CU command using both the DEVICES and ALIASES options. For example:

This example shows the devices and aliases for two CUs. To vary all aliases offline for a CU, 8101 in this example, perform the following steps:

1. All active aliases must be DETACHed from virtual machines. Before being detached, they should be disabled on Linux. On a Linux system that uses PAV aliases, query the DASD devices with the lsdasd command.

   # lsdasd
   Bus-ID Status Name Device Type BlkSz Size Blocks
   ==============================================================================
   0.0.0200 alias ECKD
   0.0.0201 alias ECKD
   0.0.0100 active dasda 94:0 ECKD 4096 2347MB 601020

2. The previous example shows two alias devices, 200 and 201. Disable them on Linux with the chccwdev -d command.

   # chccwdev -d 200
   Setting device 0.0.0200 offline
   Done
   # chccwdev -d 201 Setting device 0.0.0201 offline
   Done

3.  Detach the devices. In this example, the Linux vmcp command is used to issue the CP DETACH of the two devices.

   # vmcp detach 200 201
   0200 0201 DETACHED
4. Repeat the previous steps for all Linux systems with PAV base volumes in the CU.

5. On a privileged z/VM virtual machine such as MAINT, detach the PAV alias devices. In this example, they are rdevs A380-A38F.

   ==> detach a380-a38f system
   DASD A380 DETACHED SYSTEM HYPERPAV ALIAS
   …
   DASD A38F DETACHED SYSTEM HYPERPAV ALIAS

6.  Vary off all of the PAV alias devices with the VARY command.

   ==> vary off a380-a38f
   A380 varied offline
   …
   A38F varied offline
   16 device(s) specified; 16 device(s) successfully varied offline

7. Turn PAV off for the SSID with the SET CU NOPAV command. In this example, the SSID is 8101.

   ==> set cu nopav 8101
   Command complete

   The base DASD volumes can now be migrated using the FDRPASVM SWAP function.

After the SWAPs are complete, the PAV/HYPERPAVs can be turned back on by reversing the order of the commands.

1.  Attach the alias devices to SYSTEM.

   ==> attach a380-a38f system
   DASD A380 ATTACHED TO SYSTEM HYPERPAV ALIAS
   …
   DASD A38F ATTACHED TO SYSTEM HYPERPAV ALIAS

2. Redefine the alias devices with the CP DEFINE command. In this example, the two aliases at virtual device addresses 200 and 201 are redefined on the Linux system using them.

   # vmcp DEFINE HYPERPAVALIAS 200 FOR BASE 100
   DASD 0200 DEFINED
   # vmcp DEFINE HYPERPAVALIAS 201 FOR BASE 100
   DASD 0201 DEFINED

3. Enable the alias devices with the Linux chccwdev -e command.

   # chccwdev -e 200
   Setting device 0.0.0200 online
   …
   # chccwdev -e 201
   chccwdev -e 201
   Setting device 0.0.0201 online
   …
   Done
4.  Repeat the previous two steps for all Linux systems using PAV alias devices in the SSID.

The alias devices should now be ready for use by all Linux systems.

GDPS considerations

If GDPS/PPRC HyperSwap is active for z/VM as well as z/OS volumes, these volumes can be migrated following the procedure in FDRPAS and IBM GDPS/PPRC HyperSwap in the z/OS FDRPAS manual. To swap such volumes requires a special procedure, including the CONFIRMSWAP=YES operand on the SIMSWAP and SWAP statements. FDRPAS cannot swap a volume while it is eligible to be swapped by GDPS HyperSwap, so this procedure automates the process of disabling GDPS HyperSwap for the minimum amount of time while FDRPAS does its swaps, and then re-enables GDPS HyperSwap.

FlashCopy considerations

If volumes are migrated to a different control unit, and DFSMSdss FlashCopy is being used on z/OS to create backup copies of those volumes, you must recreate the FlashCopy target volumes on the new control unit (For example, with ICKDSF CPVOLUME or ICKDSF INIT or FDRINITV INITVTOC or FDRERASE EMPTYVTOC), because the hardware FlashCopy feature is only available between volumes that are in the same control unit. Also, ensure FASTREPLICATION(REQUIRED) is specified on such DFSMSdss jobs prior to starting the migration. Otherwise, with the default of FASTREPLICATION(PREFERRED), if the job is submitted before you recreate the FlashCopy target volumes on the new control unit, the hardware FlashCopy feature will not be available and DFSMSdss will perform a conventional physical copy. The physical copy will run for a long time, and will hold a RESERVE on the FlashCopy source volume, causing the volume not to be accessible from any system except the one running the DFSMSdss job, for the duration of the copy operation.

If FDRINSTANT FlashCopy is being used with FDR, FDRDSF or, FDRABR to create backup copies, you must update the MOUNT commands to point to devices in the new control unit (FLASHUNIT=dddd). There is no need to initialize the new FlashCopy targets, because with FDRINSTANT the FlashCopy targets are always offline. FDRINSTANT FlashCopy backup has no equivalent of FASTREPLICATION(PREFERRED); the operation will always fail, as desired, if FlashCopy cannot be used.

Smaller to larger migration considerations

It may be decided to migrate from smaller to larger 3390 volumes. When this is the case, the LARGERSIZE=OK operand must be used on the SWAP statement. After the SWAP, the cylinder allocation table of the target volume is rewritten so that all added cylinders are PERM cylinders. For example, if you are copying from a 3390-9 with all PERM cylinders to a 3390-27 with 32760 cylinders, the source allocation table will have 10017 PERM cylinders, while the allocation table of the newly copied target volume will be set to 32760 PERM cylinders.

When doing such migrations, minidisks should not be defined with the END keyword. For example if you are migrating the 3390-9 volume with a volume serial of VM1887 to a 3390-27, and you have a minidisk statement in the user directory such as the following:

Before the virtual machine is logged off and logged back on again, the statement should be changed to:

If this is not done and a Linux system has a formatted file system on that minidisk, I/O errors will be reported on the console because Linux will detect a partially formatted disk. The Linux dasdfmt command has no ability to format part of a minidisk.