Conversion Procedures › Migrating to Dynamic Cache Management › Phased Migration › Perform a Phased Migration

Perform a Phased Migration

Phased Migration assumes that too many CA Vtape Subsystems are involved or that there is insufficient DASD space available to create a dynamic cache DASD pool the same size as the static cache DASD pool.

To perform Phased Migration

1. If you have more than one CA Vtape Complex, pick one complex to start with.
2. Evaluate the subsystems running in this complex to determine how much of the static cache DASD pool will need to be converted to dynamic cache to support the normal daily operations of each subsystem.

   For example, assume 600 GBs of data are written to Virtual Volumes per day in a complex with three subsystems. The first subsystem services 100 GBs, the second subsystem services 200 GBs, and the third subsystem services 300 GBs. 100 GBs/600 GBs (or one sixth of the static cache LDSs) will need to be converted to dynamic cache to support the first subsystem.

3. Execute the GRRJCL batch utility to ensure that all Unexternalized Virtual Volumes are queued for Externalization. Then, use SVTn Display Group and SVTn SET BACKstore console commands to ensure that any queued Virtual Volumes are Externalized.

   Note: If any Virtual Volumes created in static mode cannot be Externalized, take the necessary actions to copy any needed application data sets to DASD or physical tape and scratch the Virtual Volumes.

   Execute the SVTSUTIL batch utility with the following command:

   LDS_DELETE,RTP=nnn%
   

   This will delete the specified percentage of the total static cache LDSs from DASD and from the CA Vtape Global VCAT.

   Note: Make sure nnn% is set to a percentage appropriate for the subsystem you are converting. From the preceding example, if you are converting cache for the first subsystem, nnn% would be set to 16% or one sixth of the total static cache LDSs. The utility will stop automatically when the number of static cache LDSs corresponding to 16% of the total static cache LDSs have been deleted. For the second subsystem in the preceding example, 200 GBs or the remaining 500 GBs of the static cache should be converted, or 40%.

   If the static cache DASD volumes are in a DFSMS storage group and the same storage group will be used for the dynamic cache, then the space released is immediately available.

   If the DFSMS storage groups are different or the static cache DASD volumes are not managed by DFSMS, then the volumes must be emptied so they can be converted with ISMF to the appropriate DFSMS storage group. In this case it may be more advantageous to execute the SVTSUTIL batch utility with the following command:

   LDS_DELETE,RTP=100%,VOL=(volser1,volser2,…volsern)
   

   This allows you to concentrate on emptying specific DASD volumes for conversion to DFSMS while releasing the appropriate percentage of the total static cache. Using the preceding example, if the static cache is composed of 2000 LDSs and 16% of these LDSs need to be cleared, DASD volumes with a total of 320 cache LDSs defined on them will need to be emptied.

   Note: For more information about the command and its parameters, see the chapter “SVTSUTIL Batch Commands.”

   You can execute the utility as often as necessary to clear the appropriate space.

4. If multiple subsystems are active in the complex and they share the same Startup Options Section, use symbolic substitution to create unique Startup Options Sections for each subsystem.

   Note: For examples on how to do this, see the section Parmlib Syntax in the Configuration Guide.

5. In the Startup Options Section for the subsystem being converted, change the cache management mode to dynamic by setting CacheManagement=DYNAMIC.
6. Stop and start the subsystem.
7. You can use the SVTn Display Parmlib,Short console command to check if the subsystem is running in dynamic mode.
8. Execute jobs to test the allocation of new Virtual Volumes by this subsystem. All Virtual Volumes should be written into dynamic LDSs with a data set name pattern of prefix.VVE.Vvolser.MM.CACHE.

   Note: Recalls of old Virtual Volumes that were written in static cache mode will be recalled to the static cache. Recalls of new Virtual volumes written in dynamic cache mode will be recalled to the dynamic cache.

9. Repeat Steps 3 through 9 for the next subsystem to be converted in this complex.

   When you repeat the steps is up to you. You can convert one subsystem and run it in Dynamic Cache Mode for an hour, a day, or a week before moving on to the next subsystem in the complex. Your only consideration is that what was a single large DASD pool, available to support the peak workload of all subsystems in a complex, is now two smaller DASD pools that may not be able to support the peak workload of all subsystems and keep the same number of Virtual Volumes in cache. As a result, you may see an increase in recall activity.

   Note: When less than ten static cache LDSs remain, any subsystems still running in static mode will automatically Recall Externalized static Virtual Volumes into the dynamic cache.

10. After all the subsystems in the complex are running in dynamic mode, you can convert all Virtual Volumes to dynamic mode by executing the SVTSUTIL batch utility with the following command:

    RESET_CACHETYPE=DYNAMIC
    

    Each static Virtual Volume Entry in the Global VCAT will be converted to dynamic. It takes approximately 18 minutes to convert 20,000 active Virtual Volumes when the subsystems are under a light workload. Executing the utility when the subsystems are under a heavy workload will cause delays due to competition for the Global VCAT and BSDS.

    An error report will be produced for any Virtual Volumes that cannot be converted. These are typically Virtual Volumes that were not Externalized or were active or mounted when the utility was executed.

    You can execute the utility as many times as is necessary to complete the conversion.