//SYSIN

DD *

 

COPY

STORGRP(SG1)

-

 

DS(INC(**)

-

 

EXCLUDE(SYS1.VTOCIX.*,SYS1.VVDS.*))

-

 

DELETE CATALOG SELECTMULTI(ANY) SPHERE-

 

 

ALLDATA(*) ALLX WAIT(00,00) ADMIN OPT(3) CANCELERROR

/*

 

 

//* -------------------------------------------------------------

***

//AGAIN

EXEC PGM=IEBGENER

 

//SYSPRINT

DD DUMMY

 

//SYSUT1

DD DSN=WB.MIGRATE.CNTL(DSS#SG1),DISP=SHR

 

//SYSUT2

DD SYSOUT=(A,INTRDR)

 

//SYSIN

DD DUMMY

 

//* -------------------------

JOB END ----------------------------

***

//

 

 

 

 

 

You might keep the job repeatedly executing through the second step AGAIN, where the same job is read into the system again through the internal MVS reader.

Eventually there remain a few data sets on the source volumes which are always open. These data sets require you to stop the concerned application, close and unallocate these data sets, and then run the job in Figure 13-12once more.

Verify at the end of this logical data set migration that all data has been removed from the source disk server with the IEHLIST utility’s LISTVTOC command.

Again this approach requires you to have the old and new equipment connected at the same time and most likely over an extended period, except if you push the migration through jobs like in Example 13-12,in which you can run more than one instance concurrently.

13.3.3 Summary of logical data migration based on software utilities

Problems encountered when not using an allocation manager like system-managed storage are less flexibility when using esoteric unit names, or complex and time-consuming tasks in maintaining hard-coded JCL volume names, which need to be changed when creating new volumes on new disk storage servers. It is recommended that you use system-managed volumes to overcome the limitations with esoteric unit names and hard-coded volume names in JCL.

Logical data migration is difficult and can be time-consuming, and it usually requires system down time. System-managed storage allows for a less difficult data migration, when it is on a logical level, in order to consolidate not just disk storage servers but also volumes moving to larger target volumes.

13.4 Combine physical and logical data migration

The following approach combines physical and logical data migration:

￿Physical full volume copy to larger capacity volume when both volumes have the same device geometry (same track size and same number of tracks per cylinder).

￿Use COPYVOLID to keep the original volume label and to not confuse catalog management. You can still locate the data on the target volume through standard catalog search.

￿Adjust the VTOC of the target volume to make the larger volume size visible to the system with the ICKDSF REFORMAT command to refresh, REFVTOC, or expand the VTOC,

270DS6000 Series: Concepts and Architecture

Page 294
Image 294
IBM DS6000 Series manual Combine physical and logical data migration, Storgrp SG1