Converting to System Managed Storage: Part II By Steve Pryor Steve Pryor is a senior technical developer at Innovation Data Processing Little Falls, N.J. He has more than 10 years experience in DASD storage management, disaster recovery and software development. The first article in this series focused on the requirements for a system managed storage (SMS) environment. Once these requirements have been met, the storage administrator can begin placing data under system control. This month's second and final installment describes two approaches for converting to system management: conversion by data movement and conversion in place. Conversion by Data Movement Conversion by data movement is generally the preferred method since it allows the system to do what it's supposed to do under SMS: control the placement of data sets on disk volumes. Conversion by data movement means using the data mover programs in the DFSMS environment (e.g., FDRDSF or FDRCOPY from Innovation Data Processing or DFDSS from IBM) to move data sets from non- managed volumes to managed ones. Figure 1 depicts data set conversion to SMS management by data movement. Data sets can be moved to SMS control in two ways: by backing them up and then restoring them to managed volumes, or by moving them directly from unmanaged to managed volumes without an intermediate backup. In either case, when the data mover is executed, the ACS routines are called to determine which management class and storage class should be assigned to the data set. If the ACS routines cannot assign a storage class or the data set is not eligible for SMS management for some other reason (e.g., absolute-track-allocated data sets cannot be SMS-managed), then the restore or copy fails and the data set remains unmanaged; otherwise, it is allocated on the target volume as SMS-managed. To convert data sets to SMS control by moving them, the target DASD volume of the conversion must already be in SMS physical status, and of course, there must be sufficient space on the volume to accommodate the data sets to be moved. A good way to ensure that both conditions are met is to move the data sets to a DASD volume that has just been initialized. To do so, program ICKDSF with the INIT, STGR and INDEX operands that can be used to initialize DASD volumes and place them in SMS status. Advantages of Conversion by Data Movement There are four major advantages to converting via data movement: o By moving data sets to newly initialized volumes, there is likely to be sufficient space on the receiving volumes to hold the data sets being moved; o initializing with ICKDSF ensures that the VTOC, the VTOC index and the VVDS are located adjacent to one another; o it is useful in allowing an entire application that may consist of a number of data sets spread across several unmanaged volumes to be converted at one time; and o most importantly, it allows the storage management system to choose the output volume and thus make certain that an appropriate volume is used. This means, for example, that data sets which are assigned a storage class that has the AVAILABILITY=CONTINUOUS attribute are allocated only to dual-copy devices. Disadvantages of Conversion by Data Movement Allowing the storage management subsystem to move the data sets, of course, means that data sets cannot normally be directed to reside on a particular volume nor can particular storage or management classes be forced upon a data set. This is where the selection of data mover software comes into play. The FDR system, for example, includes key words (BYPASSACS and BYPASSSMS) which provide these capabilities for users with sufficient authority. Converting data sets to managed status by transferring them from unmanaged to managed volumes may require the movement of large amounts of data. The independent DASD management components of DFSMS therefore provide an alternate means of placing data under system management, conversion in place. Conversion in Place The luxury of newly initialized DASD volumes may not always be available. Certainly data can be converted to SMS management by moving data to already-managed volumes that have not just been initialized. However, if all of the data to be converted resides on a single volume, it may be useful to convert data sets in place, without data movement. Figure 2 depicts conversion of a volume in place. A DASD volume to be converted in place must meet the same criteria as a volume to which data is being transferred; that is, it must have an indexed VTOC, a VVDS and must be assigned to an SMS storage group. The independent DASD management components of DFSMS provide programs to convert volumes in place. Among the programs that can be used are FDRCONVT from Innovation or DFDSS from IBM. Both products provide the same function, though FDRCONVT has some additional capabilities not available with DFDSS, such as the ability to process only selected data sets, or the ability to assign particular SMS constructs to data sets. Both programs operate by default on all of the data sets on a DASD volume and thus are both quite powerful. Consequently, their use should be restricted to those who have the proper security FACILITY class authority. A VVDS Is Required Before converting volumes that contain only non-VSAM data sets to SMS management, a VVDS should be defined on these volumes. Conversion in place does not create any new data sets on the volume and therefore does not implicitly define a VVDS. Since SMS-managed volumes require VVDS entries for non-VSAM as well as VSAM data sets, the conversion will fail unless a VVDS already exists on the volume. Also, if a VVDS already exists prior to conversion in place, be sure that it has sufficient primary and secondary space to hold all of the new entries that will be required. For a VVDS on an SMS managed volume, 300-600 bytes are required for each VSAM data set, and up to 139 bytes for each non-VSAM data set. The Conversion Process Both Innovation's FDRCONVT and IBM's DFDSS work in a similar manner to convert volumes to SMS management. First, the physical status of the volume is changed to INITIAL to prevent new data set allocations during the conversion process, and to eliminate the necessity for the program to ENQ the VTOC for the entire duration of the conversion. If the volume is not assigned to an SMS storage group, conversion stops with the volume in INITIAL status. Each data set is converted individually to SMS management by calling the ACS routines to get the management class and storage class names for the data set and then placing the SMS class information in the VVDS and basic catalog structure (BCS). The data set's format-1 DSCB is then updated to indicate that it is SMS managed. If any data set on the volume fails conversion, the entire volume remains in INITIAL status. Ineligible data sets must then either be moved off the volume or made eligible for SMS management (e.g., by cataloging them) before running the program again to convert the remaining data sets. Thus, it makes sense to run the conversion in simulation mode first to identify data sets that cannot be converted. The final step in the conversion process is for the program to place the volume in SMS status. Once this is completed, the volume is under control of the storage management system. Advantages of Conversion in Place Because conversion in place does not involve any movement of data, it can be faster than transferring data to managed volumes. This is particularly true if only a few large data sets are on the volume to be converted. Disadvantages of Conversion in Place On the other hand, this method does not allow the system to place the data sets for you, which could result in data sets residing on inappropriate volumes. For instance, a data set that is assigned a storage class with the AVAILABILITY=CONTINUOUS attribute will be converted even if the volume is not a dual-copy device. Also, the system cannot evenly distribute data sets across the volumes in the storage group as it does when data sets are newly allocated. Further, volumes that are converted in place may contain so much data that they exceed the high ALLOCATION/MIGRATION threshold value specified in the storage group definition for the volume. The DASD management components of DFSMS may then try to archive data sets from the volume in an attempt to meet the threshold. This scenario is less likely if data sets are moved to new volumes than if the volumes are converted in place. There are programs that can help minimize these drawbacks, however. FDRCONVT, for example, has enhanced capabilities that provide additional flexibility in conversion. For example, data sets that are ENQueued at the time of conversion are normally considered ineligible for conversion. For "always-open" data sets such as linklist libraries, this makes conversion of the volumes on which these data sets reside almost impossible. FDRCONVT can optionally be directed to ignore ENQueues and convert the data sets anyway. In addition, FDRCONVT uniquely enables the specification of SMS classes for input to the ACS routines and can force specified classes to be assigned via a "BYPASSACS" keyword. The program also allows particular data sets to be excluded from a convert operation. This select/exclude capability is useful when only certain data sets are to be converted, or when specific data sets are never to be converted. Converting Data Out of SMS Management It may sometimes be necessary to remove data sets or volumes from system management. As with conversion into managed status, this can be done either by data movement or by conversion in place. Data sets can be converted out of managed status by moving them to unmanaged volumes in the same manner as they were originally moved to the volumes (i.e., with the data mover programs such as FDRDSF or DFDSS). In this case, however, the NULLSTORCLAS operand should be specified to ensure that the data set is not assigned an SMS storage class. Since data sets without a storage class are ineligible for system management, the data set is moved to an uncontrolled volume. This procedure can be followed for a single data set, or for all of the data sets on a volume at one time. Alternatively, a volume can be converted from system management in place. The deconversion process is the reverse of conversion: the volume is first placed in INITIAL status, then all of the data sets on the volume are converted out of managed status, after which the volume is placed in NONSMS physical status. It should then be removed from the SMS storage group. If a volume is to be deconverted without data movement, all of the data sets must be eligible for conversion out of SMS management. A PDSE, for example, cannot be converted out of managed status, since PDSEs must reside on system managed volumes. Summary Generally speaking, the best way to convert data to system management is by moving data sets to already managed volumes. This allows the system to determine which volumes are appropriate targets. When conversion by data movement is not appropriate, there are programs available that allow conversion in place. Whatever the situation, an SMS conversion is not a trivial task. But through a combination of thorough preparation, step-by-step implementation and the use of proper conversion tools and techniques, it can be successfully accomplished -- positioning t he data center for the future. /* Was this article of value to you? If so, please let us know by circling Reader Service No. 00. FIGURE 1: Steps for Converting a Volume by Data Movement 1) Assign the target volumes of the conversion to an SMS storage group using ISMF. 2) Initialize the volumes to include an indexed VTOC and place them in SMS status with ICKDSF, using the INIT, INDEX and STGR operands. 3) Optionally, define a VVDS of sufficient size on the volume. Although size of the default VVDS automatically defined when the first data set (VSAM or non-VSAM) is allocated on a volume has increased with SMS from three tracks each of primary and secondary space to 10 tracks, it may be worthwhile to explicitly define the VVDS with an even larger allocation, especially if the volume will contain a large number of data sets. 4) Optionally, back up the data sets to be moved. 5) Use the data movement programs such as FDRCOPY, FDRDSF or DFDSS to move or restore the data sets onto the target volumes. FIGURE 2: Steps for Converting a Volume in Place 1) Place an indexed VTOC on the volume via ICKDSF, using the INDEX parameter. 2) Define a VVDS on the volume if none exists or if the one that does exist is too small. 3) Optionally, place the volume in INITIAL status to prevent new allocations to the volume. This may be useful if conversion is not to be performed at once and may take place over a period of time. 4) Simulate conversion of the volume to identify data sets that are not eligible for conversion to SMS management. Move these data sets off the volume or make them eligible. 5) Assign the volume to an SMS storage group using ISMF. 6) Convert the volume to SMS management. 7) If any data sets were unable to be converted, move them off the volume or make them eligible for conversion and repeat step 6.