The z/OS IBM mainframe has the capability to act as a hypervisor and host virtual LINUX machines using a facility called z/VM. If you have these systems, then how do you move them when you are refreshing your storage, or maybe to balance out the I/O in existing storage? If you are an FDRPAS user, then you will be familiar with the principle of moving data between disks with systems actively using the data. FDRPASVM is essentially just FDRPAS with a z/VM monitor added, so FDRPAS can move z/VM volumes while being aware of any updates that happen on the z/VM side.

Innovation introduced FDRPASVM for z/VM users in January 2014. FDRPASVM enables non-disruptive migration of volumes containing z/VM mini-disks, full pack mini-disks, and volumes dedicated for CMS users Linux for System z and other guest's file systems. It works in conjunction with FDRPAS on z/OS, but you do not need to be familiar with both the z/OS and z/VM sides of the operation to move z/VM volumes. If you are a z/VM person then you can drive the migrate process from z/VM by using the z/OS FTP server. It has a special mode (site filetype=JES) that allows you to submit jobs from z/VM with a PUT and copy the output of the job back with a GET. If you are a z/OS person, then once you get the z/VM components installed, you can drive all the migrations from the z/OS side using either an ISPF interface, or batch jobs.

In September 2014, Innovation added support for CP-Owned volumes including Page, Swap, SYSRES and PARM DISK.
FDRPASVM can be licensed with or without licensing FDRPAS for z/OS (but it does require that FDRPAS be installed on z/OS)

How does FDRPASVM Work?

FDRPASVM works with two tasks, a SWAP task that runs on z/OS and does the actual data movement, and a monitor task that runs on z/VM which intercepts all disk updates that happen while the swap task is running. It communicates those changed tracks back to z/OS so they can be recopied.
To run FDRPASVM you need to create two virtual machines, a CMS machine to store the code and a service virtual machine to do the monitoring. Once the CMS machine is created you install the FDRPASVM code on it and the complete install process takes less than an hour

FDRPASVM is a volume to volume move. The original volume is called a 'source' volume and the new volume is the 'target' volume. The volume status needs to be:
On z/VM, the source volumes must be online and the target volumes must be online and free.
On z/OS, the source volumes must be online and the target volumes must be offline.

The full process works like this.

Generally speaking, FDRPASVM will migrate a 3390-9 volume in about 3 minutes, depending on how busy it is. You can migrate several volumes at once, 20 concurrent migrates is not unusual. Innovation recently released a user experience note that stated that the user moved 64 3390-54 VM volumes in 14.9 minutes in a GDPS hyperswap environment.

Special Considerations

FDRPASVM supports migration of both Single System Image (SSI) clusters and non-SSI systems. When migrating an SSI system, you must run the FDRPAS MONITOR on all members of the SSI cluster, and you must update the PDVOL value in both the IPL parameters and the SAPL record.

If your disks can be accessed by more than one LPAR, then either the DASD must be offline to other LPARs, or a FDRPASVM monitor task must be running on all LPARs with the DASD online. For EMC DASD and IBM DS8800 and DS8700 DASD with the Query Host Access (QHA) feature installed, FDRPAS and FDRPASVM can determine which LPARs have the volume onlines and fail the task if monitors are not started.

Getting information about disk space usage in z/VM is not too easy, so Innovation has created a REXX EXEC named CALCDASD that can be run on each z/VM system and report on the amount and status of the DASD. You can run this EXEC and send the output to INNOVATION to get assistance with your migration planning.

CALCDASD EXEC reports on type and size of DASD, that is it reports on how many 3390-1, 3390-2 etc. disks exist. It will identify CP-Owned, SYSTEM and ATTACHED disks, and free, offline and PAV alias devices
If all the dasd belongs to z/VM, then no operands are required as shown in the first example below, the second example shows how to check a range of disks. Other operands are available, and you can see them all the the 'help' command as shown in the third example.

calcdasd 0F10-0F2F
calcdasd help

FDRPASVM has a 'SWAPDUMP' function that creates a point-in-time (PIT) backup copy of volumes. Any tracks that are changed while the backup is in progress are intercepted and applied at the end of the dump to get a true PIT copy.
You can also predict how moves will happen without actually moving or copying data by using simulate functions SIMSWAP and SIMSWAPMON.

There are special considerations when swapping from smaller to larger volumes with minidisks defined using the 'END' keyword in the z/VM User Directory. If this applies, then you should first modify the user directory entries to specify the exact ending cylinder
For example, if you are moving from 3390-9s to 3390-27s, and you have minidisk statements with '1 END', you should update all user directory entries with '1 10016'. This way, the Linux disks will remain the same size, and the remaining space will be available for other minidisks.

CHECKSOURCE and CHECKTARGET work a little different than from FDRPAS.
Don't use CHECKSOURCE=YES as it is used by FDRPAS to check the z/OS VTOC and since z/VM volumes do not have a z/OS VTOC, you will get error messages if you do.
CHECKTARGET=YES can be used. It will check that the target volumes are offline to z/OS, but it unlike the z/OS FDRPAS process, it cannot check that there are no data sets in the z/OS VTOC, so this check is just bypassed without any error messages.

FDRPASVM can move volumes that are under GDPS Hyperswap control, but as FDRPAS cannot swap a volume while it is eligible to be swapped by HyperSwap, the process temporarily disables HyperSwap for the minimum amount of time while FDRPAS does its swaps, and then re-enables HyperSwap.

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. Because of this requirement, FBA devices can not be swapped as they are not currently supported on z/OS and are not supported by z/VM HyperSwap.

You should specify NONRESPONDING=RETRY on the SWAP command as if there is an LPAR that has the volume online but does not have a monitor running, the move will fail. This means you will not move a disk that is active on another system, and so corrupt the data.

FDRPASSV is designed to be run as a disconnected virtual machine, you use FDRPAS CMS commands to send swap and control commands to it. It is recommended that you leave the service virtual machine running disconnected, so if you want to monitor every message sent to the console, it is recommended that you set up a secondary console.

When a move completes, the original source volume will have a z/OS volser of FDRxxx and the VOL1 field will not say 'VOL1', so the volume will not come online at IPL time. Use the FDRPAS RESETVOL command to change the vol labels to get it online.

Any configuration statements that contain real unit addresses, such as User Directory and System Config files, must be changed before the next IPL, as the move will relocate the volume to a different address. If possible, it is better to use the volser rather than the unit address.

CMS commands

The FDRPAS CMS command is used to communicate with the FDRPASVM service machine. The main CMS keywords are 'MONITOR TYPE SWAP'. The full syntax of the command is


First, note that the DURATION and SWAPDELAY options start with a bracket '(', but there is no closing ')' bracket. CMS command syntax states thet the ending parenthesis is optional, so it is usually not coded.

The target devices can be a single device, a list of specific devices, or a range of devices specified with wildcards. To use a wild card, you must specify between one and three starting characters of an address range, followed by '*'. For example, 1F* will monitor all devices between 1F00 and 1FFF. Addresses can only be used as target devices if they are ECKD disks that are free and online to z/VM. If you specify a range of addresses, those addresses that are elligible will be monitored and the rest ignored.

DURATION n - Specifies the number of idle minutes that the volume watch thread executes. The volume watch thread terminates when it has been idle for a total of this many minutes.
SWAPDELAY n - Specifies the number of seconds between 1 and 255 that the FDRPASVM service machine waits between scans of the eligible target devices it is monitoring to see if an FDRPAS SWAP task has selected one of them as a SWAP target. The default is 5 seconds.

Once you have an FDRPASVM monitor running on every z/VM LPAR that accesses the disks you want to move, you move the disks from the z/OS side as described on the FDRPAS page

Other CMS commands include:


Used to terminate the FDRPASVM service machine. It will terminate if there are no volumes being monitored or swapped.


Used to stop the volume watch thread from monitoring devices for new swaps. It will terminates if there are no active swaps, but if there are any active swaps, it waits for them to complete and then terminates.

back to top

Data Migration

Enterprise Disk

Lascon updTES

I retired 2 years ago, and so I'm out of touch with the latest in the data storage world. The Lascon site has not been updated since July 2021, and probably will not get updated very much again. The site hosting is paid up until early 2023 when it will almost certainly disappear.
Lascon Storage was conceived in 2000, and technology has changed massively over those 22 years. It's been fun, but I guess it's time to call it a day. Thanks to all my readers in that time. I hope you managed to find something useful in there.
All the best