SMS Questions and Answers
The objective of this section is to answer some of the most common questions asked about the FDR products in an SMS system.
How do I restore SMS-managed volumes at a disaster recovery site?
At a disaster recovery site, you may need to restore SMS-managed volumes on a starter system that does not have SMS active, or which does not include your volumes in its SMS configuration. In this case, you can tell FDR or FDRABR to restore SMS-managed volumes to non-SMS output volumes by adding the SMSPROT=NONE keyword to the RESTORE statement; this tells FDR not to make its usual checks when restoring SMS-managed volumes.
Of course, the volumes are restored with all of their SMS indicators intact, assuming that you eventually IPL a system with your normal SMS configuration. At that time, the restored volumes are usable. Until the IPL is done, the data on the volumes can be accessed, but no data sets can be allocated or scratched.
How do I convert a volume to be SMS-managed?
We recommend you to convert data sets to SMS management by moving them to SMS-managed volumes using FDRCOPY or FDRDSF DUMP/RESTORE, rather than converting the volumes in-place, whenever possible. Moving the data sets allow SMS to position them on the proper SMS-managed volumes according to the SMS classes assigned; data sets not eligible for SMS are left on their original volumes and can be handled separately.
Program FDRCONVT, documented in FDRCONVT-Overview, can be used to convert a volume to SMS-managed (and back) in place, without data movement, as long as all data sets currently on the volume are eligible for the conversion.
The CONVERTV function of IBM’s DFSMSdss products can also be used to do such an in-place conversion. However, CONVERTV cannot be used on a volume that has been initialized for ABR. CONVERTV improperly modifies the ABR Model DSCB (FDRABR.Vvolser). FDRCONVT must be used on an ABR volume. If you have used DFSMSdss to convert an ABR volume, you need to use the FDRABRM utility’s REMODEL function to correct the ABR Model DSCB (see FDRABRM-REMODEL-Statement).
Can I use a full-volume RESTORE/COPY to convert an SMS-managed volume to a non-SMS volume?
No, a full-volume restore or copy (via FDR, ABR, or CPK) always restores all of the SMS indicators in the VTOC and VVDS, so it cannot be used to convert a volume. Normally a full-volume operation requires that an SMS-managed volume be restored/copied to a volume currently defined to SMS (and a non-SMS volume only to non-SMS volume).
How does SAR handle SMS-managed volumes?
Stand Alone Restore (SAR) is totally unaware of the SMS-managed or non SMS-managed status of volumes. Since SAR is normally a full-volume dump and restore, it dumps and restores all SMS indicators on the volume; SAR restores the volume in its original state (SMS-managed or not). When the operating system is reIPL’d, SMS-managed volumes are recognized by SMS if they are currently defined in an SMS storage group. Unlike FDR, SAR does not check the SMS status of the output volume so it restores to an SMS-managed or non-SMS volume.
Are there considerations for archiving from SMS-managed volumes?
The use of the ABR option MIGRAT=YES is a necessity when Archiving data sets for Auto-Recall from SMS-managed volumes. MIGRAT=YES places a volume serial number of MIGRAT in the catalog entries of Archived data sets instead of the data set's original volume serial number. Since SMS-managed data sets normally have an NVR in the VVDS of their original volume, many z/OS functions that operate on the catalog entries of Archived data sets (such as LISTCAT and GDG processing) get errors if they try to process an Archived data set and discover that the NVR is missing. However, those functions recognize the volume serial number of MIGRAT to mean that the data set is Archived and do not try to access the NVR.
MIGRAT=YES can be specified on the DUMP TYPE=ARC statement of appropriate ABR jobs. However, MIGRAT=YES can also be set as a permanent option in the ABR option table (ABR ISPF panel A.I.4.4) so that it is automatically used for all Archive Backup jobs. You may want to use MIGRAT=YES for all Archiving, SMS-managed or not.
MIGRAT=YES can and should be used even if DFSMShsm is installed on your system, but do not use it if you do not have the ABR LOCATE exit (used for auto-recall) activated on your system.
How do I move an SMS-managed volume with FDR?
Occasionally you may want to move an entire SMS-managed volume to a new DASD, for performance balancing or because of problems with an HDA. This can easily be done with FDR full-volume copy, or full-volume dump and restore, but there are a few considerations for SMS.
First, you may want to be sure that the volume is not in use when you dump or copy it. For a non-SMS volume, IBM has never provided any good mechanism to do so, but on SMS-managed volumes you can change the volume to disabled status that does not allow any new jobs to allocate it. This is done by the following console command:
V SMS,VOL(volser),DISABLE
This does not affect any job steps currently using the volume (unless they try to scratch data sets) but fails any new job steps trying to access data sets on the volume. Unfortunately, DISABLE status also prevents FDR from accessing the volume to dump or copy, so you need to change the status back to ENABLE just before the FDR step starts and back to DISABLE as soon as the dump/copy begins.
If more than one CPU or LPAR shares the SMS-managed volume, vary the device offline to every system except the one on which the move is to be done.
Now, you can either do a full-volume COPY or a full-volume DUMP and RESTORE to move the volume. In either case, the output volume may be either an SMS-managed volume (with a different volume serial number) or a non-SMS volume. It must, of course, be the same device type with an equal or larger capacity. If it is a larger capacity, you must rebuild the indexed VTOC with ICKDSF BUILDIX.
An example of a full-volume COPY job is:
//SYSPRINT DD SYSOUT=*
//SYSPRIN1 DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//DISK1 DD UNIT=SYSALLDA,VOL=SER=vvvvv1,DISP=OLD <=INPUT VOL
//TAPE1 DD UNIT=SYSALLDA,VOL=SER=vvvvv2,DISP=OLD <=OUTPUT VOL
//TAPE11 DD DSN=backup.vvvvv1,DISP=(,CATLG),
// UNIT=TAPE,VOL=(,,,99)
//SYSIN DD *
COPY TYPE=FDR,CPYVOLID=YES,DSNENQ=HAVE
/*
If the output volume is currently a non-SMS volume, add “,SMSPROT=NONE” to the COPY statement. After the COPY, the output volume is renamed to the input volume serial number and placed offline. At this point you can issue console commands to vary the input volume offline and the output volume online and the volume is usable by SMS (if you DISABLEd the volume to SMS you must now ENABLE it).
M cuu,VOL=(SL,vvvvv1) <=== output volume address
An example of a DUMP and RESTORE is:
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//DISK1 DD UNIT=SYSALLDA,VOL=SER=vvvvv1,DISP=OLD <=INPUT VOL
//TAPE1 DD DSN=backup.vvvvv1,DISP=(,CATLG),
// UNIT=TAPE,VOL=(,,,99)
//SYSIN DD *
DUMP TYPE=FDR,DSNENQ=HAVE
/*
At this point vary the input DASD volume offline.
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//DISK1 DD UNIT=SYSALLDA,VOL=SER=vvvvv2,DISP=OLD <=OUTPUT VOL
//TAPE1 DD DSN=backup.vvvvv1,DISP=OLD
//SYSIN DD *
RESTORE TYPE=FDR,CPYVOLID=YES
/*
If the output volume is currently not SMS-managed, add “,SMSPROT=NONE” to the RESTORE statement. After the RESTORE, the output volume is renamed to the input volume serial number and SMS is notified of the change (if the volume is disabled to SMS it must now be enabled).
How do I Implement SMS management classes in ABR?
ABR supports selection and management of data sets based on SMS management class attributes. SMS-ABR-Support gives much detail on the operation of ABR when management classes are used, but it is a complicated topic. The discussion below attempts to simplify it.
Actually, implementation of management classes in ABR is not difficult. There is a keyword, SMSMANAGE=YES that can be placed on any ABR DUMP statement; it tells ABR to use SMS management classes whenever an SMS-managed volume is being processed, but it is ignored for non-SMS volumes. If you have existing ABR job streams that process SMS-managed volumes, you may be able to implement management class selection with minimal modifications.
The description of ABR’s processing of management classes in “ABR Management Class Usage” in FDRCONVT-Examples is detailed, but in simple terms. SMSMANAGE=YES turns on ABR support for all of the attributes of management classes that relate to actual selection of data sets from DASD for Volume Backups, Superscratch, and Archive Backups (such as “PRIMARY DAYS NON-USAGE” and “ROLLED OFF GDG ACTION”); they are used by ABR just as they are described in ISMF and in the IBM storage administration manuals.
For ABR Volume backups, SMS management class support can be used ONLY to exclude certain data sets from backup; ABR does not use the attributes that relate to the retention of backups.
In Superscratch and Archive Backup, the management class attributes that relate to expiration and migration of data sets are supported.
Superscratch (DUMP TYPE=SCR) supports the attributes that relate to “expiration” of data sets. Data sets that are considered expired under the management class rules are scratched from SMS-managed volumes by a Superscratch step that specifies SMSMANAGE=YES (expired data sets that actually have an expiration date in their Format 1 DSCB in the VTOC are scratched from SMS-managed volumes ONLY if the “EXPIRED” keyword is also specified on the DUMP TYPE=SCR statement).
Archive Backup (DUMP TYPE=ARC) supports the attributes that relate to selection of data sets for “migration” (such as “PRIMARY DAYS NON USAGE”).
In an Archive Backup step, you may optionally add the operand SMSEXPIRE=YES or ALL, which enables ABR support to set the COPY1 and COPY2 expiration dates in the Archive Control File separately for every data set selected for Archive Backup by SMSMANAGE=YES processing, based on the management class attributes “LEVEL 1 DAYS NON-USAGE”, “EXPIRE AFTER DAYS NON-USAGE” and “EXPIRE AFTER DAYS/DATE”. ABR then considers the COPY1 (Level 1) and COPY2 (Level 2) backups to be expired according to their individual management classes.
So, if you have existing ABR Archive Backup jobs that process SMS-managed volumes, you can add management class support simply by adding SMSMANAGE=YES (and optionally SMSEXPIRE=YES or ALL) to the DUMP statement; ABR does management class testing on SMS-managed volumes and uses normal ABR Archive keywords for selection on non-SMS volumes. If you are not already running Superscratch on your SMS-managed volumes, you need to add a new ABR step preceding the Archive Backup step, with DUMP TYPE=SCR,SMSMANAGE=YES to scratch expired data sets (the volumes must also be enabled for Superscratch in the ABR Model DSCB).
You may want to separate the processing of SMS-managed volumes from non-SMS volumes. The MOUNT STORGRP= statement can be used to select SMS-managed volumes by storage group name (SMSMANAGE=YES is still required on the DUMP statement). When processing SMS-managed volumes you may also wish to limit processing only to data sets with certain management class names; you can do this by specifying the MGMTCLAS= operand on the DUMP statement.
What do I need to do to my ACS routines for FDR?
When coding your SMS Automatic Class Selection (ACS) routines you may need to consider a few things relating to FDR; these considerations also apply to IBM’s DFSMSdss and DFSMShsm.
During the initial allocation of a data set, several ACS routine variables can be tested, including the job name, program name, user ID, IBM RACF group and execution mode (BATCH, TSO, or TASK). Your ACS routines may be coded to base class assignments on these variables as well as on other variables such as the data set name, type of data set, and its size.
However, during a restore of a data set that first set of variables is NOT be; they are nulls (this is by IBM’s rules, not ours). The reason is obviously that during a restore the value of those variables would reflect the job or task doing the restore and not the original owner of the data set, so they would be meaningless during a restore. If the ACS routines test any of those variables (see ACS Routine Variables” in SMS-ACS-Routines for a complete list), they should bypass those tests if the &ACSENVIR variable is “RECALL” (for restore from archive) or “RECOVER” (for any other restore).
It is also important to know that during an FDR data set restore, the original SMS classes of the data set being restored (if it was SMS-managed) are passed as the initial values of the &STORCLAS, &MGMTCLAS, and &DATACLAS variables (you can override those initial values using operands on the SELECT statement for other than an auto-recall restore). For a restore, you may wish to code the ACS routine to accept the initial values in most cases.
For FDRCOPY, the &ACSENVIR variable is be to “ALLOC” and the other ACS variables are set as if this was a normal allocation. However, you may still need to code special rules if the &PGM is “FDRCOPY” since the variables reflect the FDRCOPY step, not the original user.
The Data Class ACS routine is never invoked for a restore or copy/move.
The ACS routines can change the storage or management classes assigned to a data set during a restore. Some customers want to preserve the original classes during an ABR auto-recall (from Archive). You can do so by adding code similar to this near the beginning of each ACS routine (this example is for the storage class):
EXIT COND(0)
END
How can I control the SMS classes and volumes used?
Sometimes you want to restore, copy or move data sets, but you do not want SMS to override the classes of the original data sets, or you want to specify the output volumes to be used. In this case, you can use the operands BYPASSACS and/or BYPASSSMS on the RESTORE or COPY/MOVE statements.
BYPASSACS does not invoke the ACS class routines at all. You can specify the classes assigned to the data set on the SELECT statement (for example, MGMTCLAS=) otherwise the original classes of an SMS-managed data set are used. The output data set must have a storage class assigned (either the original class or specified by STORCLAS=) to be SMS-managed; conversely, if NULLSTORCLAS is specified the data set is allocated unconditionally as non SMS-managed.
BYPASSSMS bypasses SMS storage group ACS routine and volume selection, and allocates SMS-managed data sets directly on the output volumes you specify with DISKx DD statements or NVOL= parameters (the volumes MUST be SMS-managed if the data set has a storage class).
Since these options circumvent normal SMS controls, the use of these operands is restricted by a FACILITY class profile in IBM RACF or equivalent security products. You must be authorized to the resource name.
STDADMIN.ADR.COPY.BYPASSACS -- for copy/move
Restrict these names to authorized storage administrators.
How do you DELETE an improperly cataloged SMS-managed data set?
By IBM’s rules, SMS-managed data sets must always be cataloged, and non-VSAM, SMS-managed data sets must have an non-VSAM record (NVR) in the VVDS. Occasionally an interrupted data set creation or other errors may leave an SMS-managed data set only partially created, where the catalog entry, NVR or VVR, and/or DSCB is missing. Such data sets require manual intervention to clean them up since a normal deletion fails.
To delete the catalog entry for an incomplete data set, issue the IDCAMS command:
DELETE name NOSCRATCH
The ability to do DELETE NOSCRATCH under SMS may be protected by a security system profile, so it may need to be done by an authorized user.
To delete the NVR and DSCB for a uncataloged SMS-managed data set, issue the IDCAMS command:
DELETE name NVR FILE(DD1)
Where DD1 is a DD statement pointing to the volume involved. DELETE NVR fails if the data set is actually cataloged. DELETE NVR still works if only the NVR or only the DSCB exist for the data set.
To delete the VVR and DSCB for uncataloged VSAM components (SMS or not), for EACH component on the volume issue the IDCAMS command:
DELETE name VVR FILE(DD1)
How can I prepare for SMS conversion with FDREPORT?
FDREPORT can be used to identify data sets that are not supported by SMS such as unmovable and uncataloged data sets. The following example shows how to identify these data sets to ease the conversion to SMS; the report also shows the catalog status of each data set and the volume where it is cataloged.
XSELECT DSORG=(U),VOLG=TSO UNMOVABLE DATA SETS
XSELECT CATALOG=ERR,VOLG=TSO CATALOGED TO ANOTHER VOL
XSELECT CATALOG=NO,VOLG=TSO UNCATALOGED
REPORT FIELD=(DEFAULTS,CATALOG,CATVOL)
Can FDREPORT help me manage my SMS-managed data sets?
FDREPORT can report and summarize based on SMS classes and select based on SMS storage groups so a variety of reports can be generated on SMS-managed data sets and volumes. The example below selects all SMS-managed data sets (data sets that have an SMS storage class assigned) and sorts by storage class name, reporting all data sets that are assigned to each unique storage class, and summarizing based on storage class giving the total occurrences of each class and the total number of tracks of the data sets with that class. You could also report on management class or data class names by changing the field name in the SORT and SUMMARY statements to MGMTCLAS or DATACLAS.
XSELECT STORCLAS.NE.' ' *See "Note"
SORT FIELD=(STORCLAS,DSN),BREAK=(Y,N) SUM ON CLASS NAME
SUMMARY FIELD=(STORCLAS,SIZE)
REPORT FIELD=(DEFAULTS,SMSCLASS)
PRINT ONLINE,INFOMSG=NO
Can I use ABR to implement SMS tape mount management?
IBM has a feature for SMS called Tape Mount Management (TMM). Its function is to divert small data sets that are currently being written to tape (leaving much wasted tape) to SMS-managed DASD volumes. IBM recommends that one or more SMS-managed DASD volumes be dedicated to this purpose (known as “DASD Buffer” volumes) in a storage group by themselves. Process this storage group by the DASD management system at frequent intervals so that all or most of the data sets that reside there can be migrated directly to tape, resulting in efficient tape utilization since many such data sets occupy one tape.
Tape Mount Management can be implemented with FDRABR. IBM implemented a new attribute in the SMS storage group definition that tells DFSMShsm to process the DASD Buffer volumes every hour regardless of other DFSMShsm options. Since ABR processing is done by batch ABR jobs scheduled by the user, this attribute is not required.
To implement TMM with ABR:
- Define a DASD Buffer storage group to SMS. You probably want to define it with a large high threshold (such as 90 percent) and a moderate low threshold (such as 50 percent).
- You may need to define several data and management classes to identify and process these data sets. The management classes should specify “PRIMARY DAYS NON USAGE” values of 0 (to allow immediate archiving) or small values (for data sets that may need to be read back within a day or two).
- Your ACS routines must be modified to recognize tape data sets that are appropriate for TMM and direct them to the TMM classes and storage group. IBM provides a program called “DFP VOLUME MOUNT ANALYZER” that can assist in identifying such data sets.
- A separate ABR job must be coded and scheduled to run against that DASD Buffer storage group at frequent intervals to archive directly to tape (TAPE1 points to a real tape drive). You may want to specify the THRESHOLD=LOW operand in this job so that data sets are archived from the DASD only if the DASD is becoming full.