A DASD migration guide

A DASD migration guide

As the ‘DASD farm’ becomes an increasingly important

component of the IT department, a substantial
proportion of systems programmers’ time is spent on
disk migration. Although 3390 disk geometry is now
standard, migration from 3380 to 3390-style disks is
not uncommon. This chapter examines the
methodology and pitfalls of any DASD migration.

DFDSS

DFDSS is the instrument of choice to automatically move files from disk to

disk. DFDSS COPY offers two kinds of processing:

• Physical – tracks are copied from the source volume to the target
volume (of course, tracks not allocated are not copied). This is the
fastest method, ideal when device types are the same (or differ only by
capacity, the target being the largest). The source volume can be in use
(in read mode) while it is copied. Our experience shows that up to 100
gigabytes can be moved in an hour (with state of the art disks).

• Logical – tracks (or records, or blocks) of allocated files are copied from
the source volume to the target volume. Logical copy is mandatory with
unlike device geometry (3380 to 3390), which is the most problematic
situation. Only unallocated files can be moved to another volume.
DFDSS in general does all the work; system utilities are invoked in a
few cases for unlike device types (IEBCOPY for loadlibs, or IDCAMS
for KSDS). IDCAMS (EXPORT/IMPORT) is used for user catalogs.
Rare utilities like IEHMOVE and IEBISAM are called when required.

A very useful precaution is to run in advance the DFDSS jobs with the
parameter PARM=‘TYPRUN=NORUN’, to detect both syntax errors and
potential problems with datasets.

DFDSS physical move

For copying the contents of volume xxx to volume yyy, the following JCL is
recommended:

© 1999. Reproduction prohibited. Please inform Xephon of any infringement. 1

 //CPxxx EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//FROM1 DD VOL=SER=xxx,DISP=SHR,UNIT=SYSALLDA
//TO1 DD VOL=SER=yyy,DISP=SHR,UNIT=SYSALLDA
//SYSIN DD *
COPY INDD(FROM1) OUTDD(TO1) FULL ALLDATA(*) ALLEXCP -
TOL(IOERROR) COPYVOLID

COPYVOLID ensures that the volume serial number from the source
volume will be copied to the target volume. As two on-line volumes cannot
bear the same name, the target volume will be set off-line as soon as the
copy is finished. So to continue, you will have to:

1 Set the source volume OFF-LINE (this is only possible if no job is

currently allocating it).

2 Set the target volume ON-LINE.

3 Reinitialize (ICKDSF INIT) or reformat (ICKDSF RFMT) the source

volume.

Should step 3 not be performed (eg because step 1 cannot be performed),

the following message will be received during the next IPL:

IEA213A DUPLICATE VOLUME vvv FOUND ON DEVICES dd1 AND dd2

One must then reply with the device number of the disk not to be used
afterwards. Your operators will not thank you if they have not been
previously informed. Unfortunately, you cannot avoid this scenario when
handling some system volumes that can never be set off-line (SYSRES,
mastercat volume, etc).

ALLDATA(*) and ALLEXCP are used to copy all the allocated space (even
if not used). This is useful for files like the JES spool (that may appear
empty to the system, but are not).

DFDSS logical move

For moving all files from volume xxx to volume yyy, the following JCL is
recommended:

//CPxxx EXEC PGM=ADRDSSU

//SYSPRINT DD SYSOUT=*
//FROM1 DD VOL=SER=xxx,DISP=SHR,UNIT=SYSALLDA
//TO1 DD VOL=SER=yyy,DISP=SHR,UNIT=SYSALLDA
//SYSIN DD *
COPY LOGINDD(FROM1) OUTDD(TO1) TOL(IOERROR) -
ALLDATA(*) ALLEXCP ADMIN PURGE -
DELETE RECAT(*) ALLMULTI WAIT(0,0) -
DS(INCL(**),EXCL(SYS1.VTOCIX.*,SYS1.VVDS.*)) PROCESS(UNDEF)

2 © 1999. UK telephone 01635 33848, fax 01635 38345. USA telephone 940 455 7050, fax 940 455 2492.
 A DASD migration guide

Subparameters used:

• ALLDATA(*) – copy all the allocated space (files not empty).

• ALLEXCP – copy all the allocated space (empty files); DFDSS will not
do it in all cases (IBM provides a table about ALLDATA and ALLEXCP
interactions).

• ADMIN – to avoid any security problems with moving files (you must
be authorized with only READ access to the STGADMIN.ADR.
STGADMIN.COPY.DELETE profile in the FACILITY class).

• PURGE – you can override unexpired files on the target volume.

• ALLMULTI – catalogued multi-volume files are copied in their entirety

(the risk being filling upthe target disk).

• WAIT(0,0) – do not waste time waiting for files that are in use (and
won’t be moved anyway).

• PROCESS(UNDEF) – copy (to unlike target disk) files with undefined

DSORG.

If the source volume is an SMS-managed one, the ‘//TO1’ card should be

omitted, as should the OUTDD parameter. The job should be preceded by a
‘V SMS,VOL(xxx),D,N’ command to disable new allocations for this
volume. Sub-parameters to consider in some cases are:

• PROCESS(SYS1) – copy files with a high-level qualifier of SYS1.

• SPHERE – copy all AIX related to the base clusters you want to move
(not recommended AIX may be copied even if not on the volume you
want to empty – this may generate a no space left condition on the
target disk).

• BYPASSACS(**) NULLSTORCLAS – to bypass SMS rules (this is not

generally recommended).

The system parameters that need to be updated when disks or datasets are
moved incude:

• IODF and IOCP – of course, addresses for new units must be defined.
Always keep old addresses for some time, in case of fallback.

• LOADxx in PARMLIB or IPLPARM – when the master catalog has

been moved.

• SYSCATLG (or SYSCATxx) member of SYS1.NUCLEUS – if you still

use it and the master catalog has been moved.

• EDT – if esoteric names are used in your JCL, sufficient volumes must
be linked to them so as to avoid JCL errors (EDT changing is now
dynamic with HCD). It is simpler to adapt the EDT than to update the
'UNIT'= parameter in thousands of JCL files!

© 1999. Reproduction prohibited. Please inform Xephon of any infringement. 3

 • APF list – to be updated, whether it be IEAAPFxx (static) or PROGxx
(dynamic) in PARMLIB, every time an APF-authorized dataset was
moved. No need to modify it for SMS-managed libraries or libraries
located on the system-resident volume (generic entries).

• VAT list (VATLSTxx) – for volume use attributes (use generic entries
whenever possible). Often a co-requisite with EDT update, because
disks used for non-specific allocation must be declared with the storage
or public attribute.

• SMS parameters – new SMS volumes must belong to declared storage

groups.

• HSM parameters (ARCCMDxx) – new primary (or migration, or

backup) disk volumes must be declared (ADDVOL command), migrated
ML/1 disks may be suppressed (DELVOL command), volume pools
must be updated.

• Any program using dynamic allocation can be impacted, including some

product tables (DSNZPARM with DB2), and some definitions
(STOGROUPs for DB2, etc).

• IPL parameters – system-resident disk address and IPLPARM/IODF

disk address (the loadparm parameter) can be affected by DASD
migration.

• IPL texts – they are copied by the DFDSS COPY FULL function.
Consider reinstalling them only after logical copies (SYSRES volume,
stand-alone dump volume).

On-line system file migration

There are some general considerations, when a disk full copy cannot be
undertaken. Many datasets require an IPL for MVS to acknowledge that
they were moved (SYS1.SVCLIB, SYS1.STGINDEX, page datasets like
PLPA or COMMON, SYS1.UADS, mastercat), while others are used only
during the IPL (SYS1.LPALIB, SYS1.NUCLEUS, IODFs, IPLPARM).

In the recent versions of MVS, very few files still reside on the system-
resident volume (only three: SYS1.SVCLIB, SYS1.NUCLEUS and the
optional PASSWORD file). When preparing to move system files, a
precaution is to run the old IPO utility MCNVTCAT to be able to rebuild
entries in the master catalog.

Direct access datasets

It is useful to know how direct access datasets are accessed. This can
either be by track-track record (TTR), which is what DFDSS assumes by

4 © 1999. UK telephone 01635 33848, fax 01635 38345. USA telephone 940 455 7050, fax 940 455 2492.
 A DASD migration guide

default, or by relative block address (less frequent). In the first case,

DFDSS processes the file track by track (COPY TTRADDRESS
parameter), and in the second, this is achieved block by block (COPY
RELBLOCKADDRESS parameter). In the TTR case, DFDSS verifies that
a target track can contain all the blocks of a source track (this is not
obvious when disks differ by geometry). CICS, IDMS, and other DBMSs
may use BDAM files.

Unmovable datasets

Usually, datasets are declared unmovable when DEFRAGing or HSM-

migrating is to be avoided. Datasets with CCHHR location-dependent data
should no longer exist. Nevertheless, DFDSS will try to place unmovable
datasets at the same track locations on the target volume (which must be a
like device), except if the FORCE parameter was specified (then DFDSS
treats them as movable).

Model DSCB datasets

If you have used model DSCB datasets (instead of having a catalogued file
used as a general model for all GDGs, or having SMS manage the GDGs),
do not forget they must reside on the same volume as the related catalog.

JES2 spool

Initialize a spare disk (its name must match the SPOOLDEF VOLUME
parameter). Allocate a spool file (name it according to the SPOOLDEF
DSNAME parameter), whose size will be at least equal to the size of the
active one(s). There is no need to catalog it. Verify the value of the
SPOOLNUM and TGSPACE (or TGNUM prior to SP510) parameters.
Issue a ‘$SSPL,V=newvol,FORMAT’ command. When the formatting is
finished, issue a ‘$PSPL,V=oldvol’ command: little by little, the old spool
file will be drained (as job purges will occur) and eventually JES2 will
unallocate this volume. You can also force JES2 to cancel all jobs that were
using this volume ($PSPL,V=oldvol,CANCEL). Spool offload, followed by
IPL, and spool reload is an alternative.

JES2 checkpoint

The checkpoint is crucial for JES2 processing. There is no need to perform

a JES2 cold start – the checkpoint reconfiguration dialogue should be used
to move it on the fly. Allocate a new checkpoint file, have JES2 know it ($T

© 1999. Reproduction prohibited. Please inform Xephon of any infringement. 5

 CKPTDEF,NEWCKPT1=) and start the migration process ($T
CKPTDEF,RECONFIG=YES). You then reply with the appropriate
FORWARD option. The process is very quick (it takes a bit longer if you
have implemented the multi-access spool mode, because there will be
additional replies). The recent versions of JES2 can dynamically allocate
the space for the new checkpoint dataset. Don’t forget to update the
CKPTDEF parameter in JES2PARM. The process is the same for the
duplex checkpoint ($T CKPTDEF,NEWCKPT2=, etc).

JES2 PROCLIBs

If you want to take no chances, we would recommend that you copy JES2
proclibs without deleting the source file. If an IPL cannot be planned, an
abnormal stop of JES2 can be forced ($PJES2,ABEND), followed by a JES2
hot start.

JES3 spool

Use ‘*F,Q,DD=(oldvol),DRAIN’ to drain the old volume. Unlike JES2, the

new spool cannot be added on-the-fly. A JES3 warm start (or cold start) is
mandatory to take the new spool file into account, whether it be formatted
during JES3 initialization (FORMAT statement in the init deck) or pre-
formatted (using the IEBDG utility to pad the file with X'FF's, and a
TRACK statement in the init deck). Tape offload (dump job) can also be
considered, because it is more handy than JES2 offload.

An alternative (which is rarely used, although IBM mentions it in the

documentation) is to hot start JES3 without the volume to be moved. After
moving the data to the new DASD volume (DFDSS full copy), a hot start
with the dataset (on the new volume) allocated will oblige JES3 to consider
the dataset available again.

Other JES3 datasets

Moving the JCT dataset (a file containing information about the status of
jobs) normally requires a JES3 cold start. IBM also provides a ‘JCTTOOL’
facility to help you. The checkpoint dataset is less of a problem, because it
is used only to avoid reprocessing of the JES3 init deck each time JES3 is
hot-started.

6 © 1999. UK telephone 01635 33848, fax 01635 38345. USA telephone 940 455 7050, fax 940 455 2492.
 A DASD migration guide

SYS1.UADS

DFDSS copy is sufficient for copying SYS1.UADS. From my point of view,

the IBM utility UADSREFM is inferior because it does not copy entries for
logged-on users. You should use the TSO/E SYNC command to synchronize
it with the RACF database and SYS1.BRODCAST. Recatalog the new
SYS1.UADS and IPL your system.

A warning: never use IEBCOPY to move a UADS. If you do so, after

IPLing with this new UADS, no user will be able to log on. This is because
BDAM, not BPAM, is used for accessing the UADS.

SYS1.BRODCAST

There is no problem with SYS1.BRODCAST: allocate a new file on the

target volume and re-SYNC it. Then recatalog it. An IPL is not required.

SMF files

Identify SMF files not currently in use (with the ‘D SMF’ command), suppress
any reference to them in SMFPRMxx, issue the ‘SET SMF=xx’ command to
get them unallocated, recreate them (DELETE, DEFINE CLUSTER with the
MODEL subparameter). Re-update SMFPRMxx and reissue the ‘SET
SMF=xx’ command for SMF to format them. No IPL is required except if you
decide to change their CI size (as all must have the same CI size).

HSM ML/1 volumes

Never use DFDSS to move files between ML/1 volumes. Migrated files are
not catalogued, they are referenced in HSM control datasets, so you must
use HSM commands to move them.

• Prerequisite: the daily autobackup should have been run (verify that
there is no HSM.HBACK file on the volume). If it is not the case, issue
the FREEVOL ML1BACKUPVERSIONS command. Also verify that
there is enough room on other ML/1 volumes, and sufficient SDSP files
(if you use small dataset packing).

• Drain the volume: ADDVOL volser UNIT(3390) MIG(ML1 DRAIN).

• Move the files: FREEVOL MVOL(volser) TARGETLEVEL(ML1) (the

TARGETLEVEL parameter prevents tapes being mounted to receive
files you want to move).

© 1999. Reproduction prohibited. Please inform Xephon of any infringement. 7

 • Unassign the volume from HSM: DELVOL volser
MIGRATION(PURGE).

• HSM.HMIG files remaining on the volume often result from past errors
(HSM being cancelled, job or system crash, etc). You may DELETE
NOSCRATCH the related files (that appear as migrated, but are not known
by HSM), whose name you’ll find by simply browsing the HSM.HMIG files.
You can finally purge these HSM.HMIG files. Any non-HSM user datasets
allocated on ML/1 volume should be moved in the normal way.

HSM back-up volumes

For HSM back-up volumes, the processing is the same as above, the
commands to be used are:

FREEVOL BVOL(volser) TARGETLEVEL(SPILL(DASD)) (or: SPILL(TAPE))

DELVOL volser BACKUP(PURGE)

HSM control files (MCDS, BCDS, OCDS)

HSM control files are normal VSAM files. Stop HSM and invoke DFDSS to
move them. The SDSP files (HSM.SMALLDS.Vxxxxxx) must not be moved,
but can be deleted after a successful ML/1 volume migration.

Public work volumes

No real data migration is normally required for public work volumes, only
MOUNT commands with the PRIVATE attribute in place of the PUBLIC one.

DB2 or IMS databases

There is no problem using DFDSS with DB2 or IMS databases (never use
IDCAMS to move such files). Stop DB2 or IMS, or, alternatively, stop the
files you want to move using the commands:

• -STOP DATABASE(database) SPACENAM(tablespace) for DB2.

• /DBR DB(database) NOFEOV for IMS (/DBR AREA for DEDB bases).

If the IMS databases are used by CICS systems (local DL/I), issue a CEMT
SET DLIDATABASE(database) STOP command (supposing the base was
allocated through a DFSMDA macro).

8 © 1999. UK telephone 01635 33848, fax 01635 38345. USA telephone 940 455 7050, fax 940 455 2492.
 A DASD migration guide

For DB2, ensure that volumes belong to the right STOGROUP. To change
volume affinity, use the ALTER command (ALTER STOGROUP ... ADD
VOLUMES(...) REMOVE VOLUMES(...)).

For IMS, in some rare cases (3380 to 3390 migration and KSDS defined with
the BUFFERSPACE parameter), the index CI size of a HIDAM or HISAM
database may change, which may affect the DFSVSMxx parameters.

CICS user files

If CICS user files were dynamically allocated (no DD card), issue a CEMT
SET DATASET(database) CLOSE command to free them.

IMS CONTROL DATASETS

IMS control datasets apply to special cases, especially in a 3380/3390

migration. The following are examples:

• ACBLIB: run an ACBGEN (BUILD PSB=ALL).

• WADS, RDS, message queues, SPA dataset: /NRE with FORMAT

option recommended.

Some IMS commands allow you to add a new WADS (/START WADS) or
OLDS (/START OLDS) file. These files must be previously defined and
recognized by IMS (DFSMDA macros for allocation, WADS or OLDS
number falling in the defined range).

HFS (Hierarchical File System) files

HFS files are special SMS files for OpenEdition (the MVS flavour of Unix).
They cannot be logically moved by the COPY command with the current
versions of DFDSS, you must use the DUMP and RESTORE functions.

Page datasets

Use the ‘PAGEDEL DELETE,PAGE=dsn’ to drain local page datasets.

PLPA and COMMON datasets cannot be moved. Note that there is no ENQ
protecting page datasets, there is only a flag (UCBPGFL) in the UCB. Allocate
new page datasets to replace them on the next IPL and update the IEASYSxx
member in your PARMLIB. The procedure is the same for swap datasets.

© 1999. Reproduction prohibited. Please inform Xephon of any infringement. 9

Master catalog

The master catalog cannot be moved. AMS REPRO must be used to copy
its contents to a new master catalog. To do this:

• Define the new master catalog (DEF UCAT)

• Repro the old to the new:

//COPYCAT EXEC PGM=IDCAMS

//STEPCAT DD DISP=SHR,DSN=CATALOG.NEWMCAT
// DD DISP=SHR,DSN=CATALOG.OLDMCAT
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
REPRO IDS(CATALOG.OLDMCAT) ODS(CATALOG.NEWMCAT)

• Connect the old one to the new one (useful to delete the old after IPL):

IMP OBJ((CATALOG.OLDMCAT -
VOL(oldvol) DEVT(3390))) CON CAT(CATALOG.NEWMCAT)

• Update SYSCATxx or LOADxx, IPL, and finally, DEL

CATALOG.OLDMCAT UCAT RECOVERY.

SYS1.LOGREC

Allocate a new LOGREC and recatalog it. Use IFCDIP00 to format the new
LOGREC. An IPL is required.

SYS1.STGINDEX

Who still uses Checkpoint/Restart? STGINDEX is an optional file, and the

only risk with it missing is to receive a message during IPL

ILR023I DYNAMIC ALLOCATION OF VIO JOURNALING DATA SET FAILED. NO VIO JOURNALING

The VIODSN parameter (in IEASYSxx) enables you to assign another name
for the STGINDEX file, or, preferably, to avoid using it (VIODSN=IGNORE).

IODF files, SYSn.IPLPARM

There is no problem moving the IODF or SYSn.IPLPARM files, but do not

forget they must reside on the volume pointed to by the first 4 bytes of the
loadparm parameter (when IPLing the system, do not use the master
catalog to locate them).

10 © 1999. UK telephone 01635 33848, fax 01635 38345. USA telephone 940 455 7050, fax 940 455 2492.
 A DASD migration guide

User catalogs

User catalogs are not the easiest part of file migration! They should be
moved only when quiesced. They should not be moved together with the
data sets that are catalogued in them.

Before the move, the catalog should be quiesced and freed on any other
system, through the commands ‘F CATALOG,CLOSE
(CATALOG.USER)’ and ‘F CATALOG,UNALLOCATE
(CATALOG.USER)’. You can move catalogs that are not closed, the risk
being that you receive some time later error messages when VSAM files
are closed (eg when CICS is stopping), because VSAM tries to write
statistics onto the catalog at its previous location.

Locking the catalog prevents users from opening it. To do so, an

IGG.CATLOCK profile must exist in the RACF FACILITY resource class.
This is a JCL to achieve the move:

//LOCKCAT EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*
//SYSIN DD *
ALTER CATALOG.USER LOCK /* prevents any access */
//*
//SAVECAT EXEC PGM=ADRDSSU save the usercat in
case...
//SYSPRINT DD SYSOUT=*
//SAVECAT DD UNIT=SYSALLDA,DISP=(NEW,CATLG),DSN=xxx.SAVECAT,
// SPACE=(CYL,(9,5),RLSE)
//SYSIN DD *
DUMP DS(INC(CATALOG.USER)) OUTDD(SAVECAT)
//*
//MOVECAT EXEC PGM=ADRDSSU move the catalog
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
COPY DS(INC(CATALOG.USER)) DELETE ODY(newvol)
//*
//UNLOCK EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
ALTER CATALOG.USER UNLOCK /* permits any access */

Saving the catalog before the move is a good precaution, because the move
step can be cancelled, or be waiting forever, and there is a risk of getting a
damaged catalog.

A less interesting alternative is to REPRO MERGECAT the source catalog

to a new target one. You must afterwards rectify all the related aliases. If
the catalog is shared between several systems, you must reconnect it
correctly to any other master catalog:

IMPORT OBJ((CATALOG.USER VOL(newvol) DEVT(3390))) -

CONNECT ALIAS CAT(CATALOG.MASTER)

© 1999. Reproduction prohibited. Please inform Xephon of any infringement. 11

 If the foreign system has not taken into account the new location for the
catalog, you may issue a F CATALOG,RESTART command to force it to
do so.

One aspect to consider: do not EXPORT DISCONNECT the catalog before

the IMPORT CONNECT (as you did in the old way of moving a catalog,
before IBM invented IMPORT CONNECT ALIAS), because you would lose
all the aliases related to the catalog.

SMS control datasets (ACDS, COMMDS)

You cannot stop the SMS address space, but the SETSMS command
enables you to use different control datasets. To assign a new ACDS,
define it and issue the commands:

• SETSMS SAVEACDS(new-acds) – to save the current SMS

configuration.

• SETSMS ACDS(new-acds) – to enable the new ACDS.

To assign a new COMMDS use ‘SETSMS COMMDS(new-commds)’. Adapt

the IGDSMSxx member of your PARMLIB.

Linklist libraries

Use DFDSS to copy linklist libraries (no DELETE, use the TOL(ENQF)
parameter), re-catalog them on the target volume, and IPL. If you really
want to move them on-the-fly, use some utilities like RESOLVE (from
Boole and Babbage) or LNKLST statements in PROGxx (beginning with
OS/390 Release 3).

Some libraries are always allocated and will never be moved (linklist
libraries, VTAMLIB, TSO libraries, etc), but will be copied and
recatalogued. It’s a pity that DFDSS does not even allow you to
uncatalog/recatalog files that are in use (DFDSS requires exclusive use to
do so).

SYS1.DUMPxx

Dump datasets can be unallocated by a DD DEL,DSN=(xx) command, and

reallocated by DD ADD,DSN=(xx).

12 © 1999. UK telephone 01635 33848, fax 01635 38345. USA telephone 940 455 7050, fax 940 455 2492.
 A DASD migration guide

SYS1.DAE

You must disable DAE (Dump Analysis and Elimination). Usually IBM
provides an ADYSET01 member in PARMLIB. Try the SET DAE=01
command.

SYS1.PAGEDUMP

SYS1.PAGEDUMP is the stand-alone dump program dataset. This file

must reside on the S.A. volume. No problem if you lose this file (except that
you can no longer invoke the S.A. dump facility). You should regenerate
the S.A. dump program.

RACF databases

RACF databases can be migrated on-the-fly if a back-up database is in use

and the RACF activity is low. A job can be written to automate the process:

• RVARY SWITCH – the primary RACF base is deallocated and replaced

by the back-up one.

• Copy the primary database to a new primary (ICHUT400 or

IRRUT400).

• I would then run an ICHUT200 or IRRUT200 step to validate the

structure of the new RACF database.

• Catalog the new primary base and uncatalog the old one.

• RVARY SWITCH – the new primary RACF database is activated and

the back-up one is deallocated.

• RVARY ACTIVE DATASET(backupbase) – the backup RACF database

is activated again.

The RVARY command must be synchronized on all systems if the RACF

database is shared. The procedure is similar for back-up datasets (you copy
the primary on the new backup file).

CICS journals

CICS journals are sensitive to DASD characteristics. For a 3380/3390

migration, allocate new journals, format them with the DFHJCJFP utility,
then cold start CICS.

© 1999. Reproduction prohibited. Please inform Xephon of any infringement. 13

The most frequent problems with DASD migration

These are actual cases of DASD migration problems that have been
encountered in practice:

1 VSAM files with an expiration date (due to DEFINE CLUSTER issued

with subparameters FOR(days) or TO(date)).

This is a minor problem because it provokes only post-processing

errors. These files are correctly copied to the target volume, the source
files are renamed by DFDSS but not deleted (you receive a code 8 with
the message CATALOG ERROR WHEN DELETING CLUSTER). You
have to purge them manually (DELETE xxx PURGE). If you spot them
beforehand, you should issue the command ALTER xxx
NULLIFY(RETENTION) for each of them before attempting to move
them.

The same problem exists with non-VSAM files with an expiration date
(the consequence of it is the source file remaining on the source volume,
with the same name).

2 Files moved even if they are allocated to other users.

Normally, you cannot move files that are in use, but some products
allocate files with no enqueue (option NO DATASET INTEGRITY in
the MVS program property table). You may move these files to other
disks without any problem, except that those products could receive
some abends due to the fact that their files are no longer on the
volumes they thought they were. Known examples are: PSF, JES2,
JES3 (did you ever try to rename/compress/delete a JES PROCLIB ?...).

The same problem occurs if files are allocated by tasks on a foreign

system and you have no inter-system integrity tool (GRS, MIM).

3 Trying to move files from an unrecognized SMS volume.

The SMS volume must be known by your system (it must belong to an
active storage group in your system) and must not be disabled. DFDSS
will not proceed (even if you try a full volume copy).

4 Volumes referenced in user JCLs (VOL=SER=xxx, DEF CL(...

VOLUME(xxx)), etc) or even in programs (dynamic allocation).

There is no way other than changing all references (IPOUPDTE may be

sufficient for that), except if the volumes are SMS managed (you should
only define the old volume in a dummy storage group, and let SMS
rules guide new allocations). The same problem occurs with
UNIT=3380 in JCL if you are migrating to 3390.

5 Running physical and logical copies together.

Be cautious when physical and logical volume copies are executing in

parallel. For example, if a volume containing a user catalog is

14 © 1999. UK telephone 01635 33848, fax 01635 38345. USA telephone 940 455 7050, fax 940 455 2492.
 A DASD migration guide

physically copied and put off-line while some logical copies are running,
the catalog could become corrupted or contain incorrect entries for files
that were moved by logical copies.

6 Reinitializing a shared disk.

The first thing to do is to set the address off-line on all systems sharing
the disk. Initializing a disk on one system while it is on-line on another
can provoke allocation problems.

The next pitfalls are very common (from my own experience) they all
stem from catalog problems. Catalog management in MVS is so flexible
that there is always a risk of missing something, due to what I call
hidden objects.

7 SMS managed files not catalogued.

This should normally not exist. It is a minor problem, as nobody can

use these files anyway. You should spot them beforehand with a job
like this:

//STEP1 EXEC PGM=ADRDSSU,PARM=’TYPRUN=NORUN’

//SYSPRINT DD SYSOUT=*
//TAPE DD DUMMY
//SYSIN DD *
DUMP DS(INC(**),BY((CATLG,EQ,NO)), -
EXCL(SYS1.VTOCIX.*,SYS%%%%%.T*.**)) OUTDD(TAPE) -
INDD(DD1,DD2,DD3,DD4,DD5,DD6,DD7,DD8,DD9...)
//DD1 DD UNIT=SYSALLDA,DISP=SHR,VOL=SER=sms001
//DD2 DD UNIT=SYSALLDA,DISP=SHR,VOL=SER=sms002

The DDx cards all point to your SMS volumes. These files should be
deleted (if they do not belong to a foreign SMS complex!) with
commands like DELETE xxx FILE(DD1) NVR, or, on the contrary, be
recatalogued (DEF NVSAM ... RECATALOG).

The same problem occurs with VSAM files not catalogued – not a rare
event in many data centres (try DELETE xxx VVR).

8 Moving a file catalogued in a foreign master catalog.

A classic problem with systems sharing disks. The foreign system will
not be informed that its files have been moved (so IPLing this system
can generate nasty surprises). You must recatalog these files properly.
Find them in advance with a LISTCAT ALL command.

9 The hidden catalog entry – moving a file catalogued both in your

master catalog and in a user catalog.

Yes, you may have both a ‘normal’ alias called, say, PROD, and a
PROD.LIBRARY catalogued in the master catalog (try it). This ‘double
cataloguing’ is a trick used sometimes by systems people, often for
linklist or IPA-list libraries. The entry in the master catalog is used
during the IPL phase, while the one in the user catalog will be used the

© 1999. Reproduction prohibited. Please inform Xephon of any infringement. 15

 rest of the time. The problem is that DFDSS, when moving these files,
will update the user catalog, not the master catalog (hence problems
again when IPLing). Look for these files using a LISTCAT ALL
towards your master catalog. The recent versions of ISPF (DSLIST,
option 3.4) now display these double entries. Prepare in advance DEL
xxx NOSCRATCH CAT(mastercat) statements, and DEF NVSAM ...
CAT(mastercat) statements to take the new location into account.

10 The hidden alias – lost when moving.

This is when, for example, your current DFSORT library is called

PROD.SORTLIB (this name is used in all your JCL) but its real name
(on the disk) is SYS1.SORTLIB. When you move it, DFDSS will
recatalog it but the alias PROD.SORTLIB will be deleted (without any
warning). You must recreate it with a command like: ‘DEF
ALIAS(NAME(PROD.SORTLIB) REL(SYS1.SORTLIB))’. These entries
can be found in advance with a LISTC ALIAS command directed to all
your user catalogs.

From what we could test, the problem does not exist with VSAM files
(PATH entries related to primary clusters are preserved when the
clusters are moved).

11 The hidden candidate – premature reinitializing of a candidate volume.

You were happy to have emptied many volumes containing VSAM files,
and eventually you re-initialized them (ICKDSF INIT). Now, some
people are reporting errors when deleting VSAM files, or when the
system tries to expand a VSAM file onto another volume. This was
because the volumes you had reinitialized were candidate volumes for
these files (though no space was allocated on them). An ALTER xxx
REMOVEVOLUMES(volser) for any concerned file will fix the problem.

The same problem exists for non-VSAM files with more annoying
consequences: as soon as people try to handle or delete these not really
multi-volume files, they get the message:

IEF238D - REPLY DEVICE NAME OR 'CANCEL'.

because, as the system is unable to know whether or not the candidate

volume was used for these files, it tries to inspect the newly
disappeared volume.

You can be proactive by listing all the catalog entries and searching for
occurrences of these volumes that you want to reinitialize, as current
candidates for VSAM or non-VSAM files.

Conclusions

To conclude, disk migration is often a tedious task. Try to assess all the
differing problems which may occur. Prepare all the JCL before the

16 © 1999. UK telephone 01635 33848, fax 01635 38345. USA telephone 940 455 7050, fax 940 455 2492.
 A DASD migration guide

migration day, and test it carefully. There will certainly be additional

problems you had not foreseen.

This chapter was contributed by Thierry Fallissard of etic (France).

© 1999. Reproduction prohibited. Please inform Xephon of any infringement. 17