IBM DS6000 Series ユーザーズマニュアル

DS6000 Series: Concepts and Architecture

//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-12 once 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.

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.

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,