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.

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!

A few general facts about FDRMOVE

The userid that is used to run FDRMOVE jobs must have ALTER access to all datasets, and this can be a security exposure. You can reassure your security department by using the STGADMIN facility
You then need to give your userid access to profile STGADMIN.ADR.STGADMIN.MOVE. This means that security checks are bypassed and your userid has access to move any dataset. However this only applies to the FDRMOVE program, you will have not special access to any datasets for anything else. This, of course, would be an ideal solution for external workers like consultants or contractors!

FDRMOVE cannot work with datasets that are not enqueued. Consult Innovation and your manuals for the latest list, but some datasets to watch for are: JES Proclibs, SPOOL and checkpoint datasets; Page and Coupling facility datasets; CICS journals, catalogs and ML1 volumes. An especial issue is NON-SMS managed APF authorised libraries, as they are volser specific. Just to emphasise, consult the FDRMOVE manual and speak to Innovation too.

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 into a new storage pool. DISABLENEW=YES means that the source volumes will be set to SMS DISNEW. By default, FDRMOVE will try to move 8 volumes in parallel. MAXTASKS=6 means limit this job to 6 disks in parallel. 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.

//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. FASTMOVE cannot be used with GDPS Hyperswap or EMCs Autoswap.
One issue for migrating off older subsystems 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. You need at least as many transit volumes as you have source disks as FASTMOVE can concurrently handle as many source volumes as there are transit volumes. 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 job is sized for mod27s, the VTOC on each volume will be 750 tracks in size and located at track 15 (second cylinder on the volume). The volumes are initialised as SMS and so need to be added to a relevant SMS storage group.

//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

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