While FDRPAS moves volumes non-disruptively, FDRMOVE moves datasets.

As the number and sizes of datasets continue to grow, small disks are less attractive. If you need to add more capacity to a 500GB storage pool, then adding a single 2.84 GB 3390-3 disk will not make much difference. When you migrate to new hardware then that is usually a good opportunity to re-design your storage set-up and move to bigger volumes. The problem is that while FDRPAS will move one 3390-3 to a 3390-9, it is then up to you to fill up the rest of the volume. Also, while FDRPAS will let you use the extra free space when migrating to a bigger volume, it will not increase the size of a VTOC, a VVDS or a VTOCIX.

    GFS Advert

Because FDRMOVE moves data at the data set level, it can be used to consolidate smaller disks onto larger disks with minimal or no disruption. You cannot move datasets while they are open to applications, so FDRMOVE will probably move ninety percent of the datasets of a volume straight away, but the other ten percent will be in use. The FDRMOVE task then carries on running for as long as is necessary, and will keep checking the ENQ on an active dataset until it is released, at which point the dataset will be moved. The majority of datasets will eventually be picked up this way, but it may be necessary to stop an application or de-allocate databases to free up the ENQ on stubborn files. The downtime required for this might be as little as a few seconds, but it will obviously depend on the number and size of datasets waiting to be freed up and whether you are performing a MOVE or a FASTMOVE operation as described below.

A word of warning. If you are running in a multiple LPAR environment then you will have some software active to manage cross system ENQs. MIM or GRS are the usual products. Make sure that these products will remain active while your FDRMOVE jobs are running. I was caught out years ago when moving datasets, probably using DFDSS in COPY - CATALOG mode. Half way through the moves a systems programmer arrived on-site to do some maintenance work on MIM and brought it down. My move jobs happily pulled the legs away from under a couple of CICS systems. Unlucky maybe, or maybe I should have checked the change schedule more closely!

   EADM Advert

Accelerate DB2 Write with zHyperWrite and "EADM™ by Improving DB2 Logs Volumes Response Time:

A few general facts about FDRMOVE

  • FDRMOVE has a parameter to set SMS managed source volumes to 'DISNEW'. This stops new data sets from being allocated to the source volumes while the move is in progress.
  • FDRMOVE will move data sets between disk volumes in the same disk subsystem, or between disk volumes in different subsystems and between different hardware manufacturers.
  • FDRMOVE supports the normal comprehensive Innovation selection criteria, including dataset masks, volume masks and storage pools. You can both select or exclude objects. Specifically, you can select both source and target volumes individually, by a naming pattern mask, or by storage pool name. This last feature lets you drain all the files out of a specified storage pool.
  • The FDRMOVE process can be safely suspended and resumed at any time as the source dataset remains catalogued until the target file is completely moved.
  • An FDRMOVE licence includes FDRPAS, both for internal use, and to use as a stand alone product to move whole volumes.

There are two versions of FDRMOVE , MOVE and FASTMOVE.


MOVE is just the standard move process discussed above. FDRMOVE will move data sets by selection criteria as soon as they are free. The move process is disruptive as it has to scratch each data set from the source volume then recatalog it to the target. However the move process is fast, typically 1.5 minutes per GB, so the disruption is minimal. As soon as the move process is complete for that data set, the data set is available for normal use.

In the example below, we are draining an entire storage pool to a new set of volumes with VOLSERS starting DB3. DISABLENEW=YES means that the source volumes will be set to SMS DISNEW. These are DB2 files, so it would be advisable to check after a day or so and see if any databases need to be de-allocated to allow the files to be moved.
Running this as a single job is easy, but it would be faster to split the pool up into volumes and run several jobs in parallel. I guess it depends on what your objectives are at the time.

//STEPLIB DD DISP=SHR,DSN=your.pas.library

MOVE can be used to clear down an old disk subsystem, and the process may require several iterations and take a week or two, with a little bit of downtime.
If you want to clear out an old system quickly, and cannot afford much downtime, then FASTMOVE is the better option.


FASTMOVE makes use of instant snapshot products as discussed in the SnapCopy section to quickly move data sets. The problem is that snapshot products will only work within a subsystem, they cannot be used to move data between subsystems. Innovation has solved that issue by temporarily copying an entire disk into the new subsystem, then moving the datasets within the subsystem using a snapshot facility. This is a three stage process. FASTMOVE initially calls FDRPAS to temporarily move the source volume onto a 'transit volume' in the new subsystem. It then uses fast data replication facilities like FlashCopy, EMCSNAP or SnapShot Copy to copy the selected data sets from the temporary 'transit volumes' to their eventual target disks as soon as those data sets become available. Once all the selected datasets are copied, FASTMOVE will call FDRPAS again to move the temporary disk back to the original subsystem. The process in a bit more detail goes like this.

FASTMOVE invokes a special FDRPAS job which non-disruptively moves the entire selected volume to the new disk subsystem. To do this, it needs a pool of temporary offline disks that it calls 'transit disks'. These need to be at least as big as the original source volume, and can only hold one of the source volumes. FASTMOVE can concurrently handle as many source volumes as there are transit volumes, so the more transit volumes the better. The FDRPAS process follows normal FDRPAS rules, and needs an FDRPAS MONITOR job started on all LPARs. See the FDRPAS page for details.

FASTMOVE now starts to move individual datasets from the transit volumes to the eventual target volumes. This just like a normal MOVE process, except that it is much faster as the move runs at internal hardware snapshot speeds. FASTMOVE is fast, but will be restricted by the number of moves that can happen in parallel, and the number of datasets that need to be recataloged. 1TB per minute is quite possible. However, as with a MOVE operation, FASTMOVE cannot move a data set until it is inactive. This means that at some point long running applications may need to be stopped and restarted to get an open dataset freed up. The actual downtime should be minimal, minutes or maybe even seconds.

Phase 3: FDRPAS SWAP (Back to source)
Once it has finished moving all the selected datasets off a transient volume, by default, FASTMOVE will invoke FDRPAS to move that transient volume back to the source on the old subsystem. This is because FASTMOVE works at dataset level and you may not want to move all the datasets off a volume. This phase also frees up a transient volume for another swap.

However you have the option when terminating a FASTMOVE, to specify TRANSITRETURN=NO, which keeps the volume in the transient station. This means that when you resume the FASTMOVE, it does not need to invoke another Phase 1 Swap, but will restart from where it left off with the transient disk. You may also want to use this option when the old subsystem has already been scrapped.


This is an example of a FASTMOVE job selecting all data sets from 6 source volumes (IMS001 to IMS006) and moving them to set of output volumes with volsers beginning IMS2
If FASTMOVE finds that one or more source volumes must be moved to a transit station in the target control unit, it will submit the FDRPAS job pointed to by the PASJOB DD, which in this example is stored in PDSE member OJ.FDRPAS.CNTL(PASJOB). The MOUNT statement will be internally replicated for each volume which may need to be moved to a transit station, substituting the actual volume serial for &&&&&&. In this example, the transit stations will be all offline disk devices in the range of 3200 to 32FF.

//STEPLIB DD DISP=SHR,DSN=your.pas.loadlib

//STEPLIB DD DISP=SHR,DSN=your.pas.loadlib

It is always worth running FDRMOVE in simulation mode before doing it for real. As well as checking that your command syntax is correct, a simulation will list out every dataset that will be moved and the volumes they are on, and whether or not those datasets are currently ENQ'd. It will test out the FDRPAS transit job, and tell you how many transit volumes it needs.

The example below simulates clearing all the data off volumes starting DB000, except DB002 which is excluded. The data will be moved to a range of volumes starting DB1.

//STEPLIB DD DISP=SHR,DSN=your.pas.library


Before a MOVE or FASTMOVE can move any data onto a target disk in the new subsystem, the target disk must contain a VTOC. While you can initialise these disks with ICKDSF. FDRINITV will let you initialise ranges of disks with one job.

In the example below, FDRINITV will create a VTOC on a range of disks (A000 to A00F). The volumes will be given a VOLSER comprising the unit address and a prefix of DB - e.g. DBA000, DBA001 etc. The VTOC on each volume will be 750 tracks in size and located at track 15 (second cylinder on the volume):

//STEPLIB DD DISP=SHR,DSN=your.pas.loadlib


FDRMOVE includes a function to dynamically expand a VTOC on a volume, even if the volume is active on one or more LPAR. You would typically use this when you have moved a smaller volume onto a larger one with FDRPAS, and now want a bigger VTOC to move more datasets onto the target volumes.

The VTOC will be expanded in place, so EXPANDVTOC will move datasets out of the way if necessary by invoking FDRCPK. If the datasets are in use, then the EXPANDVTOC job will invite you to release them. It will automatically resize the VTOCIX too. This function requires an FDRPAS MONITOR task to be running on all LPARs so that those systems can also be updated with the new VTOC, VTOCIX and VVDS information.
Be aware that EXPANDVTOC puts a hardware reserve on the VTOC and VVDS and the job could run for several minutes. You should be converting those reserves to global ENQs as otherwise all access to the volume from other LPARs will be inhibited during the expansion.

Below is an example of a FDRPAS EXPANDVTOC job. The VTOC will be expanded to a new size on volume GNL002.

//STEPLIB DD DISP=SHR,DSN=your.fdrpas.loadlib

back to top