STORAGE MANAGEMENT

This document provides information about storage management policies at DHHS and ITS. It is intended to be a basic guide to storage management for clients who manage their own data using the IBM Storage Management Subsystem (SMS) software product. Following the recommendations in this guide can enable SMS to provide time and cost saving advantages including:

· Automatic determination of many dataset allocation parameters

· Automatic selection of appropriate storage devices

· Automatic management of dataset retention and backup

· Reduction in DASD space used by datasets

Most of the dataset allocation parameters selected by SMS are based on the name assigned to the dataset when it is created. This guide therefore details the DHHS and ITS Standard Dataset Naming Conventions.

Examples of methods for creating datasets are included for both batch jobs and interactively from ISPF.

A complete SMS guide is beyond the scope of this document. This guide addresses how datasets are named, allocated, and managed at ITS using System Managed Storage (SMS), and Hierarchical Storage Management (HSM). Complete IBM documentation of HSM and SMS is available at ITS from TSO using Book Manager from ISPF.

The Tape Management System - TMS Expiration Date (EXPDT) Parameter is explained in this document.

Stacking of tape datasets is explained in this document.

Questions regarding this document should be directed to the DIRM Technical Services Storage Management Support.

TERMS USED IN THIS DOCUMENT

ACS	Automatic Class Selection
ACTS	Automated Collection and Tracking System
ANSI	American National Standards Institute
BCDS	Backup Control Dataset
CICS	Customer Information Control System
CS	Computing Services, a division of ITS
DASD	Direct Access Storage Device
DB2	Database 2
DBA	Database Administrator
DFSMShsm	Data Facility Storage Management Subsystem Hierarchical Storage Manager
DHHS	Department of Health and Human Services
DS	Dataset
EIS	Eligibility Information System
ES	VSAM Entry Sequenced Dataset
EXPDT	Expiration Date
GDG	Generation Data Group
GDS	Generation Dataset
HLQ	High Level Qualifier
HSM	Hierarchical Storage Manager
IMS	Information Management System
ISPF	Interactive System Productivity Facility
ISPF/PDF	ISPF /Program Development Facility
ITS	Information Technology Services
JCL	Job Control Language
KS	VSAM Keyed Sequential Dataset
KSDS	Key Sequential Dataset
LLQ	Low Level Qualifier
LPAR	Logical Partition
LS	VSAM Linear Space Dataset
MCDS	Migration Control Dataset
ODS	Output Dataset
PDS	Partitioned Dataset
PDSE	Partitioned Dataset Extended
PO	Partitioned Organization
PS	Physical Sequential
PS-L	Physical Sequential up to 8GB (used primarily for IMS OSAM)
RETPD	Retention Period
RLS	Record Level Sharing
RR	VSAM Relative Record Dataset
SMS	System Managed Storage
TMS	Tape Management System
TSO	Time Sharing Option
VTL	Virtual Tape Library
VSAM	Virtual Storage Access Method
Xptr	Systemware Report system

DATA SETS

NAMING DATASETS

The dataset name is assigned to a particular set of information and distinguishes that set of information from others on the DASD or tape. Dataset names must conform to specific standards established at DHHS and ITS.

DATASET NAMING STANDARDS

DHHS dataset naming standards closely follow the ITS dataset naming standards. DHHS dataset naming standards are owned by the DIRM Application Development Section and supercede ITS dataset naming standards where there may be conflicts.

DHHS Dataset Naming Standards

The DHHS naming standards are located on the DIRM LAN Policy Drive, p:\sysdev\standard\jcl.doc.
There may be occasions where adherence to the dataset naming standards can not be followed. Strict adherence to Dataset name high level qualifier and 2^nd level qualifier must follow these standards.

DATA SET NAMES - Production

ITS SMS dataset allocation routines will automatically place all datasets that have either TEST* or DEVE* in the 3rd through last dataset name qualifier on Test LPAR volumes. Do not use either TEST* or DEVE* in the dataset name for production datasets.

1. Non VSAM files DHR.aaa.pppppp-s.ffffffff.mmmmmmmmm

DHR = Department identification for non-library data sets

aaa = Application code - Must be 3 characters

pppppp = Creating program name (aaannn - see program names. Input data

entry tapes will use the name of the program to which they are input.)

s = Sequence number

ffffffff = Copybook name (if it exists)

mmmmmmmm = Description of file/data (optional)

2. VSAM (non-DB2): DHR.aaa.V.pppppp-s.ffffffff.mmmmmmmmm

DHR = Department identification for non-library data sets

aaa = Application Code - Must be 3 characters

V = V = VSAM, Optional if required

pppppp = Creating program name (aaannn - see program names. Input data

entry tapes will use the name of the program to which they are input.)

s = Sequence number

ffffffff = Copybook name (if it exists)

mmmmmmmm = Description of file/data (optional)

nn = File number

g = Data set group - D = Main data

P = Primary index

1 = Secondary index 1

2 = Secondary index 2

etc.

bbb = Database acronym

ccc = DB database

PI primary index

S1 secondary index 1

S2 secondary index 2

etc.

3. DB2 VSAM files DHRDB01.DSNDBD.aaabbbcc.tttttttt.i0001.Axxx

DHRDB01 = Department identification for Production DB2 data sets using the
01 DB2 subsystem

DSNDBx = Cluster,=C, Data=D, Index=I

aaa = Application code - Must be 3 characters

bbb = Database acronym

cc = DB database

tttttttt = Table Space Name or Index Space Name

i0001 = I could also be a J - toggle

Axxx = Partition number, 1-255, 1 if not partitioned

Note, DIRM Technical Services DB2 Administrators define all DB2 Tables.

DATA SET NAMES - Test Environment

ITS SMS dataset allocation routines will automatically place all datasets that have either TEST* or DEVE* in the 3rd through last dataset name qualifier on Test LPAR volumes.

1. Non VSAM files: DHRT.aaa.pppppp-s.ffffffff.mmmmmmmmm

DHRT = Department identification for non-library data sets

aaa = Application code - Must be 3 characters

pppppp = Creating program name (aaannn - see program names. Input data

entry tapes will use the name of the program to which they are input.)

s = Sequence number

ffffffff = Copybook name (if it exists)

mmmmmmmm = Description of file/data (optional)

2. VSAM (non-DB2): DHRT.aaa.V.pppppp-s.ffffffff.mmmmmmmmm

DHRT = Department identification for non-library data sets

aaa = Application Code - Must be 3 characters

V = V = VSAM, Optional if required

pppppp = Creating program name (aaannn - see program names. Input data

entry tapes will use the name of the program to which they are input.)

s = Sequence number

ffffffff = Copybook name (if it exists)

mmmmmmmm = Description of file/data (optional)

t = 5 - 9 for 'Test' data base identification

nn = File number

g = Data set group - D = Main data

P = Primary index

1 = Secondary index 1

2 = Secondary index 2

etc.

bbb = Database acronym

cc = DB database

PI primary index

S1 secondary index 1

S2 secondary index 2

etc.

3. DB2 VSAM files DHRDBnn.DSNDBD.aaabbbcc.tttttttt.i0001.Axxx

DHRDBnn = Department identification for DB2 data sets, where nn = DB2
Test Subsystem, 51, 52, or 53

DSNDBx = Cluster=C, Data=D, Index=I

aaa = Application code - Must be 3 characters

bbb = Database acronym

cc = DB database

tttttttt = Table Space Name or Index Space Name

i0001 = I could also be a J - toggle

Axxx = Partition number, 1-255, 1 if not partitioned

Note, DIRM Technical Services DB2 Administrators define all DB2 Tables.

ITS Dataset Naming Standards

The following are dataset naming standards recommended by ITS and may or may not be implemented by agencies using ITS systems.

Standard 1 ~ All Datasets

The operating system requires that all dataset names are strings of up to 44 characters that conform to the following restrictions:

· Characters are alphabetic (A-Z), numeric (0-9), national (@,#, and $) and periods (.)

· The whole name must be divided into segments (qualifiers) of up to eight characters each. For example, SEPT.REPORT.DATA is the name of a dataset whose qualifiers are SEPT, REPORT, and DATA.

· The first character of the dataset name and the first character after a period must be alphabetic or national

· The last character of a dataset name may not be a period, nor may there be two consecutive periods.

Standard 2 ~ Non-DB2 and Non-TSO datasets

Non-DB2 and non-TSO dataset names require two qualifiers.

· The high-level qualifier must be the client's three-letter department code.

· The second-level qualifier must be the client's three-letter application code.

· The third-level qualifier should consist of the following variables to create a six-character qualifier:

PROD or TEST	Production dataset or Test dataset
O or B	Datasets allocated by CICS or IMS All other datasets
I or F or L or P or V or A or S or Y	DLI FOCUS LIBRARY PDS VSAM SAS, SEQ SYSTEM

For example, a non-TSO or non-DB2 dataset name would have the following format:

AAA.BBB.PRODOI.*.*

In this example AAA is the client's three letter department code, and BBB is the client's three letter application code, PROD indicates a production dataset, O indicates a dataset allocated by CICS or IMS, I indicates a DLI dataset, and the asterisks indicate a client selected LLQ.

Following the first three qualifiers, the client specifies subsequent levels. When you are naming datasets it is crucial to think about storage management considerations. The qualifiers used in the dataset name regulate how datasets are allocated, stored and managed at ITS. ACS Routines are the rules that determine the data class, storage class, storage group, and management class for the dataset.

Standard 3 ~ TSO datasets

TSO datasets have three qualifiers.

· The high-level qualifier consists of the department code and TSO

· The second-level qualifier consists of TEAM and the SCC assigned team number.

· The third-level qualifier consists of a client selected LLQ.

For example, a TSO dataset name would have the following format:

aaaTSO.TEAMbb.cccccccc

In this example, aaa is the department code, bb is the SCC assigned team number, and cccccccc is the LLQ.

Standard 4 ~ DB2 datasets

If VSAM datasets are to be explicitly defined for table spaces, DB2 requires a special naming convention. Each dataset is composed of the following qualifiers:

aaaDBxxx	VCAT Alias; limited to 8 characters. First three characters must be a valid ITS department code, followed by DBxxx, the DB2 subsystem ID.
DSNDBC or DSNDBD	The first five characters must be DSNDB, followed by C for VSAM clusters or D for VSAM data components
bbbDxxxx	Database Name. First three characters must be a valid application billing code, followed by D (for database), and any four characters.
cccSxxxx cccXxxxx	Table Space or Index Space Name. First three characters must be a valid application billing code followed by S for Table Space or X for Index Space, and any four characters.
I0001	Constant Indication, use for all dataset names
A001	Standard – must be keyed as shown if table space is not partitioned

For example, a DB2 dataset name would have the following format:

aaaDBxxx.DSNDBD.bbbDxxxx.cccSxxxx.I0001.A001 Table Space

aaaDBxxx.DSNDBD.bbbDxxxx.cccXxxxx.I0001.A001 Index Space

In these examples aaaDBxxx is an alias consisting of the valid ITS department code, and the DB2 subsystem ID, DSNDBD indicates a VSAM data component, bbbDxxxx is the database name, cccSxxxx for the Table Space name or cccXxxxx for the Index Space name, I0001 is the Constant Indication, and A001 indicates that the table space is not partitioned.

Standard 5 ~ SYSW LPAR datasets

Dataset names on the SYSW LPAR should use the naming convention DHRT for the first high-level qualifier. The T represents a test and development file.

Standard 6 ~ HFS datasets

In z/OS, UNIX System Services (USS) files and directories are stored in hierarchical file system (HFS) data sets. Like MVS data sets, HFS data sets can be allocated, backed up, restored, and deleted. HFS datasets must be mounted at specific points in the UNIX directory tree structure before they can be accessed though USS. Mountpoints can be requested by contacting the ITS Customer Support Center at 9815197, or toll free, 1-800-722-3946. A Vantive ticket should be requested and assigned to General Systems. The following naming standards have been established for HFS files:

xxx.yyy.**.SYSz.HFS

xxx	The high-level qualifier must be the client's three-letter department code, as shown on the invoice. An additional T indicates the dataset is for test.
yyy	The second-level qualifier must be the client's three-letter application code.
**	The next level qualifier is freeform. The total length cannot exceed 30 chars.
SYSz.HFS	The dataset name must end in SYSz.HFS. Where z is the LPAR on which the dataset is mounted. Z/OS, our current MVS operating system, does not allow HFS datasets to be shared across LPARs.

The following are examples of valid dataset names:

DHR.BDA.SYSA.HFS

DHR.BDA.SYSW.HFS

DATASET NAMES EXAMPLES

This section gives examples of dataset names, how those datasets are stored and managed by SMS, and the page number in the preceding documentation that discusses each allocation.

DB2 DATASETS

TEST

DHRDB51.DSNDBC.MGAUCRDB.MGA00111.I0001.A001

Data Class: DEFAULT

Management Class: NOACTION

Storage Class: DB2TEST

Storage Group: DB2TEST

PRODUCTION

DHRDB01.DSNDBC.MGAUCRDB.MGA00111.I0001.A001

Data Class: DEFAULT

Management Class: NOACTION

Storage Class: DBBASE

Storage Group: DB2PROD

TSO DATASETS

TSO datasets are not differentiated between Production and Test.

DHRTSO.TEAM51.JCL

Data Class: SRCFLIB

Management Class: EXTRBK

Storage Class: TSOBASE

Storage Group: GENPROD

DHRTSO.TEAM49.DOC

Data Class: DEFAULT

Management Class: TSOBASE

Storage Class: TSOBASE

Storage Group: GENPROD

GENERAL DATASETS

PRODUCTION

DHR.EJA.EJA454-1.TRIGGER

Data Class: DEFAULT

Management Class: STANDARD

Storage Class: BASE

Storage Group: GENPROD

DHR.BDA.V.TECH.SUPPORT (VSAM DATASET)

Data Class: DEFAULT

Management Class: STANDARD

Storage Class: BASE

Storage Group: GENPROD

TEST

DHRT.BDA.IMXA.CNTLLIB

Data Class: DDEFAULT

Management Class: STANDARD

Storage Class: BASE

Storage Group: GENTEST

ALLOCATING DATASETS

The process of creating a new dataset is called "allocating" a dataset. This process accomplishes two tasks:

1. Reserves DASD space so there is a place for the information that the dataset will contain; and

2. Enters the name and volume serial of the dataset in the system catalog so that the operating system can find the dataset the next time you request it.

Batch processing creates most datasets. Automatic Class Selection (ACS) routines in SMS have been configured by CS to assign appropriate class information to your datasets based on the allocation parameters and the dataset name specified in your JCL. It is best to review the current data classes that have been defined based on common allocation parameters. By specifying the data class, you no longer need to code the Volume serial number, device type, DCB parameters, or even the amount of space in your JCL. If circumstances arise that require different allocation parameters, they can still be specified in JCL to override the ACS assignments.

When blocksize is unspecified or set to zero in your JCL, SMS will determine the most efficient blocksize based on the record length, dataset organization, and device type. This can greatly improve utilization of DASD, decreasing the total cost of data storage and frees the user from complex calculations based on device geometry to determine an efficient blocksize for datasets.

ACS routines override JCL specified Storage Class

//SMSDS2 DD DSNAME=MYDS2.PGM,STORCLAS=GONEIN3,DISP=(NEW,KEEP)
//MYDATA DD DSN=datasetname, SPACE=(TRK,(1,1)),
// MGMTCLAS=STANDARD,,STORCLAS=BASE,
// RECFM=FB,LRECL=307,BLKSIZE=0,DISP=(,CATLG,DELETE)

ISPF UTILITIES MENU

Step 1. To allocate a dataset, at the ISPF Primary Option Menu select option 3, Utilities. This will bring up the Utility Selection Menu.

Step 2. At the Utility Selection Menu, select option 2, Dataset. This will bring up the Data Set Utility screen.

Step 3. At the Data Set Utility screen, select A, Allocate new data set. Press the TAB key to move to Data Set Name, enter the dataset name (see Naming Datasets below) and press the Enter key. This will bring up the Allocate New Data Set screen.

Step 4. The Allocate New Data Set screen contains a list of parameters for the new dataset. Most of the parameters will already contain information copied from the last dataset you created. Change the parameters by pressing the Tab key to move to that parameter and typing over the existing entry. Make sure that the Volume Serial parameter is left blank to create an SMS dataset. Press the Enter key to accept the parameters for the dataset. This will return you to the Data Set Utility screen. The upper right-hand corner of the screen will contain the message:

DATA SET ALLOCATED

In order to allocate a dataset and make full use of storage management options at ITS, it is essential to understand dataset naming conventions and SMS. The following sections will cover dataset naming standards and the ACS Routines established for Data Class, Storage Class, Management Class, and Storage Groups. Carefully review the attributes for each Data Class, Storage Class, Management Class, and Storage Group at ITS.

DASD MANAGEMENT

DASD management at ITS ensures integrity of your data on DASD, maintains maximum DASD space availability, and promotes optimum use of DASD space. The DASD management practices that most directly affect you are those related to space release, dataset migration (archiving), and the daily backup of new or modified DASD datasets.

SYSTEM MANAGED STORAGE (SMS)

System Managed Storage allows the operating system to take over much of the storage management tasks that previously were performed manually. The purpose of SMS is to eliminate, simplify and automate tasks normally done by users or a storage administrator. SMS uses software programs to manage data security, placement, migration, backup, recall, recovery, and deletion of datasets. This ensures that current data is available when needed, and obsolete data is removed from storage.

The goals of system-managed storage are to:

· Reduce computing costs by improving the use of the storage media; for example, by reducing out-of-space Abends and providing a way to set a free-space requirement.

· Reduce labor costs involved in storage management by centralizing control, automating tasks, and providing interactive controls for storage administrators. This allows the clients to focus on their job responsibilities.

· Reduce the client’s need to be concerned with the physical details of performance, space, and device management. Clients can focus on using data instead of managing data.

SMS is tailored to meet individual needs. SMS allows the storage administrator to affect new dataset allocations, volume extend, and perform data movement by assigning classes and groups to a new dataset which affect dataset attributes, placement, migration, and backup.

Classes and groups are assigned via installation-written ACS Routines. The assigned classes and groups are:

· used by SMS to determine dataset characteristics during initial allocation

· used by SMS to select the best available volume(s) for dataset allocation

· used by SMS for dynamic cache management

· used by HSM for backup and migration decisions

· used by HSM for disaster backup and recovery

All data, storage, and management classes can be viewed via option O of the ISPF Primary Option Menu, option O of OTHER COMMANDS 1, and option S of OTHER COMMANDS 2. The type of data you are storing determines the data class that you select. The next section describes the data classes already set up at ITS, and rules in the ACS Routines that assign datasets to these data classes. Before allocating datasets, review the attributes for the data classes and the ACS Routines that assign datasets to each Data Class.

DATA CLASS

Data Classes are used to allocate attributes for a dataset in one operation. Data classes apply to SMS-managed and non-SMS datasets. They allow you to define allocation defaults and simplify allocations by using data class in place of many keywords. In order to allocate the attributes for the dataset, the data class name must be explicitly specified in the client’s JCL or implicitly via the ACS Routines. SMS uses only those data class attributes that have meaning for the dataset being allocated. All Data Class parameters (with the exception of DATASET NAME TYPE) may be overridden with JCL or other allocation methods. CS will implicitly assign the following data classes via the ACS Routines. Data class attributes are defined in more detail in the appendix.

Table 1 Data Class Names

DATA CLASS NAME	Rule that assigns the Data Class to the dataset
DATAF	When the third qualifier of the dataset name is any of the following: PRODOF, PRODOV, PRODOS, PRODBF, PRODBP, PRODBA PRODBS, TESTOF, TESTOP, TESTOS, TESTBF, TESTBP. TESTBS OR the last qualifier is one of the following: DATA , FDATA
DATAV	When the last qualifier of the dataset name is one of the following: TEXT, VDATA
EXFKSDS	EXFKSDS is used for datasets that exceed 4GB RBA addressing
LOADLIB	When the last qualifier of the dataset name is one of the following: RESLIB, PGMADB, LINKLIB, LOAD* OR the third qualifier is one of the following: PRODBL, TESTOL, TESTBL
SRCFLIB	When the last qualifier of the dataset name is one of the following: COB, ASM, CNTL, PROCLIB, SCR, SOURCE, FOR, JCL*
SRCVLIB	When the last qualifier is one of the following: PLI, PL1, SCRIPT, CLIST
LISTING	When the last qualifier is one of the following: SYSOUT, OUTLIST, LIST, LISTING
KEYED	When the last qualifier is one of the following: PRODOI, PRODBI, PRODBV, TESTOI, TESTOV, TESTBI, TESTBV
DEFAULT	This is the default data class. This data class is assigned to all datasets except where the specific qualifiers are targeted for other data class names or the data class name has been specified in the JCL.

STORAGE CLASS

Storage Classes are used to specify performance and availability levels for SMS-managed datasets. These are used to select a device to meet those goals and requirements thus allowing the dataset allocation to be made in the appropriate storage group. However ITS, does not differentiate between DASD. All production DASD is considered high performance. The storage class is used to assign the proper storage group. These may be specified in JCL, however if an incorrect storage class is specified the dataset would then be assigned to either an incorrect storage group or an incorrect management class, or both. For instance, the dataset could reside on a volume and not be backed up for disaster recovery purposes. For these reasons, CS strongly encourages clients to contact CS and have their datasets coded into the ACS Routines. This eliminates the need to code the STORCLAS parameter into JCL. For the specific DHHS dataset naming convention contact your application manager or Technical Services Storage Management Administrator. The following table lists the defined Storage Classes currently in use. The table also shows what Storage Group would be assigned based on the Storage Class defined to the dataset within the ACS routines.

STORAGE CLASS AND CORESPONDING STORAGE GROUP

Table 2 Storage Class and Corresponding Storage Group

STORAGE CLASS	STORAGE GROUP
ACTSDB	ACTSDB
ACTSDBI	ACTSDBI
ACTSDBRO	ACTSDBRO
ACTSTEST	ACTSTEST
ACTSVRU	ACTSVRU
BASE	GENPROD
BASE1	SGTEMP90
DBBASE	DB2PROD
DB2DASD	DB2PROD
DB2PROD	DB2PROD
DB2TEST	DB2TEST
DHRPERF	DHRPERF
EISTEST	EISTEST
EISTIMS1	EISTIMS1
EISTIMS2	EISTIMS2
GENPROD	GENPROD
GENTEST	GENTEST
GENTESTS	GENTEST
LARGE	LARGE
LARGET	LARGET
OBASE	GENPROD
PERFORM	PERFORM
TSOBASE	GENPROD

STORAGE GROUP

The Storage Class selected will determine the Storage Group for the dataset. Storage groups separate data by client or by type. Storage groups are a collection or pool of storage volumes that are defined to SMS. SMS allows the use of various management classes and various storage classes in a single SMS storage group. Storage groups reduce the need for the user to understand the physical requirements of the storage devices. SMS allows users to specify a data, storage, or management class. The Storage Group that is assigned is dependent upon the Storage Class that is assigned. Multiple Storage Classes can be assigned to the same Storage Group.

You will see the corresponding Storage Groups and Storage Classes in Table 4.

STORAGE GROUP DESCRIPTIONS

Please read through the descriptions of the Storage Groups to determine the Storage Group that holds the type of data you are allocating. After determining the best Storage Group, go to Storage Class and review

Table 3 Storage Group Description

STORAGE GROUP NAME	STORAGE GROUP DESCRIPTION
ACTSDB	This storage group contains the DHHS ACTS production DB2 databases. The client department manages this storage group, with support provided by CS. For the specific dataset naming convention contact your application manager or Technical Services Storage Management Administrator.
ACTSDBI	This storage group contains the DHHS ACTS production DB2 database Indexes for selected table spaces. The client department manages this storage group, with support provided by CS. For the specific dataset naming convention contact your application manager or Technical Services Storage Management Administrator.
ACTSDBRO	This storage group contains the DHHS ACTS production read-only DB2 databases. The client department manages this storage group, with support provided by CS. For the specific dataset naming convention contact your application manager or Technical Services Storage Management Administrator.
ACTSTEST	This storage group contains the DHHS ACTS test DB2 databases. For the specific dataset naming convention contact your application manager or Technical Services Storage Management Administrator. The client department manages this storage group, with support provided by CS.
ACTSVRU	This storage group contains the DHHS ACTS production DB2 databases to support Voice Response Unit child support information requests. For the specific dataset naming convention contact your application manager or Technical Services Storage Management Administrator. The client department manages this storage group, with support provided by CS.
DB2PROD	This storage group contains client production DB2 databases, with exceptions for large DB2 applications where the client department has chosen to manage a private storage group. Segregation of the DB2 applications helps ensure data integrity and consistent performance. CS targets this unique data to this storage group. Also, databases that are allocated specifying a storage class of DBBASE will be targeted to this storage group. The non-DB2 databases currently allocated in this storage group are being reallocated to the GENPROD storage group. The test DB2 databases with storage classes DBTEST and DLDBTEST will be reallocated into storage group DB2TEST. CS manages this storage group.
DB2TEST	This storage group contains the client test DB2 databases. For specific database naming conventions contact your DBA. CS manages this storage group.
EISTEST	This storage group contains the DHHS EIS test VSAM and other general datasets. For the specific dataset naming convention contact your application manager or Technical Services Storage Management Administrator. The client department manages this storage group, with support provided by CS.
EISTIMS1	This storage group contains the DHHS EIS test IMS databases. For the specific dataset naming convention contact your application manager or Technical Services Storage Management Administrator. The client department manages this storage group, with support provided by CS.
EISTIMS2	This storage group contains the DHHS EIS test IMS databases. For the specific dataset naming convention contact your application manager or Technical Services Storage Management Administrator. The client department manages this storage group, with support provided by CS.
GENPROD	This storage group contains the SMS-managed general production data that has been targeted by the storage administrator. General production data includes interactive data such as TSO and ISPF/PDF libraries, online files or databases, batch files, and VSAM not being targeted to other specific storage groups. DB2 databases should not be targeted into this pool. Datasets that have not been identified as SMS-managed, but specify a storage class of BASE or TSOBASE during allocation will also be allocated in this storage group.
GENTEST	This storage group contains general test data. These are datasets with the naming convention %%%T. or %%%TSOT. or if one of the qualifiers is one of the following: TEST* DEVE*. By contacting CS, datasets with other specific identification as test data maybe requested for inclusion. CS manages this storage group.
IEVSSXA	This storage group contains the DHHS EIS IEVS datasets. For the specific dataset naming convention contact your application manager or Technical Services Storage Management Administrator. The client department manages this storage group, with support provided by CS.
LARGE	This storage group contains specifically managed datasets based on their size. Currently, datasets greater than or equal to approximately 1450 cylinders have been targeted by name to this storage group. To explore this option, contact the CS Capacity and Performance staff. CS manages this storage group.
LARGET	This storage group has the same criteria as LARGE except it is for test datasets. CS manages this storage group.
SGTEMPW	This storage group contains three types of datasets generated on the test system. The first group is system generated temporary datasets that exist for the duration of a job. Secondly, datasets with a storage class of BASE1, or a management class GONEIN1 or GONEIN3 will be allocated in this storage group. Lastly, datasets that have not been identified as SMS-managed or a storage class was not specified in the JCL, will also be allocated into this storage group. CS manages this storage group.
SGTEMP90	This storage group contains three types of datasets generated on the production systems. The first group is system generated temporary datasets that exist for the duration of a job. Secondly, datasets with a storage class of BASE1, or a management class GONEIN1 or GONEIN3 will be allocated in this storage group. Lastly, datasets that have not been identified as SMS-managed or a storage class was not specified in the JCL, will also be allocated into this storage group. CS manages this storage group.

STORAGE GROUP SERVICES

The following table reflects various services for the storage groups that would be of interest to the clients. Definitions and possible values follow in Storage Group Service Definitions.

Table 4 Storage Group Services

STORAGE GROUP NAME	SERVICES
STORAGE GROUP NAME	Automatic Migration	Automatic Backup	Automatic Dump
ACTSDB	YES	YES	NO
ACTSDBI	NO	NO	NO
ACTSDBRO	NO	NO	NO
ACTSTEST	NO	NO	NO
ACTSVRU	NO	NO	NO
DB2PROD	NO	NO	NO
DB2TEST	NO	NO	NO
EISTEST	NO	NO	NO
EISTIMS1	NO	NO	NO
EISTIMS2	NO	NO	NO
GENPROD	YES	YES	NO
GENTEST	PRIMARY	NO	NO
IEVSSXA	PRIMARY	NO	NO
LARGE	YES	NO	NO
LARGET	NO	NO	NO
PERFORM	YES	YES	NO
SGTEMPW	INTERVAL	NO	NO
SGTEMP90	INTERVAL	NO	NO

STORAGE GROUP SERVICE DEFINITIONS

AUTO MIGRATE The AUTO MIGRATE value shows whether the DASD volumes in this Storage Group are eligible for automatic space management processing. Space management processing is a function of DFSMShsm that manages DASD storage automatically by deletion of temporary datasets, release of unused, over-allocated space, and migration of low-activity datasets from client accessible volumes to HSM volumes. Primary space management process daily at 0300 and interval migration is hourly.

Possible values: YES, NO, INTERVAL, or PRIMARY

If AUTO MIGRATE is YES or INTERVAL, the datasets are eligible for primary space management and automatic interval migration. If AUTO MIGRATE is NO, the datasets are not eligible for automatic migration. If AUTO MIGRATE is PRIMARY the datasets are only eligible for primary space management. Dataset eligibility is based on the management class attributes.

AUTO BACKUP The value in the AUTO BACKUP data column shows whether the volumes in this Storage Group are eligible for automatic backup processing. The automatic backup processing is a function of DFSMShsm that makes incremental backup copies of newly created or changed datasets based on the management class attributes assigned to each dataset. Automatic backup processes daily at 0130.

Possible values: YES or NO

If AUTO BACKUP is YES, the datasets are eligible for automatic backup. If AUTO BACKUP is NO, then none of the datasets in this Storage Group will be backed up automatically.

AUTO DUMP The value in the AUTO DUMP data column shows whether all volumes in this Storage Group can be automatically dumped using DFSMShsm. The automatic dump function copies all the data from the DASD volume to tape volumes weekly beginning at 0015.

Possible values: YES or NO

MANAGEMENT CLASS

Management Classes for SMS-managed DASD datasets control dataset backup, retention, and migration services. DFSMShsm uses these attributes to automatically provide both storage management and availability management. Management classes let you define management requirements for individual datasets, rather than defining the requirements for entire volumes. Management classes may be specified in JCL, but attributes are subject to change and possibly the class may be deleted. Many Management Classes are automatically assigned by ACS routines by datasets name. For this reason, CS strongly encourages clients to contact CS and have their datasets coded in the ACS routines. For the specific DHHS dataset naming convention contact your application manager or Technical Services Storage Management Administrator.

To see all the Management Classes go to ISMF on your TSO ISPF session.

Reference Management Class Names and Descriptions in the Appendix.

HIERARCHICAL STORAGE MANAGER (HSM)

Hierarchical Storage Manager provides space management, backup, and recovery functions to manage datasets automatically on a variety of storage devices. It thus reduces manual intervention and optimizes the use of primary storage space, such as G93 volumes. It does so by moving (migrating) and compacting "aged" datasets and then automatically recalling them to primary volumes when they are referenced by a batch job or needed during a TSO session.

After HSM has migrated datasets, the System Catalog indicates that they are cataloged by the volume MIGRAT. Although there is physically no such volume mounted on the system, HSM operates as if there were. For example, if you reference migrated datasets via a standard TSO or batch job command, HSM will recall the datasets for you and then will process your TSO command or proceed with the batch job.

HSM COMMANDS

HDELETE HDELETE deletes one or more migrated datasets from a migration volume. HSM deletes the dataset without recalling it to a primary volume. When HSM deletes the dataset it maintains any backup versions of the dataset and the information in the BCDS.

HDELETE cannot be used to delete datasets from primary volumes or backup volumes.

The following deletes a migrated dataset from the MCDS without waiting for the command to complete:

HDELETE dataset name NOWAIT

HLIST The HLIST command lists information about migrated and/or backed up datasets using the MCDS or the BCDS. If you do not specify which type of information is desired, HSM will list migrated datasets.

The following will list information about the specified dataset from both the MCDS and the BCDS:

HLIST BOTH DATASETNAME(dataset name)

The following will list information about the specified backed up dataset from the BCDS to the terminal:

HLIST BCDS DATASETNAME(dataset name)

The following will list information about datasets beginning with the HLQ within the MCDS to your terminal:

HLIST LEVEL(high level qualifier)

The following will list information about datasets beginning with the HLQ within the MCDS to a permanent dataset:

HLIST LEVEL(high level qualifier) ODS(dataset name)

The results of the HLIST command default to the terminal unless the ODS is specified.

HMIGRATE HMIGRATE one or more data sets to a migration volume. Most commonly used to move datasets off storage groups to tape migration level, ML2.

HRECALL The following will recall a dataset from a migration volume to a primary DASD volume without tying up the TSO session.

HRECALL dataset name NOWAIT

HRECOVER The command HRECOVER is used to recover a backup version of one or more datasets.

The following will recover a dataset from the most recent backup generation:

HRECOVER dataset name

The following will recover a dataset from the X backup volume generation:

HRECOVER dataset name GEN(xxx)

In this command, xxx represents the number of the GDG that you are recovering.

Tape MANAGEMENT

TMS EXPIRATION DATE KEYWORDS

Tape Management System - TMS uses the EXPDT JCL keyword differently than z/OS JES (standard JCL) for tape volume datasets This section describes the TMS use of the EXPDT keyword.

From the TMS Release 5.2 MVS General Information Guide

3.1.3 Specifying CA-1 EXPDT Keywords in TMS

Listed below are the JCL Julian format of CA-1 EXPDT keywords and the corresponding CA-1 batch and online keyword expression of these values.

Table 5 TMS Expiration Date Keywords

JCL EXPDT	Equivalent Keywords	Description of CA-1 Expiration Date keywords
	ZEROS	A date with an internal value of zeros is always displayed as zeros. However the date can only be entered as any number of 0s or the word ZEROS.
yyyy/ddd	yyyy/ddd	Julian date format. The acceptable range of Julian dates is 1960/001 through 2155/366. CA-1 validates all input dates to ensure that they fall within this range.
88uuu	USER/uuu	This keyword allows you to create your own keywords for processing. CA-1 treats this as PERMANENT.
90ddd	CATLG/ddd	Retain ddd days then retain while data set is cataloged to the operating system.
98000	FOREIGN	This is a nonresident tape so do not update the TMC. This value is not stored in the TMC but appears in the Audit data set for type 3 (exception) records. CA-1 does not allow you to set the expiration of a data set to FOREIGN in a TMC record.
98ddd	LDATE/ddd	Retain ddd days after date on which tape was last used.
99000	CATLG or CATALOG	Retain while data set is cataloged to the operating system.
99ccc	CYCLE/ccc	Retain ccc cycles.
99365/99366	PERM or PERMANENT	Retain data set permanently.
	STATS/sss	Status of held tape where sss is the reason code indicating why the tape is being held. This keyword has no JCL equivalent. It is set by programs through the SET_KEYWORD function or is entered through the keyword format STATS/sss to apply permanent retention (other than 99365) to an unknown situation such as a broken chain. Certain Release 4.x expiration dates are set to STATS/sss during a TMC conversion from Release 4.x to Release 5.1. For more information refer to the discussion of the TMSCONTM utility in the CA-1 Release Guide.
	STATS/001	The EXPDT in the JCL is less than the current date - therefore CA-1 set the EXPDT to STATS/001 to prevent the tape from scratching prematurely.
	STATS/002	There is a multivolume chaining error. A TMC volume with this EXPDT is chained to a volume not in the TMC.
	STATS/003	In RMM the EXPDT was 98000. In the conversion routine of RMM to CA-1 the EXPDT is set to STATS/003.
	STATS/004	In RMM the EXPDT was blanks. In the conversion routine of RMM to CA-1 the EXPDT is set to STATS/004.

3.1.3.1 Other Considerations

Warning messages are generated in CA-1 ISPF and TIQ functions for dates entered in the Julian format, yyddd, that correspond to a CA-1 Release 4.x EXPDT keyword.

EXPDT=yyddd date supplied in the JCL falls within the CA-1 EXPDT keyword range, it is treated as a keyword unless:

The CAI.PPOPTION parameter TRUXPD is set to YES (TRUXPD=NO is the default). This option treats all dates as true expiration dates.

If a special DD statement defined in CAI.PPOPTION by the KEYDD keyword which defaults to TMNOKEY is present in the same step, the date is treated as a true expiration date. This is also true for EXPDT=yyyy/ddd.

The CAI.PPOPTION parameter KEYDD, which identifies the ddname (TMNOKEY is the default) placed in the JCL as DD DUMMY, indicates that a date specified in the JCL as 98ddd or 99ccc is treated as a Julian expiration date instead of a CA-1 EXPDT keyword. This override applies to all tapes created in the step in which this special ddname was specified.

If TRUXPD=YES, the CAI.PPOPTION parameter KEYDD acts as an override, allowing dates specified in the JCL as 98ddd or 99ccc to be treated as CA-1 EXPDT keywords instead of true expiration dates.

If LABEL=EXPDT=98ddd or 99ccc was specified and the KEYDD ddname is in the JCL with TRUXPD=NO, the date is treated as a Julian date (see example).

If LABEL=EXPDT=98ddd or 99ccc was specified and the KEYDD ddname is in the JCL with TRUXPD=YES, the date is treated as a CA-1 keyword.

If LABEL=EXPDT=98ddd or 99ccc was specified and the KEYDD ddname is not in the JCL with TRUXPD=NO, CA-1 treats the date as a CA-1 keyword.

If LABEL=EXPDT=98ddd or 99ccc was specified and the KEYDD ddname is not in the JCL with TRUXPD=YES, CA-1 treats the date as a Julian date.

Example:

The JCL to retain a tape until the 71st day of 1998 might look something like this:

//SYSUT2 DD DSN=A.B.C,UNIT=TAPE,DISP=(NEW,CATLG),

// LABEL=EXPDT=98071

//TMNOKEY DD DUMMY

Note: CA-1 does not distinguish between LABEL=EXPDT=98071 and LABEL=EXPDT=1998/071. Both formats appear to CA-1 as 98071.

To treat all dates as true expiration dates, set the TRUXPD option to YES in the TMOOPTxx of CAI.PPOPTION.

When ACCODE is specified with a valid combination for CA-1, EXPDT is not interpreted. If ACCODE=xCAEXPDT, the expiration date is treated as an expiration date regardless of any CA-1 definition. If ACCODE=xCAKEYWD, the expiration date is treated as a keyword.

3.2.1 Default Retention

An installation-defined Default Retention (CA-1 system option RP) is assigned to any tape data set that is created without an expiration date, retention period or ACCODE parameter in the JCL. The default can be either a given number of days, a specific Julian date, or CA-1 keyword date. A status indicator in the TMC reflects the assignment of the Default Retention. The default TMS retention period if no EXPDT= parameter is used is 5 days. After 5 days, TMS will automatically delete the dataset.

When the Default Retention is taken, CA-1 can optionally set another status indicator to indicate that the expiration date is eligible to be overridden if there is an entry for the data set in the Retention Data Set.

When the JCL provides an EXPDT, RETPD or ACCODE parameter, this status indicator is not turned on. However, CA-1 system option RO does allow the indicator to be set, regardless of the JCL specification, so that you can use the Retention Data Set (RDS) to enforce tape retention standards in your environment.

In either case, if there is no corresponding entry in the Retention Data Set (RDS), CA-1 honors the date calculated at OPEN for output.

3.2.2 Default Abend Retention

When a tape data set normally OPENed for output (DISP=NEW or DISP=MOD) is CLOSEd by an abend, the program is probably to be rerun and the normal retention period of the tape may no longer be valid. To allow for this condition, CA-1 changes the expiration date for the tape data sets CLOSEd by abend to the Default Abend Retention (CA-1 system option ABE) and sets a status indicator. An exit is available to establish retention other than the Default Abend Retention. The expiration date can also be assigned by the Retention Data Set if the ABEND keyword is specified for the data set.

3.2.3 Retention Data Set

The Retention Data Set (RDS) is used to supply expiration criteria after a tape data set has been created. The batch program TMSEXPDT processes the RDS and compares the control statements it contains with TMC records. For the RDS to override the expiration date, a status indicator in the TMC record must indicate that the data set is eligible to be overridden. This indicator is always turned on when there is no JCL-supplied EXPDT, RETPD or ACCODE parameter.

CA-1 system option RO provides the means to turn this indicator on even when the JCL supplies the retention, giving the RDS the final authority on all tape data set retention. When the option is on, it facilitates centralized enforcement of retention standards. A Retention Data Set option of SELECT=ALL allows all TMC records meeting selection criteria to be assigned a new expiration date regardless of the status indicator in the TMC.

Virtual TAPE SubSystem

The IBM Virtual Tape Subsystem Library (VTL) is a hardware and software combination that creates tape data sets onto virtual tape volumes. The purpose of this is to reduce the usage of old tape cartridges, increase data transfer speeds, and implement data set duplication to the Western Data Center (WDC).

The following is the IBM VTL process.

Tape datasets that are not already in the Storage Management Subsystem exclude list or do not have “OFFSITE” as the 3rdlvl data set name qualifer will be placed on a virtual volser with one of the following first letters/numbers; ‘E’ or ‘F’ and cataloged in the system and TMS catalogs. The VTL series volser will only contain one dataset unless there is dataset stacking by label in the job's JCL to have multiple datasets reside on one volser. When first created, the tape data set resides on a staging DASD device in the VTL Server. The VTL series volser will be immediately copied (two copies) to two the high density tape volumes on the VTL Server. The high density tape volumes on the VTL Server are a very high density and high speed tape cartridge and tape drive that will contain numerous VTL volsers. Jobs can access the tape dataset by either dataset name if cataloged or by the VTL volser if the dataset is not cataloged. Users will only see the dataset assigned to a VTL volser and not what high density tape volumes on the VTL Server the volser has been duplicated to.

DR Tapes

Shortly after the tape dataset and volser are created, the VTL Server sends a copy to the WDC VTL Server.
This process is used primarily for disaster recovery (DR) purposes. The offisite vault is no longer used. All DR.DHR.** backup tapes are automatically copied to the WDC when created. There will be two DR.DHR.** tape volsers, one at the Eastern Data Center (EDC) and one at the WDC.
A user no longer has to request a DR.DHR.** volser to be returned from the offsite vault. The user can immediately access the DR.DHR.** volser since it resides in both the EDC and WDC VTL Servers.

Offsite Tapes

The Storage Management Subsystem VTL tape dataset exclude list and JCL are used as input to the new VTL system so as to prevent 'as much as possible' inadvertently placing tape datasets onto the VTL volsers that need to be sent offsite. For example, tape datasets that were created to be shipped offsite of ITS are placed into the Storage Management Subsystem exclude list so as to place the dataset on a physical tape cartridge.
A user can also place “OFFSITE” in the 3rdlvl data set name qualifier and “UNIT=NONSILO” to automatically place the tape data set on a cartridge tape to have it later sent offsite.

There are two procedures to follow to remove a tape dataset from at VTL volser and place it on an individual physical tape cartridge for possible offsite use.

First the user must identify the dataset name to ITS for exclusion in the VTL. Send an email to TECH.SUPPORT.REQUEST.GENERAL@DHHS.NC.GOV to have the dataset excluded from being processed by the VTL
Then the user runs an IEBGENER for sequential datasets or IEBCOPY for partitioned datasets to copy the tape dataset from the VTL volser to the physical tape cartridge.

Send all questions and requests on the VTL to TECH.SUPPORT.REQUEST.GENERAL@DHHS.NC.GOV.

Appendix

DATA CLASS ATTRIBUTES

The following three tables list data classes and their attributes that are available for client specification. Definitions and possible values follow in Data Class Attribute Definitions.

ATTRIBUTES	DATA CLASS NAME
ATTRIBUTES	DATAF	DATAV	DIRECT	ENTRY	KEYED	LINEAR
RECORG	--	--	RR	ES	KS	LS
RECFM	FB	VB	--	--	--	--
LRECL	80	225	--	--	--	--
KEYLEN	--	--	--	--	--	--
KEYOFF	--	--	--	--	0	--
AVGREC	U	U	U	U	U	U
AVG VALUE	80	255	4,096	4,096	4,096	4,096
SPACE PRIMAR	5,000	5,000	100	100	100	100
SPACE SECON	5,000	5,000	100	100	100	100
SPACE DIRECTORY	---	---	---	---	---	---
RETPD or EXPDT	---	---	---	---	---	---
ADDITIONAL VOLUME AMT	---	---	---	---	---	---
IMBED	---	---	---	---	---	---
REPLICATE	---	---	---	---	---	---
CISIZE DATA	---	---	---	---	---	---
%FREE SPACE CA	---	---	---	---	10	---
%FREE SPACE CI	---	---	---	---	10	---
SHARE XREGION	---	---	---	---	2	---
SHARE XSYSTEM	---	---	---	---	3	---
DATASET NAME TYPE	---	---	---	---	---	---
EXTD ADDRESS.	---	---	---	---	---	---
REUSE	---	---	---	---	---	---
INITIAL LOAD				---	---	---
SPANNED/ NONSPANNED	---	---	---	---	---	---
BWO	---	---	---	---	---	---
LOG	---	---	---	---	---	---
LOGSTREAM ID	---	---	---	---	---	---
REC ACC BIAS	USER	---	---	---	---	---

ATTRIBUTES	DATA CLASS NAME
ATTRIBUTES	LISTING	LOADLIB	SRCFLIB	SRCVLIB	DEFAULT	TEST
RECORG	--	--	--	--	--	--
RECFM	VBA	U	FB	VB	--	--
LRECL	137	---	80	255	--	--
KEYLEN	---	---	---	---	---	---
KEYOFF	---	---	---	---	---	---
AVGREC	U	U	U	U	U	---
AVG VALUE	137	23,476	80	255	---	---
SPACE PRIM C	20,000	50	5,000	5,000	5,000	---
SPACE SECON	20,000	50	5,000	5,000	5,000	---
SPACE DIRECTORY	----	62	62	62	----	----
RETPD or EXPDT	----	----	----	----	----	----
ADDITIONAL VOLUME AMT	---	---	---	---	---	---
IMBED	----	----	----	----	----	----
REPLICATE	----	----	----	----	----	----
CSIZE DATA	----	----	----	----	----	----
%FREE SPACE CA	----	----	----	----	----	----
%FREE SPACE CI	----	----	----	----	----	----
SHARE XREGION	----	----	----	----	----	----
DATASET NAME TYPE	---	---	---	---	---	---
SHARE XSYSTEM	----	----	----	----	----	----
EXTD ADDRESS.	YES	---	---	---	---	---
REUSE	NO	NO	NO	---	---	---
INITIAL LOAD				---	---	---
SPANNED/ NONSPANNED	---	---	---	---	---	---
BWO	---	---	---	---	---	---
LOG	---	---	---	---	---	---
LOGSTREAM ID	---	---	---	---	---	---
REC ACC BIAS	USER	---	---	---	---	---

ATTRIBUTE	DATA CLASS NAME
ATTRIBUTE	EXFKSDS	KEY4096	SEQ4096
RECORG	KS	KS	ES
RECFM	---	---	---
LRECL	---	---	---
KEYLEN	---	---	---
KEYOFF	---	---	---
AVGREC	U	U	U
AVG VALUE	4096	4096	4096
SPACE PRIM	100	100	100
SPACE SECON	100	100	100
SPACE DIRECT	----	---	---
RETPD or EXPDT	----	----	----
ADDITIONAL VOLUME AMT	---	---	---
IMBED	----	----	----
REPLICATE	----	----	----
CISIZE DATA	----	4096	4096
%FREE SPACE CA	10	10	----
%FREE SPACE CI	10	10	----
SHARE XREGION	2	2	2
SHARE XSYSTEM	3	3	3
DATASET NAME TYPE	---	---	---
EXTD ADDRESS.	YES	---	---
REUSE	NO	NO	NO
INITIAL LOAD	RECOVERY	RECOVERY	RECOVERY
SPANNED/ NONSPANNED	---	---	---
BWO	---	---	---
LOG	---	---	---
LOGSTREAM ID	---	---	---
REC ACC BIAS	USER	---	---

DATA CLASS ATTRIBUTE DEFINITIONS

RECORG The RECORG field shows how VSAM datasets allocated by a Data Class are organized.

Possible values:

KS	VSAM Keyed Sequential Dataset
ES	VSAM Entry Sequenced Dataset
RR	VSAM Relative Record Dataset
LS	VSAM Linear Space Dataset

A blank field (the default) means that the Data Class is used for non-VSAM datasets having Partitioned Organization (PO) or Physical Sequential (PS) organization.

RECFM The RECFM field shows the record format and type of carriage control assigned to non-VSAM datasets:

Possible values (they may appear singly or in combination):

B	Blocked format
F	Fixed format
S	Standard (if format fixed) or Spanned (if format is variable)
U	Undefined format
V	Variable format
A	ANSI carriage control
M	Machine carriage control

A blank field (the default) means that the Data Class is used for non-VSAM datasets.

LRECL The LRECL field shows, in bytes, the logical record length. The value shown is the length of fixed-length records or the maximum length of variable-length records.

Possible values:

1 to 32760 or blank	for non-VSAM datasets
1 to 32761 or blank	for VSAM datasets

If you are using a key-sequenced VSAM dataset, the KEYLEN attribute cannot be larger than the logical record length.

KEYLEN The KEYLEN field shows, in bytes, the size of each record key in a non-VSAM dataset, or the size of each key field in a key-sequenced VSAM dataset.

Possible values:

0 to 255	for non-VSAM datasets.
1 to 255	for key sequenced VSAM datasets

KEYOFF The KEYOFF field applies only to key-sequenced VSAM datasets. The field shows, in bytes, the distance from the start of the record to the start of the key field.

Possible values:

0 to 32760

KEYOFF must be in the range 0 to the difference between LRECL and KEYLEN.

AVGREC The AVGREC field shows whether this Data Class allocates space in bytes, kilobytes, or megabytes.

Possible values:

K	Space is allocated in kilobytes
M	Space is allocated in megabytes
U	Space is allocated in bytes.

AVG VALUE The AVG VALUE field shows the multiplication factor used in determining allocated space. Primary space equals AVG VALUE times SPACE PRIMARY; secondary space equals AVG VALUE times SPACE SECONDARY. In both cases, space is allocated in bytes if AVGREC = U, in kilobytes if AVGREC = K, or in megabytes if AVGREC = M. Thus, if AVG VALUE = 80, SPACE PRIMARY = 1000, and AVGREC = U, it means that 80,000 bytes of primary space have been allocated.

Possible values:

0 to 65535

SPACE PRIMARY The SPACE PRIMARY value; when multiplied by AVG VALUE, determines the amount of space that this Data Class initially allocates for a dataset. Space will be allocated in bytes if AVGREC = U, in kilobytes if AVGREC = K, or in megabytes if AVGREC = M. Thus if SPACE PRIMARY = 200, AVG VALUE = 1, and AVGREC = K, the initial space allocated will be 200K (200 X 1).

Possible values:

0 to 999999

SPACE SECONDARY The SPACE SECONDARY value, when multiplied by AVG VALUE, determines the additional space that can be allocated for a dataset. Space will be allocated in bytes if AVGREC = U, in kilobytes if AVGREC = K, or in megabytes if AVGREC = M. Thus if SPACE SECONDARY = 50, AVG VALUE = 6, and AVGREC = M, the additional space allocated will be 300 (50 X 6) megabytes.

Possible values:

0 to 999999

SPACE DIRECTORY The SPACE DIRECTORY field shows the number of blocks allocated for the directory of a partitioned dataset.

Possible values: 0 to 999999

RETPD OR EXPDT The RETPD OR EXPDT field shows either the retention period or the expiration date assigned to datasets by this Data Class. Datasets will be deleted or archived either one day after the retention period or on the expiration date. You can override the Data Class value with JCL or other allocation methods, but they don’t appear in the data column.

Possible values:

yyyy/mm/dd	Any year from 1900 to 2155; month: 01 to 12; day: 01 to 31
yyyy/00/00	The expiration date has been set to this special value, which is meaningful to other programs. The year yyyy is in the range 1900-2155
0 to 9999	Datasets expire in the number of days shown
The following special characters can appear in this column:
------------------	No retention period or expiration date has been specified for this data class
???????????	The value cannot be displayed because of a data conversion error

ADDITIONAL VOLUME The ADDITIONAL VOLUME AMT field shows the type of allocation amount when a VSAM dataset in extended format begins allocation on subsequent new volumes.

Possible values:

PRIMARY	Primary allocation amount has been requested.
SECONDARY	Secondary allocation amount has been requested.

If the value has not been specified. The system will use the default value of PRIMARY.

IMBED The IMBED field is for key-sequenced VSAM datasets only. It shows whether each sequence-set record is to be written, as many times as possible, on the first track of the data control area.

Possible values:

YES	Write each sequence-set record, as many times as possible, on the first track of the data control area.
NO	Put the sequence-set records on the same DASD that contains the index records.

REPLICATE The REPLICATE field shows whether VSAM will write each index record on one track of DASD as many times as possible. This option, called index replication, reduces rotational delay, and is available if RECORG is KS.

Possible values:

YES	VSAM will write each index record on a single track of DASD as many times as possible
NO	Each index record will appear on a track only once.

CISIZE DATA The CISIZE DATA field is for VSAM datasets with a RECORG of ES, KS, LS, or RR. This field shows the number of bytes allocated for each control interval in data portion, not the index portion, of a dataset.

To allow for overhead processing, the CISIZE value will be at least seven bytes greater than maximum record size.

Possible values:

1 to 32768

%FREE SPACE CA The %FREE SPACE CA field shows what percentage of each control area in a key-sequenced VSAM dataset should be set aside as free space. VSAM uses the space to lengthen or insert records, as needed.

Possible values:

0 to 100

%FREE SPACE CI The %FREE SPACE CI field shows what percentage of each control interval in a key-sequenced VSAM dataset should be set aside as free space. VSAM uses the space to lengthen or insert records, as needed.

Possible values:

0 to 100

SHARE XREGION The SHARE XREGION field shows how a VSAM dataset can be shared among regions of one system, or across regions of multiple systems.

Possible values:

1	All users can read the dataset OR one user can update it.
2	All users can read the dataset AND one user can update it.
3	All users can read and update the dataset. VSAM does not protect the dataset
4	All users can read and update the dataset. VSAM helps prevent lost, damaged, or altered data.

SHARE XSYSTEM The SHARE XSYSTEM field shows how a VSAM dataset can be shared among systems.

3	All users can read and update the dataset. VSAM does not protect the dataset.
4	All users can read and update the dataset. VSAM monitors access of datasets in order to prevent lost, damaged, or altered data.

DATASET NAME TYPE This column shows the format that is used to allocate datasets using this data class.

Possible values:

EXTENDED PREFERRED	The system allocates datasets in extended format if the necessary system resources are available. Otherwise, it allocates them in non-extended format.
EXTENDED REQUIRED	The system allocates data sets in extended format if the necessary system resources are available. Otherwise, the allocations fail.
LIBRARY	The system allocates datasets as PDSEs.
PDS	The system allocates datasets as PDSs.

EXTENDED

ADDRESSABILITY The extended addressability field specifies whether or not a VSAM KSDS in the extended format is allowed to grow beyond the four gigabyte (4GB) size.

Possible values:

YES	Provides extended addressability.
NO	Does not provide extended addressability.

REUSE The REUSE field indicates whether or not users can open the cluster again and again as a new cluster.

Possible values:

YES	Indicates that the cluster is reusable
NO	Indicates that the cluster is not reusable

INITIAL LOAD The INITIAL LOAD field indicates whether or not the storage allocated to the data component was preformatted before records were inserted during initial load.

Possible values:

SPEED	Indicates that the data component's space was not preformatted
RECOVERY	Indicates that the data component's space was preformatted

SPANNED/

NONSPANNED The SPANNED/NONSPANNED field shows whether the data record is allowed to cross control interval boundaries.

Possible values:

SPANNED	Indicates that the record is contained in more than one control interval.
NONSPANNED	Indicates that the record is contained in one control interval

The following special characters may appear in this data column:

------------------	If the value has not been specified.
???????????	Value cannot be displayed because of data conversion error.

BWO The BWO field shows that backup-while-open (BWO) is allowed for the sphere.

Possible values:

TYPECICS	BWO processing for CICS VSAM file control datasets is allowed
TYPE IMS	BWO processing for IMS VSAM datasets is to be used
NO	BWO does not apply to this cluster

The following special characters may appear in this data column:

-------------------	If the value has not been specified
???????????	Value cannot be displayed because of a data conversion error

LOG The LOG field shows whether the sphere to be accessed with VSAM RLS is recoverable or non-recoverable.

Possible values:

NONE	Not a recoverable dataset.
UNDO	Changes to the sphere accessed in RLS mode can be backed out.
ALL	Both the external backout and the forward recovery capability are available for the sphere accessed in RLS mode.

LOGSTREAM ID The LOGSTREAM ID shows the name of the recovery logstream.

Possible values:

Dataset name

Prefix name for the recovery logstream dataset.

REC ACC BIAS The RECORD ACCESS BIAS field allows the system to acquire and choose the buffering algorithms.

Possible values :

SYSTEM	A value of SYSTEM allows the system to choose the number of buffers and the buffering algorithms for the VSAM dataset.
USER	A value of USER prevents SYSTEM MANAGED BUFFERING and number of buffers and buffering algorithms will be based on user specified (or defaulted) values and current algorithms.

MANAGEMENT CLASS Attributes

The following contains several of the primary Management Classes. There are approximately 140 management classes; too many to list in this document. To view all the Management Classes go to ISMF on your TSO ISPF session.

From the ISPF Primary Option Menu, enter on Option ===> O.O.S
Select Option # 3 – Management Class
Enter an Active CDS: CDS Name . . . . . . . . . 'ACTIVE'
You should now be on the MANAGEMENT CLASS APPLICATION SELECTION screen
Enter a Management Class or * to see all or management classes starting with a specific character.
For Example to see all the Gone In management classes enter; Management Class Name . . . G*
To show a list of the management classes enter at, Select one of the following options:
1 1. List - Generate a list of Management Classes

You will now see a listing of all the Gone In Management Classes such as GI7 – relates to Gone In 7 Days.

CS will implicitly assign the following management classes via the ACS routines based on the rules set forth.

Management Class Name	Rule that assigns the Management Class to the dataset
EXTRBKP	Assigned to all DASD datasets that have a low-level(last) qualifier of COB* ASM* JCL* CNTL* CLIST LINKLIB PLI PROCLIB SCRIPT SRC SOURCE TEXT FOR* JCLLIB COBOL LOAD* PGMLIB RESLIB TEXT PL1
ACTSDS	Assigned to ACTS Production DASD datasets with the naming convention: DHR.FKO., DHR.FKY., DHR.NHD.**
GONEIN3	Assigned to DASD datasets with the naming convention: LLQ=LIST, SYSOUT, OUT, OUTPUT, LISTING, OUTLIST
NOACTION	Assigned to all DASD datasets with a storage class of ‘LARGE’ or ‘PERFORM’ or with a high-level(first) qualifier of one of the following: %%%PROD %%%TEST OR a third level qualifier of one of the following: PRODOI PRODBI TESTOI TESTBI
STANDARD	This management class will be assigned to all DASD datasets that have been defined as SMS-managed and there has been no specification of a special class in the client’s JCL or via the ACS routines.
TSOBASE	This management class will be assigned to all DASD datasets with a high-level qualifier of: %%%TSO

MANAGEMENT CLASS ATTRIBUTES Definitions

The following three tables list all attributes of the management classes for DASD datasets. The specific classes listed are assigned via the ACS Routines. These are a representation of Management Classes. The attributes of all Management Classes may be reviewed in ISMF. Definitions and possible values follow in Management Class Attribute Definitions. DHRT datasets will default to a Management Class of GI395T unless requested otherwise.

ATTRIBUTES	MANAGEMENT CLASS NAME
ATTRIBUTES	EXTRBKP	GI3	GONEIN3	GDG5	NOACTION
Expire After Days Non-Usage	NOLIMIT	3	4	NOLIMIT	NOLIMIT
Expire After Date/Days	NOLIMIT	3	NOLIMIT	NOLIMIT	NOLIMIT
Retention Limit	NOLIMIT	NOLIMIT	NOLIMIT	0	NOLIMIT
Partial Release	COND IMMED	COND IMMED	COND IMMED	COND IMMED	NO
Primary Days Non-Usage	15	--	0	15	--
Level 1 Days Non-Usage	45	--	0	20	--
Command/Auto Migrate	BOTH	NONE	COMMAND	BOTH	NONE
# GDG Elements on Primary	1	1	1	5	1
Rolled Off GDS Action	EXPIRE	EXPIRE	EXPIRE	EXPIRE	EXPIRE
Backup Frequency	0	--	--	0	--
# Backup Versions (DS Exists)	5	--	--	2	--
# Backup Versions (DS Deleted)	2	--	--	2	--
Retain Days Only Backup	60	--	--	60	--
Retain Days Extra Backup	30	--	--	30	--
Admin/User CMD Backup	BOTH	NONE	NONE	BOTH	NONE
Auto Backup	YES	NO	NO	YES	NO
Backup Copy Tech	STANDARD	STANDARD	STANDARD	STANDARD	STANDARD

ATTRIBUTES	MANAGEMENT CLASS NAME
ATTRIBUTES	NORELSE	TSOBASE	STANDARD	ACTSDS
Expire After Days Non-Usage	NOLIMIT	NOLIMIT	NOLIMIT	NOLIMIT
Expire After Date/Days	NOLIMIT	NOLIMIT	NOLIMIT	NOLIMIT
Retention Limit	NOLIMIT	NOLIMIT	0	NOLIMIT0
Partial Release	NO	COND IMMED	COND IMMED	COND IMMED
Primary Days Non-Usage	15	10	15	4
Level 1 Days Non-Usage	45	15	20	7
Command/Auto Migrate	BOTH	BOTH	BOTH	BOTH
# GDG Elements on Primary	1	1	1	--
Rolled Off GDS Action	EXPIRE	EXPIRE	EXPIRE	--
Backup Frequency	0	0	0	1
Backup Versions (DS Exists)	2	5	2	1
# Backup Versions (DS Deleted)	2	2	2	0
Retain Days Only Backup	60	60	60	60
Retain Days Extra Backup	30	30	30	0
Admin/User CMD Backup	BOTH	BOTH	BOTH	BOTH
Auto Backup	YES	YES	YES	YES
Backup Copy Tech	STANDARD	STANDARD	STANDARD	STANDARD

These are DHHS specific Management Classes for Test datasets
Default is GI395T

ATTRIBUTES	MANAGEMENT CLASS NAME
ATTRIBUTES	GI90T	GI180T	GI395T
Expire After Days Non-Usage	90	180	395
Expire After Date/Days	NOLIMIT	NOLIMIT	NOLIMIT
Retention Limit	90	180	395
Partial Release	COND IMMED	COND IMMED	COND IMMED
Primary Days Non-Usage	15	15	15
Level 1 Days Non-Usage	20	20	20
Command/Auto Migrate	BOTH	BOTH	BOTH
# GDG Elements on Primary	1	1	1
Rolled Off GDS Action	EXPIRE	EXPIRE	EXPIRE
Backup Frequency	1	1	1
Backup Versions (DS Exists)	2	2	2
# Backup Versions (DS Deleted)	2	2	2
Retain Days Only Backup	60	60	60
Retain Days Extra Backup	30	30	30
Admin/User CMD Backup	BOTH	BOTH	BOTH
Auto Backup	YES	YES	YES
Backup Copy Tech	STANDARD	STANDARD	STANDARD

MANAGEMENT CLASS ATTRIBUTE DEFINITIONS

EXPIRE NON-USAGE The value in the EXPIRE NON-USAGE data column shows how many days an unaccessed dataset can exist before expiring. Datasets become eligible for expiration when the number of days since last access reaches the value in this column.

Possible values: 1 to 9999 or NOLIMIT

EXPIRE DATE/DAYS The value in the EXPIRE DATE/DAYS data column shows the expiration date or number of days until the datasets expire, beginning with the creation date.

Possible values: yyy/mm/dd, 0 to 9999, or NO LIMIT

If both the EXPIRE AFTER DAYS NON-USAGE and EXPIRE AFTER DATE/DAYS fields have a value of NOLIMIT, the datasets never expire. If either has a value of NOLIMIT and the other field specifies an expiration date or the number of days until expiration, the datasets expire at the specified time. If both fields specify expiration dates or the number of days until expiration, the datasets or objects expire on the later date.

RET LIMIT The RET LIMIT value shows whether the DFSMShsm will use the RETPD or EXPDT that a client or Data Class specifies for a dataset. If the value is 0, SMS will not use the specified RETPD or EXPDT. A value of 1 to 9999 represents a number of days. This number overrides RETPD or EXPDT if the specified RETPD or EXPDT exceeds it. Otherwise, SMS uses the specified RETPD or EXPDT, ignoring the number. A value of NOLIMIT allows an unlimited RETPD or EXPDT.

Possible values: 0 to 9999 or NOLIMIT

PARTIAL RELEASE The value in the PARTIAL RELEASE data column shows whether or not the datasets can have unused space automatically released. Partial Release applies only to VSAM dataset in extended format, or non-VSAM datasets.

Possible values:

YES	Release unused space automatically during the Space Management cycle.
CONDITIONAL	Unused space can be released automatically only if a secondary allocation exists for the dataset.
YES IMMED	Release unused space when a dataset is closed or during the Space Management cycle, whichever comes first.
COND IMMED	Unused space for datasets with secondary allocation is released either when a dataset is closed or during the Space Management cycle, whichever comes first.
NO	Do not release unused space.

Note that for Extended VSAM datasets, CONDITIONAL or COND IMMED is treated the same as YES or YES IMMED.

PRIMARY DAYS The value in the PRIMARY DAYS data column represents the minimum number of days that must elapse since last access before a dataset is eligible for migration. A value of 0 means that datasets are immediately eligible.

Possible values: 0 to 9999

LEVEL 1 DAYS The LEVEL 1 DAYS column value indicates whether datasets can migrate to Level 1 storage and how long they can remain there.

Possible values:

0	No migration to Level 1. Datasets migrate directly from primary storage to Level 2.
1 to 9999	The total number of consecutive days that datasets must remain unaccessed before becoming eligible to migrate from Level 1 to Level 2.
NOLIMIT	Datasets cannot migrate to Level 2 automatically, but they can do so by command, or they can remain on Level 1 for an unlimited period.

CMD/AUTO MIGRATE The CMD/AUTO MIGRATE column shows whether datasets can migrate between storage levels. The field also shows how migration, if allowed, can be initiated.

Possible values:

BOTH	Datasets can migrate either automatically or by command
COMMAND	Datasets can migrate by command only.
NONE	Datasets cannot migrate between storage levels.

# GDG ON PRIMARY The # GDG ON PRIMARY column shows how many of the newest generations of a GDG must always occupy primary storage. Any generations older than this set of newest generations are eligible for early migration. They will be chosen for migration in preference to non-generation datasets.

If the field shows 0, all generations of the GDG are given priority for early migration.

Possible values: 0 to 255

ROLLED-OFF GDS

ACTION The value in the ROLLED-OFF GDS ACTION data column indicates whether the GDS will expire or migrate after it has been removed from the GDG.

Possible values: MIGRATE or EXPIRE

BACKUP FREQUENCY A value of 1 to 9999 in the BACKUP FREQUENCY data column represents the minimum number of days between backups for datasets. A new backup of a dataset can be made after this period of days only if the dataset is changed during that period.

A BACKUP FREQUENCY of 0 means that the dataset, if changed, will be backed up each time DFSMShsm processes the volume that contains them.

Possible values: 0 to 9999

# BACKUPS

(DS EXISTS) The # BACKUPS (DS EXISTS) value shows the maximum number of backups versions to retain for a dataset.

Only the most recent automatic backups can be kept. Each backup of a given dataset will contain a different version of the dataset.

Possible values: 1 to 13

# BACKUPS

(DS DELETED) The # BACKUPS (DS DELETED) value shows whether automatic backups of a dataset will be kept after the dataset is deleted. A value of 0 means that no such backups will be kept. A value of 1 or higher represents the maximum number that can be kept.

Each automatic backup of a deleted dataset contains a different version of the dataset. Only the most recent backups will be kept.

Possible values: 0 to 13

RETAIN DAYS ONLY

BACKUP The value in the RETAIN DAYS ONLY BACKUP data column shows how long the most recent backup copy of a dataset will be kept after the dataset is deleted. A numeric value represents a specific number of days; NOLIMIT means unlimited retention.

Possible values: 1 to 9999 or NOLIMIT

RETAIN DAYS EXTRA

BACKUPS The value in the RETAIN DAYS EXTRA BACKUPS column shows how long to keep backups of a dataset that pre-date the most recent backup. Each of these older backups will be kept for the period specified, regardless of whether the dataset exists or has been deleted. A numeric value represents a specific number of days; NOLIMIT means unlimited retention.

Possible values: 1 to 9999 or NOLIMIT

ADM/USER BACKUP The value in the ADM/USER BACKUP column shows who is authorized to perform command backups against the datasets. If only the Storage Administrator can perform command backups, the value will be ADMIN. BOTH means that clients as well as the Storage Administrator can perform command backups. NONE means that neither clients nor the Storage Administrator can perform command backups.

Possible values: ADMIN, BOTH or NONE

AUTO BACKUP The value in the AUTO BACKUP column shows whether automatic backup is allowed for datasets.

Possible values: YES or NO