Chapter 4. Storage management software

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Storage management software

DFSMS is an exclusive element of the z/OS operating system that automatically manages data from creation to expiration. This chapter covers the following topics:

•The DFSMS utility programs to assist you in organizing and maintaining data

•The major DFSMS access methods

•The data set organizations

•An overview of the elements that comprise DFSMS:

– DFSMSdfp, a base element of z/OS

– DFSMSdss, an optional feature of z/OS

– DFSMShsm, an optional feature of z/OS

– DFSMSrmm, an optional feature of z/OS

– z/OS DFSORT

This chapter includes the following sections:

•Overview of DFSMSdfp utilities

•DFSMSdfp access methods

•Access method services (IDCAMS)

•Virtual Storage Access Method

•Data set separation

•Data Facility sort

•Data Set Services (DFSMSdss)

•Hierarchical Storage Manager

•Removable media manager (DFSMSrmm)

4.1 Overview of DFSMSdfp utilities

Utilities are programs that perform commonly needed functions. DFSMS provides utility programs to assist you in organizing and maintaining data. There are system and data set utility programs that are controlled by job control language (JCL), and utility control statements.

This section is intended to give you only an overview about what system utilities and data set utilities are, along with their name and a brief description of their purpose. For more details and to help you find the program that performs the function you need, see “Guide to Utility Program Functions” in z/OS DFSMSdfp Utilities, SC26-7414.

4.1.1 System utility programs

System utility programs are used to list or change information related to data sets and volumes, such as data set names, catalog entries, and volume labels. Most functions that system utility programs can perform are accomplished more efficiently with other programs, such as IDCAMS, ISPF/PDF, ISMF, or DFSMSrmm.

Table 4-1 lists and describes system utilities that are provided by DFSMSdfp.

Table 4-1 System utility programs

System utility	Alternate program	Purpose
IEHINITT	DFSMSrmm EDGINERS	Write standard labels on tape volumes.
IEHLIST	ISMF, PDF 3.4	List system control data.
IEHMOVE	DFSMSdss, IEBCOPY	Move or copy collections of data.
IEHPROGM	Access Method Services, PDF 3.2	Build and maintain system control data.
IFHSTATR	DFSMSrmm, EREP	Select, format, and write information about tape errors from the IFASMFDP tape.

4.1.2 Data set utility programs

You can use data set utility programs to reorganize, change, or compare data at the data set or record level. These programs are controlled by JCL statements and utility control statements.

These utilities allow you to manipulate partitioned, sequential, or indexed sequential data sets, or PDSEs, which are provided as input to the programs. You can manipulate data ranging from fields within a logical record to entire data sets. The data set utilities included in this section cannot be used with VSAM data sets. You use the IDCAMS utility to manipulate VSAM data set. For more information, see 4.3.2, “Starting the IDCAMS utility program” on page 40.

Table 4-2 lists data set utility programs and their use.

Table 4-2 Data set utility programs

Data set utility	Use
IEBCOMPR	Compare records in sequential or partitioned data sets, or PDSEs.
IEBCOPY	Copy, compress, or merge partitioned data sets or PDSEs; add RLD count information to load modules; select or exclude specified members in a copy operation; rename or replace selected members of partitioned data sets or PDSEs.
IEBDG	Create a test data set consisting of patterned data.
IEBEDIT	Selectively copy job steps and their associated JOB statements.
IEBGENER or ICEGENER	Copy records from a sequential data set, or convert a data set from sequential organization to partitioned organization.
IEBIMAGE	Modify, print, or link modules for use with the IBM 3800 Printing Subsystem, the IBM 3262 Model 5, or the 4284 printer.
IEBPTPCH	Print or punch records of a sequential or partitioned data set.
IEBUPDTE	Incorporate changes to sequential or partitioned data sets, or PDSEs.

4.2 DFSMSdfp access methods

An access method is a friendly program interface between programs and their data. It is in charge of interfacing with Input/Output Supervisor (IOS), the z/OS code that starts the I/O operation. An access method makes the physical organization of data transparent to you by using these techniques:

•Managing data buffers

•Blocking and deblocking logical records into physical blocks

•Synchronizing your task and the I/O operation (wait/post mechanism)

•Writing the channel program

•Optimizing the performance characteristics of the control unit (such as caching and data striping)

•Compressing and decompressing I/O data

•Running software error recovery

In contrast to other platforms, z/OS supports several types of access methods and data organizations.

An access method defines the organization by which the data is stored and retrieved. DFSMS access methods have their own data set structures for organizing data, macros, and utilities to define and process data sets. It is an application choice, depending on the type of access (sequential or random), to allow or disallow insertions and deletions, to pick up the most adequate access method for its data.

Access methods are identified primarily by the data set organization to which they apply. For example, you can use the basic sequential access method (BSAM) with sequential data sets. However, there are times when an access method identified with one data organization type can be used to process a data set organized in a different manner. For example, a sequential data set (not an extended format data set) created by using BSAM can be processed by the basic direct access method (BDAM), and vice versa.

4.2.1 Basic sequential access method

BSAM arranges logical records sequentially in the order in which they are entered. A data set that has this organization is a sequential data set. Blocking, deblocking and the I/O synchronization is done by the application program. This is basic access. You can use BSAM with the following data types:

•Sequential data sets

•Extended-format data sets

•z/OS UNIX files

4.2.2 Basic direct access method

BDAM arranges records in any sequence that your program indicates, and retrieves records by actual or relative address. If you do not know the exact location of a record, you can specify a point in the data set to begin a search for the record. Data sets organized this way are called direct data sets.

Optionally, BDAM uses hardware keys. Hardware keys are less efficient than the optional software keys in VSAM KSDS.

Note: Because BDAM tends to require the use of device-dependent code, it is not a recommended access method. In addition, using keys is much less efficient than in VSAM. BDAM is supported by DFSMS only to enable compatibility with other IBM operating systems.

4.2.3 Basic partitioned access method

Basic partitioned access method (BPAM) arranges records as members of a PDS or a PDSE on DASD. You can use BPAM to view a UNIX directory and its files as though it were a PDS. You can view each PDS, PDSE, or UNIX member sequentially with BSAM or QSAM. A PDS or PDSE includes a directory that relates member names to locations within the data set. Use the PDS, PDSE, or UNIX directory to retrieve individual members.

A member is a sequential file that is contained in the PDS or PDSE data set. When members contain load modules (executable code in PDS) or program objects (executable code in PDSE), the directory contains program attributes that are required to load and rebind the member. Although UNIX files can contain program objects, program management does not access UNIX files through BPAM.

4.2.4 Queued sequential access method (QSAM)

QSAM arranges logical records sequentially in the order that they are entered to form sequential data sets, which are the same as those data sets that BSAM creates. The system organizes records with other records. QSAM anticipates the need for records based on their order. To improve performance, QSAM reads these records into main storage before they are requested. This is called queued access. QSAM blocks and deblocks logical records into physical blocks. QSAM also ensures the synchronization between the task and the I/O operation.

You can use QSAM with the following data types:

•Sequential data sets

•Basic format sequential data sets

•Large format sequential data sets

•Extended-format data sets

•z/OS UNIX files

4.2.5 Object access method

Object access method (OAM) processes very large named byte streams (objects) that have no record boundary or other internal orientation as image data. These objects can be recorded in a DB2 database or on an optical storage volume. For information about OAM, see z/OS DFSMS Object Access Method Application Programmer’s Reference, SC35-0425, and z/OS DFSMS Object Access Method Planning, Installation, and Storage Administration Guide for Object Support, SC35-0426.

4.2.6 Virtual Storage Access Method

Virtual Storage Access Method (VSAM) is an access method that has several ways of organizing data, depending on the application’s needs.

VSAM arranges and retrieves logical records by an index key, relative record number, or relative byte addressing (RBA). A logical record has an RBA, which is the relative byte address of its first byte in relation to the beginning of the data set. VSAM is used for direct, sequential, or skip sequential processing of fixed-length and variable-length records on DASD. VSAM data sets (also named clusters) are always cataloged. There are five types of cluster organization:

•Entry-sequenced data set (ESDS)

This data set contains records in the order in which they were entered. Records are added to the end of the data set and can be accessed sequentially or randomly through the RBA.

•Key-sequenced data set (KSDS)

This data set contains records in ascending collating sequence of the contents of a logical record field called key. Records can be accessed by using the contents of the key, or by an RBA.

•Linear data set (LDS)

This data set contains data that has no record boundaries. Linear data sets contain none of the control information that other VSAM data sets do. Data in Virtual (DIV) is an optional intelligent buffering technique that includes a set of assembler macros that provide buffering access to VSAM linear data sets. For more information about DIV, see 4.4.13, “VSAM: Data-in-virtual” on page 57.

•Relative record data set (RRDS)

This data set contains logical records in relative record number order. The records can be accessed sequentially or randomly based on this number. There are two types of relative record data sets:

– Fixed-length RRDS: Logical records must be of fixed length.

– Variable-length RRDS: Logical records can vary in length.

A z/OS UNIX file (HFS or zFS) can be accessed as though it were a VSAM ESDS. Although UNIX files are not actually stored as entry-sequenced data sets, the system attempts to simulate the characteristics of such a data set. To identify or access a UNIX file, specify the path that leads to it.

4.3 Access method services (IDCAMS)

You can use the access method services utility (also know as IDCAMS) to establish and maintain catalogs and data sets (VSAM and non-VSAM). It is used mainly to create and manipulate VSAM data sets. IDCAMS has other functions (such as catalog updates), but it is most closely associated with the use of VSAM.

4.3.1 Access method services commands

There are two types of access method services commands:

Functional commands Used to request the actual work (for example, defining a data set or listing a catalog)

Modal commands Allow the conditional execution of functional commands (to make it look like a language)

All access method services commands have the following general structure:

COMMAND parameters ... [terminator]

The command defines the type of service requested, the parameters further describe the service requested, and the terminator indicates the end of the command statement.

Time Sharing Option (TSO) users can use functional commands only. For more information about modal commands, refer to z/OS DFSMS Access Method Services for Catalogs, SC26-7394.

The automatic class selection (ACS) routines (established by your storage administrator) and the associated SMS classes eliminate the need to use many access method services command parameters. The SMS environment is discussed in more detail in Chapter 5, “System-managed storage” on page 79.

4.3.2 Starting the IDCAMS utility program

When you want to use an access method services function, enter a command and specify its parameters. Your request is decoded one command at a time. The appropriate functional routines perform all services that are required by that command.

You can call the access method services program in the following ways:

•As a job or jobstep

•From a TSO session

•From within your own program

TSO users can run access method services functional commands from a TSO session as though they were TSO commands.

For more information, refer to “Invoking Access Method Services from Your Program” in z/OS DFSMS Access Method Services for Catalogs, SC26-7394.

As a job or jobstep

You can use JCL statements to call access method services. PGM=IDCAMS identifies the access method services program, as shown in Figure 4-1.

//YOURJOB JOB YOUR INSTALLATION'S JOB=ACCOUNTING DATA
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=A
//SYSIN DD *

access method services commands and their parameters

/*

Figure 4-1 JCL statements to call IDCAMS

From a TSO session

You can use TSO with VSAM and access method services to:

•Run access method services commands

•Run a program to call access method services

Each time that you enter an access method services command as a TSO command, TSO builds the appropriate interface information and calls access method services. You can enter one command at a time. The access method services processes the command completely before TSO lets you continue processing.

To use IDCAMS and certain of its parameters from TSO/E, you must update the IKJTSOxx member of SYS1.PARMLIB. Add IDCAMS to the list of authorized programs (AUTHPGM). For more information, see z/OS DFSMS Access Method Services for Catalogs, SC26-7394.

From within your own program

You can also call the IDCAMS program from within another program and pass the command and its parameters to the IDCAMS program.

4.3.3 IDCAMS functional commands

This section describes the IDCAMS functional commands and their respective functions. Table 4-3 lists and describes the functional commands. For more information about each command, a detailed description, usage, and syntax, see z/OS DFSMS Access Method Services Commands, SC23-6846.

Table 4-3 Functional commands

Command	Functions
ALLOCATE	Allocates VSAM and non-VSAM data sets.
ALTER	Alters attributes of data sets, catalogs, tape library entries, and tape volume entries that have already been defined.
BLDINDEX	Builds alternate indexes for existing VSAM base clusters.
CREATE	Creates tape library entries and tape volume entries.
DCOLLECT	Collects data set, volume usage, and migration utility information.
DEFINE ALIAS	Defines an alternate name for a user catalog or a non-VSAM data set.
DEFINE ALTERNATEINDEX	Defines an alternate index for a KSDS or ESDS VSAM data set.
DEFINE CLUSTER	Creates KSDS, ESDS, RRDS, VRRDS, and linear VSAM data sets.
DEFINE GENERATIONDATAGROUP	Defines a catalog entry for a generation data group (GDG).
DEFINE NONVSAM	Defines a catalog entry for a non-VSAM data set.
DEFINE PAGESPACE	Defines an entry for a page space data set.
DEFINE PATH	Defines a path directly over a base cluster or over an alternate index and its related base cluster.
DEFINE USERCATALOG	Defines a user catalog.
DELETE	Deletes catalogs, VSAM clusters, and non-VSAM data sets.
DIAGNOSE	Scans an integrated catalog facility BCS or a VVDS to validate the data structures and detect structure errors.
EXAMINE	Analyzes and reports the structural consistency of either an index or data component of a KSDS VSAM data set cluster.
EXPORT	Disconnects user catalogs, and exports VSAM clusters and ICF catalog information about the cluster.
EXPORT DISCONNECT	Disconnects a user catalog.
IMPORT	Connects user catalogs, and imports VSAM cluster and its integrated catalog facility (ICF) catalogs information.
IMPORT CONNECT	Connects a user catalog or a volume catalog.
LISTCAT	Lists catalog entries.
PRINT	Used to print VSAM data sets, non-VSAM data sets, and catalogs.
REPRO	Performs the following functions: •Copies VSAM and non-VSAM data sets, user catalogs, master catalogs, and volume catalogs. •Splits ICF catalog entries between two catalogs. •Merges ICF catalog entries into another ICF user or master catalog. •Merges tape library catalog entries from one volume catalog into another volume catalog.
SHCDS	Lists SMSVSAM recovery associated with subsystems spheres and controls that allow recovery of a VSAM RLS environment.
VERIFY	Causes a catalog to correctly reflect the end of a data set after an error occurred while closing a VSAM data set. The error might have caused the catalog to be incorrect.

4.3.4 AMS modal commands

With access method services (AMS), you can set up jobs to run a sequence of modal commands with a single invocation of IDCAMS. Modal command execution depends on the success or failure of prior commands.

Using modal commands

With access method services, you can set up jobs to run a sequence of modal commands with a single invocation of IDCAMS. Modal command execution depends on the success or failure of prior commands. The access method services modal commands are used for the conditional execution of functional commands. The following commands are available:

•The IF-THEN-ELSE command sequence controls command execution based on condition codes.

•The NULL command causes the program to take no action.

•The DO-END command sequence specifies more than one functional access method services command and its parameters.

•The SET command resets condition codes.

•The CANCEL command ends processing of the current job step.

•The PARM command chooses diagnostic aids and options for printed output.

Note: These commands cannot be used when access method services are run in TSO. See z/OS DFSMS Access Method Services for Catalogs, SC26-7394, for a complete description of the AMS modal commands.

Commonly used single job step command sequences

A sequence of commands commonly used in a single job step includes EXPORT-DELETE-DEFINE-IMPORT or DELETE-DEFINE-BLDINDEX, as follows:

•You can specify either a data definition (DD) name or a data set name with these commands.

•When you refer to a DD name, allocation occurs at job step initiation. The allocation can result in a job failure if a command such as IMPORT follows a EXPORT-DELETE-DEFINE sequence that changes the location (volser) of the data set. Such failures can occur with either SMS-managed data sets or non-SMS-managed data sets.

Avoiding potential command sequence failures

To avoid potential failures with a modal command sequence in your IDCAMS job, perform either one of the following tasks:

•Specify the data set name instead of the DD name.

•Use a separate job step to perform any sequence of commands (for example, REPRO, IMPORT, BLDINDEX, PRINT, or EXAMINE) that follow a DEFINE command.

4.3.5 DFSMS Data Collection Facility (DCOLLECT)

The DFSMS Data Collection Facility (DCOLLECT) is a function of access method services. DCOLLECT collects data in a sequential file that you can use as input to other programs or applications.

The IDCAMS DCOLLECT command collects DASD performance and space occupancy data in a sequential file that you can use as input to other programs or applications.

An installation can use this command to collect information about these items:

•Active data sets: DCOLLECT provides data about space use and data set attributes and indicators on the selected volumes and storage groups.

•VSAM data set information: DCOLLECT provides specific information related to VSAM data sets that are on the selected volumes and storage groups.

•Volumes: DCOLLECT provides statistics and information about volumes that are selected for collection.

•Inactive data: DCOLLECT produces output for DFSMShsm-managed data (inactive data management), which includes both migrated and backed up data sets:

– Migrated data sets: DCOLLECT provides information about space utilization and data set attributes for data sets migrated by DFSMShsm.

– Backed up data sets: DCOLLECT provides information about space utilization and data set attributes for every version of a data set backed up by DFSMShsm.

•Capacity planning: Capacity planning for DFSMShsm-managed data (inactive data management) includes the collection of both DASD and tape capacity planning:

– DASD Capacity Planning: DCOLLECT provides information and statistics for volumes managed by DFSMShsm (ML0 and ML1).

– Tape Capacity Planning: DCOLLECT provides statistics for tapes managed by DFSMShsm.

•SMS configuration information: DCOLLECT provides information about the SMS configurations. The information can be from either an active control data set (ACDS) or a source control data set (SCDS), or the active configuration.

Data is gathered from the VTOC, VVDS, and DFSMShsm control data sets for both managed and non-managed storage. ISMF provides the option to build the JCL necessary to run DCOLLECT.

With the sample JCL shown in Figure 4-2 you can gather information about all volumes belonging to the storage group STGGP001.

Figure 4-2 DCOLLECT job to collect information about all volumes in on storage group

Many clients run DCOLLECT on a time-driven basis triggered by automation. In such a scenario, the peak hours should be avoided due to the heavy access rate caused by DCOLLECT in VTOC and catalogs.

4.3.6 Generation data group

GDG is a catalog function that makes it easier to process data sets with the same type of data but in different update levels. For example, the same data set is produced every day, but with different data. You can then catalog successive updates or generations of these related data sets. Each data set within a GDG is called a generation data set (GDS) or generation.

Within a GDG, the generations can have like or unlike DCB attributes and data set organizations. If the attributes and organizations of all generations in a group are identical, the generations can be retrieved together as a single data set.

Generation data sets can be sequential, PDSs, PDSEs, or direct (BDAM). Generation data sets cannot be UNIX files or VSAM data sets. The same GDG can contain SMS and non-SMS data sets.

There are usability benefits to grouping related data sets using a function such as GDS. For example, the catalog management routines can refer to the information in a special index called a generation index in the catalog, which provides these benefits:

•All data sets in the group can be referred to by a common name.

•z/OS is able to keep the generations in chronological order.

•Outdated or obsolete generations can be automatically deleted from the catalog by z/OS.

Another benefit is the ability to reference a new generation using the same JCL.

A GDG base is allocated in a catalog before the GDSs are cataloged. Each GDG is represented by a GDG base entry. Use the access method services DEFINE command to allocate the GDG base.

The GDG base is a construct that exists only in a user catalog, it does not exist as a data set on any volume. The GDG base is used to maintain the GDS, which are the real data sets.

The number of GDSs in a GDG depends on the limit you specify when you create a new GDG in the catalog. The maximum number of generations available is 255 for regular, before z/OS 2.2, or 999 for extended GDGs on z/OS 2.2 and later releases.

A GDS has sequentially ordered absolute and relative names that represent its age. The catalog management routines use the absolute generation name in the catalog. The relative name is a signed integer used to refer to the most current (0), the next to most current (-1), and so forth, generation.

Absolute generation and version numbers

An absolute generation and version number is used to identify a specific generation of a GDG. The same GDS can have different versions, which are maintained by your installation. The version number allows you to perform normal data set operations without disrupting the management of the generation data group. For example, if you want to update the second generation in a three-generation group, then replace generation 2, version 0, with generation 2, version 1. Only one version is kept under GDG control for each generation.

The generation and version number are in the form GxxxxVyy, where xxxx is an unsigned four-digit decimal generation number (0001 - 9999) and yy is an unsigned two-digit decimal version number (00 - 99). For example:

•A.B.C.G0001V00 is generation data set 1, version 0, in generation data group A.B.C.

•A.B.C.G0009V01 is generation data set 9, version 1, in generation data group A.B.C.

The number of generations and versions is limited by the number of digits in the absolute generation name, there can be a maximum of 9,999 generations. Each generation can have up to 100 versions. The system automatically maintains the generation number.

You can catalog a generation by using either absolute or relative numbers. When a generation is cataloged, a generation and version number is placed as a low-level entry in the generation data group. To catalog a version number other than V00, you must use an absolute generation and version number.

Relative generation numbers

As an alternative to using absolute generation and version numbers when cataloging or referring to a generation, you can use a relative generation number. To specify a relative number, use the generation data group name followed by a negative integer, a positive integer, or a zero (0), enclosed in parentheses, such as A.B.C(-1), A.B.C(+1), or A.B.C(0).

The value of the specified integer tells the operating system what generation number to assign to a new generation data set, or it tells the system the location of an entry representing a previously cataloged old generation data set.

When you use a relative generation number to catalog a generation, the operating system assigns an absolute generation number and a version number of V00 to represent that generation. The absolute generation number assigned depends on the number last assigned and the value of the relative generation number that you are now specifying. For example, if in a previous job generation, A.B.C.G0006V00 was the last generation cataloged, and you specify A.B.C(+1), the generation now cataloged is assigned the number G0007V00.

Though any positive relative generation number can be used, a number greater than 1 can cause absolute generation numbers to be skipped for a new generation data set. For example, if you have a single step job and the generation being cataloged is a +2, one generation number is skipped. However, in a multiple step job, one step might have a +1 and a second step a +2, in which case no numbers are skipped. The mapping between relative and absolute numbers is kept until the end of the job.

GDG example

In the example in Figure 4-3, the limit is 5. That means the GDG can hold a maximum of five GDSs. The data set name is ABC.GDG. You can then access the GDSs by their relative names. For example, ABC.GDG(0) corresponds to the absolute name ABC.GDG.G0005V00. ABC.GDG(-1) corresponds to generation ABC.GDG.G0004V00, and so on. The relative number can also be used to catalog a new generation (+1), which will be generation number 6 with an absolute name of ABC.GDG.G0006V00. Because the limit is 5, the oldest generation (G0001V00) is rolled-off if you define a new one.

Figure 4-3 Sample GDG structure

Extended GDG

The extended attribute allows system programmers to extend the maximum number of active generations within the GDG base from 255 to 999. This increase provides better flexibility to keep all required versions under GDG control, and reduce the requirement of NOSCRATCH GDGs in your systems. For more information about extended GDGs, see IBM z/OS V2R2: Storage Management and Utilities, SG24-8289.

GDG processing order

There are times where you will need to process all GDS files at once. You can achieve that by providing only the GDG base name in your JCL. During the GDG definition, you can also decide how the system performs bulk processing. If you do not specify any reading order, or select FIFO, the data sets are stacked for read in the order they were created. If LIFO was used during GDG definition, the system reverses the order of stacking, going from the newest to the oldest data set.

Rolled in and rolled off

When a GDG contains its maximum number of active generation data sets in the catalog, which is defined in the LIMIT parameter, and a new GDS is rolled in at the end-of-job step, the oldest generation data set is rolled off from the catalog. If a GDG is defined that use DEFINE GENERATIONDATAGROUP EMPTY and is at its limit, then when a new GDS is rolled in, all the currently active GDSs are rolled off.

The parameters that you specify on the DEFINE GENERATIONDATAGROUP IDCAMS command determine what happens to rolled-off GDSs. For example, if you specify the SCRATCH parameter, the GDS is scratched from VTOC when it is rolled off. If you specify the NOSCRATCH parameter, the rolled-off generation data set is recataloged as rolled off and is disassociated with its generation data group.

Creating GDGs with the NOSCRATCH parameter can result in generation overlap if rolled off versions are not deleted/renamed before the GDG version reaches 9999 and the counter is reset to 0001. If version 0001 still exists, a “duplicate data set name” error is issued when an attempt is made to catalog the new GDS.

GDSs can be in a deferred roll-in state if the job never reached end-of-step or if they were allocated as DISP=(NEW,KEEP) and the data set is not system-managed. However, GDSs in a deferred roll-in state can be referred to by their absolute generation numbers. You can use the IDCAMS command ALTER ROLLIN to roll in these GDSs.

For more information about generation data groups, see z/OS DFSMS: Using Data Sets, SC26-7410.

4.4 Virtual Storage Access Method

VSAM is a DFSMSdfp component that is used to organize data and maintain information about the data in a catalog. VSAM arranges records by an index key, relative record number, or relative byte addressing. VSAM is used for direct or sequential processing of fixed-length and variable-length records on DASD. Data that is organized by VSAM is cataloged for easy retrieval and is stored in one of five types of data sets.

There are two major parts of VSAM:

•Catalog management: The catalog contains information about the data sets.

•Record management: VSAM can be used to organize records into five types of data sets, that is, the VSAM access method function:

– Key-sequenced data sets (KSDSs) contain records in ascending collating sequence. Records can be accessed by a field, called a key, or by a relative byte address.

– Entry-sequenced data sets (ESDSs) contain records in the order in which they were entered. Records are added to the end of the data set.

– Linear data sets (LDSs) contain data that has no record boundaries. Linear data sets contain none of the control information that other VSAM data sets do. Linear data sets must be cataloged in a catalog.

– Relative record data sets (RRDSs) contain records in relative record number order, and the records can be accessed only by this number. There are two types of relative record data sets:

• Fixed-length RRDS: The records must be of fixed length.

• Variable-length RRDS (VRRDS): The records can vary in length.

Several components compose VSAM data sets. Each component plays a unique role in VSAM processing. They are briefly described in the next sections. For a more in-depth description of VSAM processing, see VSAM Demystified, SG24-6105.

4.4.1 Logical record

A logical record is a unit of application information used to store data in a VSAM cluster. The logical record is designed by the application programmer from the business model. The application program, through a GET, requests that a specific logical record be moved from the I/O device to memory in order to be processed. Through a PUT, the specific logical record is moved from memory to an I/O device. A logical record can be of a fixed size or a variable size, depending on the business requirements.

The logical record is divided into fields by the application program, such as the name of the item, code, and so on. One or more contiguous fields can be defined as a key field to VSAM, and a specific logical record can be retrieved directly by its key value.

Logical records of VSAM data sets are stored differently from logical records in non-VSAM data sets.

4.4.2 Physical record

A physical record is device-dependent and is a set of logical records moved during an I/O operation by just one Transport Control Word (TCW) Read or Write. VSAM calculates the physical record size to optimize the track space (to avoid many gaps) at the time the data set is defined. All physical records in VSAM have the same length. A physical record is also referred to as a physical block or simply a block. VSAM can have control information along with logical records in a physical record.

4.4.3 Control interval

The control interval (CI) is a concept that is unique to VSAM. A CI is formed by one or several physical records (usually just one). It is the fundamental building block of every VSAM file. A CI is a contiguous area of direct-access storage that VSAM uses to store data records and control information that describes the records. A CI is the unit of information that VSAM transfers between the storage device and the main storage during one I/O operation.

Whenever a logical record is requested by an application program, the entire CI containing the logical record is read into a VSAM I/O buffer in virtual storage. The specified logical record is then transferred from the VSAM buffer to a user-defined buffer or work area (if in move mode).

Based on the CI size, VSAM calculates the best size of the physical block to better use the 3390/3380 logical track. The CI size can be from 512 bytes to 32 KB. A CI contents depends on the cluster organization.

The size of CIs can vary from one component to another, but all the CIs within the data or index component of a particular cluster data set must be of the same length. The CI components and properties can vary, depending on the data set organization. For example, an LDS does not contain CIDFs and RDFs in its CI. All of the bytes in the LDS CI are data bytes.

4.4.4 Control area

Control area (CA) is also a concept unique to VSAM. A CA is formed by two or more CIs put together into fixed-length contiguous areas of direct-access storage. A VSAM data set is composed of one or more CAs. In most cases, a CA is the size of a 3390/3380 cylinder. The minimum size of a CA is one track. The CA size is implicitly defined when you specify the size of a data set at data set definition.

CAs are needed to implement the concept of splits. The size of a VSAM file is always a multiple of the CA size, and VSAM files are extended in units of CAs.

4.4.5 Component

A component in systems with VSAM is a named, cataloged collection of stored records, such as the data component or index component of a key-sequenced file or alternate index. A component is a set of CAs. It is the VSAM terminology for a z/OS data set. A component has an entry in the VTOC. An example of a component can be the data set containing only data for a KSDS VSAM organization. A VSAM can have up to two components: Data and Index.

Data component

The data component is the part of a VSAM cluster, alternate index, or catalog that contains the data records. All VSAM cluster organizations have the data component.

Index component

The index component is a collection of records containing data keys and pointers (RBA). The data keys are taken from a fixed defined field in each data logical record. The keys in the index logical records are compressed (rear and front). The RBA pointers are compacted. Only KSDS and VRRDS VSAM data set organizations have the index component.

Using the index, VSAM is able to retrieve a logical record from the data component when a request is made randomly for a record with a certain key. A VSAM index can consist of more than one level (binary tree). Each level contains pointers to the next lower level. Because there are random and sequential types of access, VSAM divides the index component into two parts: The sequence set and the index set.

4.4.6 Cluster

A cluster is a named structure that consists of a group of related components. VSAM data sets can be defined with either the DEFINE CLUSTER command or the ALLOCATE command. The cluster is a set of components that have a logical binding between them. For example, a KSDS cluster is composed of the data component and the index component.

TThe concept of cluster was introduced to improve the flexibility of JCL while accessing VSAM datasets. If you want to access a KSDS normally, just use the cluster’s name on a DD card. Otherwise, if you want special processing with just the data, use the data component name on the DD card.

4.4.7 Sphere

A sphere is a VSAM cluster and its associated data sets. The cluster is originally defined with the access method services ALLOCATE command, the DEFINE CLUSTER command, or through JCL. The most common use of the sphere is to open a single cluster. The base of the sphere is the cluster itself.

4.4.8 Other VSAM terminologies

Besides the components described previously, this section covers a few terminologies that are related to VSAM data sets that system programmers need to be familiar with.

Spanned records

Spanned records are logical records that are larger than the CI size. They are needed when the application requires very long logical records. To have spanned records, the file must be defined with the SPANNED attribute at the time it is created. Spanned records are allowed to extend across or “span” control interval boundaries, but not beyond control area limits. The RDFs describe whether the record is spanned or not.

A spanned record always begins on a control interval boundary, and fills one or more control intervals within a single control area. A spanned record does not share the CI with any other records, so the free space at the end of the last segment is not filled with the next record. This free space is only used to extend the spanned record.

Splits

CI splits and CA splits occur as a result of data record insertions (or increasing the length of an existing record) in KSDS and VRRDS organizations. If a logical record is to be inserted (in key sequence) and there is not enough free space in the CI, the CI is split. Approximately half the records in the CI are transferred to a free CI provided in the CA, and the record to be inserted is placed in the original CI.

If there are no free CIs in the CA and a record is to be inserted, a CA split occurs. Half the CIs are sent to the first available CA at the end of the data component. This movement creates free CIs in the original CA, and the record to be inserted causes a CI split.

Sequence set

The sequence set is the lowest level of index. It directly points (through an RBA) to the data CI in the CA of the data component. Each index logical record has these functions:

•Maps one CI in the data component

•Contains pointers and high key information for the data CI

Each index CI has these functions:

•Maps one data CA.

•Contains horizontal pointers from one sequence set CI to the next keyed sequence set CI. These horizontal pointers are needed because of the possibility of splits, which make the physical sequence different from the logical collating sequence by key.

Index set

The records in all levels of the index above the sequence set are called the index set. An entry in an index set logical record consists of the highest possible key in an index record in the next lower level, and a pointer to the beginning of that index record. The highest level of the index always contains a single index CI.

The structure of VSAM prime indexes is built to create a single index record at the lowest level of the index. If there is more than one sequence-set-level record, VSAM automatically builds another index level.

Figure 4-4 shows a view of the VSAM data set concepts mentioned.

Figure 4-4 VSAM data set components

Alternate index

The alternate index is a VSAM function that allows logical records of a KSDS or ESDS to be accessed sequentially and directly by more than one key field. The cluster that has the data is called the base cluster. An alternate index cluster is then built from the base cluster. Alternate indexes eliminate the need to store the same data in different sequences in multiple data sets for the purposes of various applications. Each alternate index is a KSDS cluster that consists of an index component and a data component.

The records in the alternate index index component contain the alternate key and the RBA pointing to the alternate index data component. The records in the alternate index data component contain the alternate key value itself and all the primary keys corresponding to the alternate key value (pointers to data in the base cluster). The primary keys in the logical record are in ascending sequence within an alternate index value.

Any field in the base cluster record can be used as an alternate key. It can also overlap the primary key (in a KSDS), or any other alternate key. The same base cluster can have several alternate indexes that vary the alternate key. There can be more than one primary key value per the same alternate key value. For example, the primary key might be an employee number and the alternate key might be the department name. Obviously, the same department name can have several employee numbers.

Alternate index cluster is created with the IDCAMS DEFINE ALTERNATEINDEX command. It is then populated with the BLDINDEX command. Before a base cluster can be accessed through an alternate index, a path must be defined. A path provides a way to gain access to the base data through a specific alternate index. To define a path, use the DEFINE PATH command.

SHAREOPTIONS (crossregion,crosssystem)

The cross-region share options specify the amount of sharing allowed among regions within the same system or multiple systems. Cross-system share options specify how the data set is shared among systems. Use global resource serialization (GRS) or a similar product to perform the serialization.

SHAREOPTIONS (1,x)

The data set can be shared by any number of users for read access (open for input), or it can be accessed by only one user for read/write access (open for output). If the data set is open for output by one user, a read or read/write request by another user will fail. With this option, VSAM ensures complete data integrity for the data set. When the data set is already open for RLS processing, any request to open the data set for non-RLS access will fail.

SHAREOPTIONS (2,x)

The data set can be shared by one user for read/write access, and by any number of users for read access. If the data set is open for output by one user, another open for output request will fail, but a request for read access will succeed. With this option, VSAM ensures write integrity. If the data set is open for RLS processing, non-RLS access for read is allowed. VSAM provides full read and write integrity for its RLS users, but no read integrity for non-RLS access.

SHAREOPTIONS (3,x)

The data set can be opened by any number of users for read and write request. VSAM does not ensure any data integrity. It is the responsibility of the users to maintain data integrity by using enqueue and dequeue macros. This setting does not allow any type of non-RLS access while the data set is open for RLS processing.

SHAREOPTIONS (4,x)

The data set can be fully shared by any number of users. For each request, VSAM refreshes the buffers used for direct processing. This setting does not allow any non-RLS access when the data set is already open for VSAM RLS or DFSMStvs processing. If the data set is opened in non-RLS mode, a VSAM RLS or DFSMStvs open is allowed. As in SHAREOPTIONS 3, each user is responsible for maintaining both read and write integrity for the data that the program accesses.

For more information about VSAM share options, see z/OS DFSMS: Using Data Sets, SC26-7410.

4.4.9 Typical KSDS processing

A KSDS has an index that relates key values to the relative locations in the data set. This index is called the prime index. It has two uses:

•Locate the collating position when inserting records

•Locate records for retrieval

When initially loading a KSDS data set, records must be presented to VSAM in key sequence. This loading can be done through the IDCAMS VSAM utility named REPRO. The index for a key-sequenced data set is built automatically by VSAM as the data set is loaded with records.

When a data CI is completely loaded with logical records, free space, and control information, VSAM makes an entry in the index. The entry consists of the highest possible key in the data control interval and a pointer to the beginning of that control interval.

When accessing records sequentially, VSAM refers only to the sequence set. It uses a horizontal pointer to get from one sequence set record to the next record in collating sequence.

Request for data direct access

When accessing records directly, VSAM follows vertical pointers from the highest level of the index down to the sequence set to find vertical pointers to the requested logical record. Figure 4-5 shows how VSAM searches the index when an application issues a GET for a logical record with key value 23.

The following is the sequence:

1. VSAM scans the index record in the highest level of the index set for a key that is greater or equal to 23.

2. The entry 67 points to an index record in the next lower level. In this index record, VSAM scans for an entry for a key that is higher than or equal to 23.

3. The entry 38 points to the sequence set that maps the CA holding the CI containing the logical record.

4. VSAM scans the sequence set record with the highest key, searching for a key that is greater than or equal to 23.

5. The entry 26 points to the data component CI that holds the record that you want.

6. VSAM reads the storage device, and loads the CI containing the information into VSAM buffers. Then, it searches the CI for the record with key 23. VSAM finds the logical record and gives it to the application program.

If VSAM does not find a record with the key that you want, the application receives a return code indicating that the record was not found.

Figure 4-5 Processing an indexed VSAM cluster: Direct access

For more detailed information about VSAM KSDS processing, see VSAM Demystified, SG24-6105.

4.4.10 Typical ESDS processing

For an ESDS, two types of processing are supported:

•Sequential access (the most common).

•Direct (or random) access requires the program to give the RBA of the record.

Skip sequential is not allowed.

Existing records can never be deleted. If the application wants to delete a record, it must flag that record as inactive. As far as VSAM is concerned, the record is not deleted. Records can be updated, but without length change.

ESDS organization is suited for sequential processing with variable records, but in a few read accesses you need a direct (random) access by key (here using the alternate index cluster).

Figure 4-6 shows a sample structure of VSAM ESDS data sets.

Figure 4-6 Typical ESDS processing (ESDS)

For more information about ESDS processing, see VSAM Demystified, SG24-6105.

4.4.11 Typical RRDS processing

The application program inputs the relative record number of the target record. VSAM is able to find its location quickly by using a formula that considers the geometry of the DASD device. The relative number is always used as a search argument. For an RRDS, three types of processing are supported:

•Sequential processing

•Skip-sequential processing

•Direct processing (in this case, the randomization routine is supported by the application program)

Figure 4-7 shows a typical processing of a VSAM fixed-length RRDS data set.

Figure 4-7 Typical RRDS processing

For extended information about RRDS processing, see VSAM Demystified, SG24-6105.

4.4.12 Typical LDS processing

A linear data set is a VSAM data set with a control interval size from 4096 bytes to 32768 bytes, in increments of 4096 bytes. An LDS has no embedded control information in its CI, that is, no record definition fields (RDFs) and no control interval definition fields (CIDFs).

Therefore, all LDS bytes are data bytes. Logical records must be blocked and deblocked by the application program (although logical records do not exist, from the point of view of VSAM).

IDCAMS is used to define a linear data set. An LDS has only a data component. An LDS data set is just a physical sequential VSAM data set that consists of 4 KB physical records, but with a revolutionary buffer technique called DIV. A linear data set is processed as an entry-sequenced data set, with certain restrictions.

Because a linear data set does not contain control information, it cannot be accessed as though it contained individual records. You can access a linear data set with the DIV macro. If using DIV to access the data set, the control interval size must be 4096, Otherwise, the data set will not be processed.

When a linear data set is accessed with the DIV macro, it is referred to as the data-in-virtual object or the data object.

Figure 4-8 shows a sample structure of a VSAM LDS data set.

Figure 4-8 Typical LDS data set

4.4.13 VSAM: Data-in-virtual

DIV is an optional and unique buffering technique that is used for LDS data sets. Application programs can use DIV to map a data set (or a portion of a data set) into an address space, a data space, or a hiperspace. An LDS cluster is sometimes referred to as a DIV object. After setting the environment, the LDS cluster looks to the application as a table in virtual storage with no need to issue I/O requests.

Data is read into main storage by the paging algorithms only when that block is actually referenced. During real storage manager (RSM) page-steal processing, only changed pages are written to the cluster in DASD. Unchanged pages are discarded because they can be retrieved again from the permanent data set.

DIV is designed to improve the performance of applications that process large files non-sequentially and process them with significant locality of reference. It reduces the number of I/O operations that are traditionally associated with data retrieval. Likely candidates are large arrays or table files.

For information about how to use data-in-virtual, see z/OS MVS Programming: Assembler Services Guide, SA22-7605.

4.4.14 VSAM resource pool

Buffering is one of the key aspects as far as I/O performance is concerned. A VSAM buffer is a virtual storage area where the CI is transferred during an I/O operation. VSAM KSDS uses two types of buffers: Buffers for data CIs and buffers for index CIs. A buffer pool is a set of buffers with the same size. A resource pool is a buffer pool with several control blocks describing the pool and describing the clusters with CIs in the resource pool.

The objective of a buffer pool is to avoid I/O operations in random accesses (due to revisiting data) and to make these I/O operations more efficient in sequential processing, improving performance.

For more efficient use of virtual storage, buffer pools can be shared among clusters using locally or globally shared buffer pools. There are four types of resource pool management, called modes, defined according to the technique used to manage them:

•Nonshared resources (NSR)

•Local shared resources (LSR)

•Global shared resources (GSR)

•Record-level shared resources (RLS)

These modes can be declared in the ACB macro of the VSAM data set (MACRF keyword) and are described in the following sections.

Non-shared resource

Non-shared resource (NSR) is the default VSAM buffering technique. The following are some of the characteristics of NSR buffers:

•The resource pool is implicitly constructed at data set open time.

•The buffers are not shared among VSAM data sets. Only one cluster has CIs in this resource pool.

•Buffers are located in the private area.

•For sequential reads, VSAM uses the read-ahead function. When the application finishes processing half the buffers, VSAM schedules an I/O operation for that half of the buffers.

This process continues until a CA boundary is encountered. The application must wait until the last I/O to the CA is done before proceeding to the next CA. The I/O operations are always scheduled within CA boundaries.

•For sequential writes, VSAM postpones the writes to DASD until half the buffers are filled by the application. Then VSAM schedules an I/O operation to write that half of the buffers to DASD. The I/O operations are always scheduled within CA boundaries.

•CIs are discarded as soon as they are used by using a sequential algorithm to keep CIs in the resource pool.

•There is dynamic addition of strings. Strings are like cursors. Each string represents a position in the data set for the requested record.

•For random access, there is no look-ahead, but the algorithm remains sequential.

NSR is used by high-level languages. Because buffers are managed by a sequential algorithm, NSR is not the best choice for random processing. For more details about NSR buffers, seeVSAM Demystified, SG24-6105.

Local shared resource

An LSR resource pool is suitable for random processing, not for sequential processing. LSR has the following characteristics:

•Shared among VSAM clusters accessed by tasks in the same address space.

•Located in the private area and expanded storage only (ESO) hiperspace. With hiperspace, VSAM buffers are located in expanded storage to improve the processing of VSAM clusters. With z/Architecture, ESO hiperspaces are mapped in main storage.

•A resource pool is explicitly constructed by macro BLDVRP before the OPEN.

•Buffers are managed by the last recently used (LRU) algorithm, so the most referenced CIs are kept in the resource pool. It is adequate for random processing.

•LSR expects that CIs in buffers are revisited.

For extra information about LSR, see VSAM Demystified, SG24-6105.

Global shared resource

GSR is similar to the LSR buffering technique. GSR differs from LSR in the following ways:

•The buffer pool is shared among VSAM data sets accessed by tasks in multiple address spaces in the same z/OS image.

•Buffers are located in CSA.

•The code using GSR must be in the supervisor state.

•Buffers cannot use hiperspace.

•The separate index resource pools are not supported for GSR.

GSR is not commonly used by applications, so consider using VSAM RLS instead. For extra information about LSR, see VSAM Demystified, SG24-6105.

Record-level sharing

RLS is the implementation of VSAM data sharing. Record-level sharing is discussed in detail in Chapter 7, “DFSMS Transactional VSAM Services” on page 119.

For more information about NSR, LSR, and GSR, see VSAM Demystified, SG24-6105.

4.4.15 VSAM: System-managed buffering

System-managed buffering (SMB) enables VSAM to perform these tasks:

•Determine the optimum number of index and data buffers

•Change the buffer algorithm as declared in the application program in the ACB MACRF parameter, from NSR (sequential) to LSR (LRU)

Usually, SMB allocates many more buffers than are allocated without SMB. Performance improvements can be dramatic with random access (particularly when few buffers were available). The use of SMB is transparent from the point of view of the application, so no application changes are needed.

SMB is available to a data set when all of the following conditions are met:

•It is an SMS-managed data set.

•It is in extended format (DSNTYPE = EXT in the data class).

•The application opens the data set for NSR processing.

SMB is started or disabled by using one of the following methods:

1. The Record Access Bias data class field.

2. The ACCBIAS subparameter of AMP in the JCL DD statement. JCL information takes precedence over data class information.

If all of the required conditions are met, SMB is started when option SYSTEM or an SMB processing technique is used in the fields described previously. SMB is disabled when USER is entered instead (USER is the default). Because JCL information takes precedence over data class information, installations can enable or disable SMB for some executions.

SMB uses formulas to calculate the storage and buffer numbers needed for a specific access type. SMB takes the following actions:

•It changes the defaults for processing VSAM data sets. This action enables the system to take better advantage of current and future hardware technology.

•It initiates a buffering technique to improve application performance. The technique is one that the application program does not specify. You can choose or specify any of the four processing techniques that SMB implements:

Direct Optimized (DO) The DO processing technique optimizes for totally random record access. This technique is appropriate for applications that access records in a data set in totally random order. This technique overrides the user specification for NSR buffering with an LSR implementation of buffering.

Sequential Optimized (SO) The SO technique optimizes processing for record access that is in sequential order. This technique is appropriate for backup and for applications that read the entire data set or a large percentage of the records in sequential order.

Direct Weighted (DW) This technique is optimal when most of the processing is direct, and some is sequential. DW processing provides the minimum read-ahead buffers for sequential retrieval and the maximum index buffers for direct requests.

Sequential Weighted (SW) This technique is optimal when most of the processing is sequential processing, and some is direct. This technique uses read-ahead buffers for sequential requests and provides additional index buffers for direct requests. The read-ahead will not be as large as the amount of data transferred with SO.

For more information about the use of SMB, see VSAM Demystified, SG24-6105.

4.5 Data set separation

Data set separation allows you to designate groups of data sets in which all SMS-managed data sets within a group are kept separate, on the physical control unit (PCU) level or the volume level, from all the other data sets in the same group.

When allocating new data sets or extending existing data sets to new volumes, SMS volume selection frequently calls SRM to select the best volumes. Unfortunately, SRM might select the same set of volumes that currently have the lowest I/O delay. Poor performance or single points of failure might occur when a set of functional-related critical data sets are allocated onto the same volumes. SMS provides a function to separate their critical data sets, such as DB2 partitions, onto different volumes to prevent DASD hot spots and reduce I/O contention.

The user defines the volume separation groups in a data set separation profile. During data set allocation, SMS attempts to separate data sets that are specified in the same separation group onto different extent pools and volumes.

This technique provides a facility for an installation to separate functional-related critical data sets onto different extent pools and volumes for better performance and to avoid single points of failure.

To use data set separation, you must create a data set separation profile and specify the name of the profile to the base configuration. During allocation, SMS attempts to separate the data sets listed in the profile.

A data set separation profile contains at least one data set separation group. Each data set separation group specifies whether separation is at the PCU or volume level, and whether it is required or preferred. It also includes a list of data set names to be separated from each other during allocation.

For details about data set separation implementation and syntax, see z/OS DFSMSdfp Storage Administration Reference, SC26-7402.

Important: Use data set separation only for a small set of mission-critical data.

4.6 Data Facility sort

The Data Facility sort (DFSORT) licensed program is a high-performance data arranger for z/OS users. Using DFSORT, you can sort, merge, and copy data sets using EBCDIC, UNICODE, z/Architecture decimal or binary keys. It also helps you to analyze data and produce detailed reports using the ICETOOL utility or the OUTFIL function. DFSORT is an optional feature of z/OS.

DFSORT, together with DFSMS and RACF, form the strategic product base for the evolving system-managed storage environment. DFSORT is designed to optimize the efficiency and speed with which operations are completed through synergy with processor, device, and system features (for example, memory objects, IBM Hiperspace™, data space, striping, compression, extended addressing, DASD and tape device architecture, processor memory, and processor cache).

You can use DFSORT to do simple application tasks such as alphabetizing a list of names, or you can use it to aid complex tasks such as taking inventory or running a billing system. You can also use the record-level editing capability of DFSORT to perform data management tasks.

For most of the processing done by DFSORT, the whole data set is affected. However, certain forms of DFSORT processing involve only certain individual records in that data set.

4.6.1 DFSORT functions

DFSORT adds the ability to do faster and easier sorting, merging, copying, reporting, and analysis of your business information, as well as versatile data handling at the record, fixed position/length or variable position/length field, and bit level.

While sorting, merging, or copying data sets, you can perform these tasks:

•Select a subset of records from an input data set. You can include or omit records that meet specified criteria. For example, when sorting an input data set containing records of course books from many different school departments, you can sort the books for only one department.

•Reformat records, add or delete fields, and insert blanks, constants, or binary zeros. For example, you can create an output data set that contains only certain fields from the input data set, arranged differently.

•Sum the values in selected records while sorting or merging (but not while copying). For the example of a data set containing records of course books, you can use DFSORT to add up the dollar amounts of books for one school department.

•Create multiple output data sets and reports from a single pass over an input data set. For example, you can create a different output data set for the records of each department.

•Sort, merge, include, or omit records according to the collating rules defined in a selected local.

•Alter the collating sequence when sorting or merging records (but not while copying). For example, you can have the lowercase letters collate after the uppercase letters.

•Sort, merge, or copy Japanese data if the IBM Double Byte Character Set Ordering Support (DBCS Ordering, the 5665-360 Licensed Program, Release 2.0, or an equivalent product) is used with DFSORT to process the records.

DFSORT has utilities such as ICETOOL, which is a multipurpose DFSORT utility that uses the capabilities of DFSORT to perform multiple operations on one or more data sets in a single step.

Tip: You can use the ICEGENER facility of DFSORT to achieve faster and more efficient processing for applications that are set up to use the IEBGENER system utility. For more information, see z/OS DFSORT Application Programming Guide, SC26-7523.

4.7 Data Set Services (DFSMSdss)

DFSMSdss is a DASD data and space management tool. DFSMSdss works on DASD volumes only in a z/OS environment. You can use DFSMSdss to perform the following tasks:

•Copy and move data sets between volumes of like and unlike device types.

•Dump and restore data sets, entire volumes, or specific tracks.

•Convert data sets and volumes to and from SMS management.

•Compress partitioned data sets.

•Release unused space in data sets.

•Reduce or eliminate DASD free-space fragmentation by consolidating free space on a volume.

•Implement concurrent copy or a FlashCopy in ESS or DS8000 DASD controllers.

You can use the DFSMSdss to back up, copy, dump, move, or restore data in your systems. DFSMSdss can be called by JCL or by external programs, such as DFSMShsm, to perform data movement. It also participates in disaster recovery solutions, by allowing the recovery of your systems from a stand-alone DFSMSdss restore function, or copy and replication services, such as GDPS solutions.

This section provides a high-level description of DFSMSdss basic functions, so no data replication services are covered here. For more information about DFSMSdss, capabilities, and copy services, see z/OS DFSMSdss Storage Administration, SC23-6868.

4.7.1 Physical and logical processing

Before you begin using DFSMSdss, you should understand the difference between logical processing and physical processing and how to use data set filtering to select data sets for processing. DFSMSdss can perform two kinds of processing when running COPY, DUMP, and RESTORE commands:

•Logical processing operates against data sets independently of physical device format.

•Physical processing moves data at the track-image level and operates against volumes, tracks, and data sets.

Each type of processing offers different capabilities and advantages.

During a restore operation, the data is processed the same way that it is dumped because physical and logical dump tapes have different formats. If a data set is dumped logically, it is restored logically, and if it is dumped physically, it is restored physically. A data set restore operation from a full volume dump is a physical data set restore operation.

Logical processing

A logical copy, dump, or restore operation treats each data set and its associated information as a logical entity, and processes an entire data set before beginning the next one.

Each data set is moved by tracks from the source device and is potentially written to the target device as a set of data records, allowing data movement between devices with different track and cylinder configurations. Checking of data record consistency is not performed during the dump operation.

DFSMSdss performs logical processing in these circumstances:

•You specify the DATASET keyword with the COPY command. A data set copy is always a logical operation, regardless of how or whether you specify input volumes.

•You specify the DATASET keyword with the DUMP command, and either no input volume is specified, or LOGINDDNAME, LOGINDYNAM, or STORGRP is used to specify input volumes.

•The RESTORE command is performed, and the input volume was created by a logical dump.

Catalogs and VTOCs are used to select data sets for logical processing. If you do not specify input volumes, the catalogs are used to select data sets for copy and dump operations. If you specify input volumes using the LOGINDDNAME, LOGINDYNAM, or STORGRP keywords on the COPY or DUMP command, DFSMSdss uses VTOCs to select data sets for processing.

When to use logical processing

Use logical processing for the following situations:

•Data is copied to an unlike device type.

Logical processing is the only way to move data between unlike device types.

•Data that might need to be restored to an unlike device is dumped.

This concern is particularly important to remember when making backups that you plan to retain for a long time (such as vital records backups).

If a backup is retained for a long time, the device type that it originally was on might no longer be in use at your site when you want to restore it. This situation means you must restore it to an unlike device, which can be done only if the backup has been made logically.

•Aliases of VSAM user catalogs are to be preserved during copy and restore functions.

Aliases are not preserved for physical processing.

•Unmovable data sets or data sets with absolute track allocation are moved to different locations.

•Multivolume data sets are processed.

•VSAM and multivolume data sets are to be cataloged as part of DFSMSdss processing.

•Data sets are to be deleted from the source volume after a successful dump or copy operation.

•Both non-VSAM and VSAM data sets are to be renamed after a successful copy or restore operation.

•You want to control the percentage of space allocated on each of the output volumes for copy and restore operations.

•You want to copy and convert a PDS to a PDSE or vice versa.

•You want to copy or restore a data set with an undefined DSORG to an unlike device.

•You want to keep together all parts of a VSAM sphere.

Physical processing

Physical processing moves data based on physical track images. Because data movement is carried out at the track level, only target devices with track sizes equal to those of the source device are supported. Physical processing operates on volumes, ranges of tracks, or data sets. For data sets, it relies only on volume information (in the VTOC and VVDS) for data set selection, and processes only that part of a data set residing on the specified input volumes.

DFSMSdss performs physical processing in these circumstances:

•You specify the FULL or TRACKS keyword with the COPY or DUMP command. This situation results in a physical volume or physical tracks operation.

Attention: Take care when using the TRACKS keyword with the COPY and RESTORE commands. The TRACKS keyword should be used only for a data recovery operation. For example, you can use it to “repair” a bad track in the VTOC or a data set, or to retrieve data from a damaged data set. You cannot use it in place of a full-volume or a logical data set operation. Doing so can destroy a volume or impair data integrity.

•You specify the data set keyword on the DUMP command and input volumes with the INDDNAME or INDYNAM parameter. This situation produces a physical data set dump.

•The RESTORE command is run and the input volume is created by a physical dump operation.

When to use physical processing

Use physical processing in these circumstances:

•Backing up system volumes that you might want to restore with a stand-alone DFSMSdss restore operation.

Stand-alone DFSMSdss restore supports only physical dump tapes.

•Performance is an issue.

Generally, the fastest way (measured by elapsed time) to copy or dump an entire volume is by using a physical full-volume command. This advantage is primarily because minimal catalog searching is necessary for physical processing.

•Substituting one physical volume for another or recovering an entire volume.

With a COPY or RESTORE (full volume or track) command, the volume serial number of the input DASD volume can be copied to the output DASD volume.

•Dealing with I/O errors.

Physical processing provides the capability to copy, dump, and restore a specific track or range of tracks.

•Dumping or copying between volumes of the same device type but different capacity.

4.7.2 DFSMSdss stand-alone services

The DFSMSdss stand-alone restore function is a single-purpose program. It is designed to allow the system programmer to restore vital system packs during disaster recovery without relying on an MVS environment. Stand-alone services can perform either a full-volume restore or a track restore from dump tapes produced by DFSMSdss or DFDSS.

For detailed information about the stand-alone service and other DFSMSdss information, see z/OS DFSMSdss Storage Administration Reference, SC35-0424, and z/OS DFSMSdss Storage Administration Guide, SC35-0423.

4.8 Hierarchical Storage Manager

Hierarchical Storage Manager (DFSMShsm) is a disk storage management and productivity product for managing low activity and inactive data. It provides backup, recovery, migration, and space management functions as well as full-function disaster recovery support. DFSMShsm improves disk use by automatically managing both space and data availability in a storage hierarchy.

Availability management is used to make data available by automatically copying new and changed data set to backup volumes.

Space management is used to manage DASD space by enabling inactive data sets to be moved off fast-access storage devices, thus creating free space or new allocations.

DFSMShsm also provides for other supporting functions that are essential to your installation's environment. For further information about DFSMShsm, see z/OS DFSMShsm Storage Administration Guide, SC35-0421 and z/OS DFSMShsm Storage Administration Reference, SC35-0422.

4.8.1 DFSMShsm data sets

DFSMShsm assists you in the space and availability tasks related to user and application data sets. It stores and maintains information about backups and migrated data sets under its control, based on the management policies defined in SMS Management Class (MC) construct and DFSMShsm parmlib.

To retrieve information in a timely matter of time, DFSMShsm uses control data sets (CDSs) that record data about data sets, tapes, and DASD volumes. These records are stored in different CDSs depending on the record content. There are four CDSs used by DFSMShsm, which are explained next:

•Backup control data set (BCDS)

The BCDS provides DFSMShsm with information defining the backup and dump environment. DFSMShsm needs this information to manage its backup data sets and volumes. DFSMShsm updates the contents of the BCDS with current backup version information.

•Migration control data set (MCDS)

The MCDS provides information about migrated data sets and the volumes they migrate to and from. Additionally, internal processing statistics and processing-unit-environment data are in the MCDS. DFSMShsm needs this information to manage its data sets and volumes. With this information you can verify, monitor, and tune your storage environment

•Offline control data set (OCDS)

The OCDS provides DFSMShsm with information about each migration and backup tape and about each data set on these tapes.

•Journal data set

The journal data set provides DFSMShsm with a record of each critical change made to a control data set from any host since the last time that CDS was successfully backed up. DFSMShsm recovers control data sets by merging the journal with a backed-up version of the control data set. Control data sets cannot be recovered to the point of failure without the journal. Use of the journal is highly preferred.

The data sets mentioned in this section are critical to DFSMShsm, and the loss of any of these data sets can potentially result in data loss. For this reason, create backups of DFSMShsm CDSs.

You can achieve that by using SETSYS CDSVERSIONBACKUP command. For more information about CDS data sets and how to create the backup files, see z/OS DFSMShsm Implementation and Customization Guide, SC23-6869.

4.8.2 Storage device hierarchy

A storage device hierarchy consists of a group of storage devices that have different costs for storing data, different amounts of data stored, and different speeds of accessing the data, which is processed as follows:

Level 0 volumes A volume that contains data sets that are directly accessible by the user. The volume can be either DFSMShsm-managed or non-DFSMShsm-managed.

Level 1 volumes A volume owned by DFSMShsm containing data sets that migrated from a level 0 volume.

Level 2 volumes A volume under control of DFSMShsm containing data sets that migrated from a level 0 volume, from a level 1 volume, or from a volume that is not managed by DFSMShsm.

Besides the storage hierarchy defined here, there are several volume types that are supported/controlled by DFSMShsm, including the following:

•Level 0 (L0) volumes contain data sets that are directly accessible to you and the jobs that you run. DFSMShsm-managed volumes are those L0 volumes that are managed by the DFSMShsm automatic functions. These volumes must be mounted and online when you refer to them with DFSMShsm commands.

•Migration level 1 (ML1) volumes are DFSMShsm-supported DASD on which DFSMShsm maintains your data in DFSMShsm format. These volumes are normally permanently mounted and online. They can be these types of volumes:

– Volumes containing data sets that DFSMShsm migrated from L0 volumes.

– Volumes containing backup versions created from a DFSMShsm BACKDS or HBACKDS command. Backup processing requires ML1 volumes to store incremental backup and dump VTOC copy data sets, and as intermediate storage for data sets that are backed up by data set command backup.

•Migration level 2 (ML2) volumes are DFSMShsm-supported tape or DASD on which DFSMShsm maintains your data in DFSMShsm format. These volumes are normally not mounted or online. They contain data sets migrated from ML1 volumes or L0 volumes.

•Daily backup volumes are DFSMShsm-supported tape or DASD on which DFSMShsm maintains your data in DFSMShsm format. These volumes are normally not mounted or online. They contain the most current backup versions of data sets copied from L0 volumes. These volumes can also contain earlier backup versions of these data sets.

•Spill backup volumes are DFSMShsm-supported tape or DASD on which DFSMShsm maintains your data sets in DFSMShsm format. These volumes are normally not mounted or online. They contain earlier backup versions of data sets, which were moved from DASD backup volumes.

•Dump volumes are DFSMShsm-supported tape. They contain image copies of volumes that are produced by the full volume dump function of DFSMSdss (write a copy of the entire allocated space of that volume), which is started by DFSMShsm.

•Aggregate backup volumes are DFSMShsm-supported tape. These volumes are normally not mounted or online. They contain copies of the data sets of a user-defined group of data sets, along with control information for those data sets. These data sets and their control information are stored as a group so that they can be recovered (if necessary) as an entity by an aggregate backup and recovery process (ABARS).

•Fast replication target volumes are contained within SMS copy pool backup storage groups. They contain the fast replication backup copies of DFSMShsm-managed volumes. Beginning with z/OS V1R8, fast replication is done with a single command.

•Overflow volumes are ML1 volumes with OVERFLOW paramter set during ADDVOL statement. The overflow volumes are used in situations where a migration or backup task is started, and the data set exceeds the size specified in SETSYS ML1OVERFLOW command, and the NOOVERFLOW volumes do not have enough space to allocate the data set.

•Cloud migration are cloud storage that can be used by DFSMShsm to migrate and recall data sets. Using cloud services to store migrated data sets relieve many DFSMShsm constraints, including data set reblocking, need to recycle, and CPU processing.

For more information about DFSMShsm devices, see z/OS DFSMShsm Implementation and Customization Guide, SC23-6869.

4.8.3 Availability management

DFSMShsm backs up your data, automatically or by command, to ensure availability if accidental loss of the data sets or physical loss of volumes occurs. DFSMShsm also allows the storage administrator to copy backup and migration tapes, and to specify that copies be made in parallel with the original.

You can store the copies on site as protection from media damage, or offsite as protection from site damage. DFSMShsm also provides disaster backup and recovery for user-defined groups of data sets (aggregates) so that you can restore critical applications at the same location or at an offsite location.

Figure 4-9 shows DFSMShsm processing for availability management tasks.

Figure 4-9 DFSMShsm availability management

Note: You must also have DFSMSdss to use the DFSMShsm functions.

Availability management ensures that a recent copy of your DASD data set exists. The purpose of availability management is to ensure that lost or damaged data sets can be retrieved at the most current possible level. DFSMShsm uses DFSMSdss as a fast data mover for backups. Availability management automatically and periodically performs the following functions:

1. Copy all the data sets on DASD volumes to tape volumes

2. Copy the changed data sets on DASD volumes (incremental backup) either to other DASD volumes or to tape volumes

DFSMShsm minimizes the space occupied by the data sets on the backup volume by using compression and stacking.

Tasks for availability management functions

The tasks for controlling automatic availability management of SMS-managed storage require adding DFSMShsm commands to the ARCCMDxx parmlib member and specifying attributes in the SMS storage classes and management classes. It is assumed that the storage classes and management classes have already been defined.

The attribute descriptions explain the attributes to be added to the previously defined storage groups and management classes. Similarly, the descriptions of DFSMShsm commands relate to commands to be added to the ARCCMDxx member of SYS1.PARMLIB.

Two groups of tasks are performed for availability management: Dump tasks and backup tasks. Availability management is composed of the following functions:

•Aggregate backup and recovery (ABARS)

•Automatic physical full-volume dump

•Automatic incremental backup

•Automatic control data set backup

•Command dump and backup

•Command recovery

•Disaster backup

•Expiration of backup versions

•Fast replication backup and recovery

Command availability management

Commands cause availability management functions to occur, resulting in the following conditions:

•One data set to be backed up.

•All changed data sets on a volume to be backed up.

•A volume to be dumped.

•A backed-up data set to be recovered.

•A volume to be restored from a dump and forward recovered from later incremental backup versions. Forward recovery is a process of updating a restored volume by applying later changes as indicated by the catalog and the incremental backup versions.

•A volume to be restored from a dump copy.

•A volume to be recovered from backup versions.

•A specific data set to be restored from a dump volume.

•All expired backup versions to be deleted.

•A fast replication backup version to be recovered from a copy pool.

Common dump and recovery queues

Besides the capacity of backing up and restoring data sets and volumes, DFSMShsm also provides the capability to spread dump and recovery requests across several DFSMShsm images. By doing so, you can reduce the amount of time that is required to dump and restore your data, thus reducing your backup and recovery windows.

These common queues use XCF messaging along with a master host to receive, and distribute the workload to available hosts. There can be only one master host at a time, and several submitters and processing hosts. If the master host becomes offline, another available host can assume the master role.

For more information about common dump and common recovery queues, including implementation steps, see z/OS DFSMShsm Implementation and Customization Guide, SC23-6869.

4.8.4 Space management

Space management is the function of DFSMShsm that allows you to keep DASD space available for users to meet the service level objectives for your system. The purpose of space management is to manage your DASD storage efficiently. To do this, space management automatically and periodically performs these functions:

1. Move low activity data sets (using DFSMSdss) from user-accessible volumes to DFSMShsm volumes

2. Reduce the space that is occupied by data on both the user-accessible volumes and the DFSMShsm volumes

DFSMShsm improves DASD space usage by keeping only active data on fast-access storage devices. It automatically frees space on user volumes by deleting eligible data sets, releasing overallocated space, and moving low-activity data to lower cost-per-byte devices, even if the job did not request tape. Figure 4-10 shows a sample space management processing performed by DFSMShsm.

Figure 4-10 DFSMShsm space management

Several DFSMShsm space management functions are available:

•Automatic primary space management

Run daily, this function cleans L0 volumes by deleting expired and temporary data sets, and releasing allocated and not used space (scratch). During automatic primary space management, DFSMShsm can process a maximum of 15 volume migration tasks concurrently.

This activity consists of the deletion of temporary data sets, deletion of expired data sets, the release of unused and overallocated space, migration, and class transition. Each task processes its own separate user DASD volume. The storage administrator selects the maximum number of tasks that can run simultaneously, and specifies which days and the time of day the tasks are to be performed.

•Automatic secondary space management

Automatic secondary space management deletes expired data sets from ML1/ML2, then moves data sets (under control of the management class) from ML1 to ML2 volumes. It should complete before automatic primary space management so that the ML1 volumes will not run out of space.

•Automatic interval migration

This function is initiated when a DFSMShsm-managed volume exceeds a specified threshold. Interval migration can select data sets for migration or transition, depending on the management class and DFSMShsm configuration. The interval migration processing is always performed at the top of the hour. If the threshold is exceeded after this check, the migration will occur only in the next window.

•On demand migration

This function is initiated when a DFSMShsm-managed volume exceeds a specified threshold. This function differs from interval migration because on demand migration does not perform the top-of-the-hour processing to check the volume utilization. Instead, it is notified by SMS when a volume exceeds the threshold, and the migration is performed against this single volume.

•Automatic recall

Automatically recalls user data sets back to DASD volumes, when referenced by the application.

•Space management by command

This function allows you to perform some space management tasks, such as migration and class transition by command, without needing to wait for the next automatic space management.

It is possible to have more than one z/OS image sharing a DFSMShsm policy. In this case, one of the DFSMShsm images is the primary host and the others are secondary. The primary HSM host is identified by HOST= in the HSM startup and is responsible for these tasks:

•Hourly space checks

•During auto backup: CDS backup, backup of ML1 data sets to tape

•During auto dump: Expiration of dump copies and deletion of excess dump VTOC copy data sets

•During secondary space management (SSM): Cleanup of MCDS, migration volumes, and L1-to-L2 migration

If you are running your z/OS HSM images in sysplex (parallel or basic), you can use secondary host promotion to allow a secondary image to assume the primary image's tasks if the primary host fails.

SMS Management Class for tape

With z/OS 2.3, new management class attributes were added to allow tape retention management through SMS management class. The new fields can be used by DFSMSrmm to control data set and tape retention, creating a single policy to manage both disk and tape data.

The following tape attributes were included in management class to allow tape processing:

•Tape volumes attributes

– ‘Retention Method’

The retention method is an attribute of the volume. All volumes in a multivolume set have the same retention method. All data sets on a volume are managed with the same retention method as the volume on which they reside. Retention method is only used if writing to the first data set of the volume chain.

– ‘VRSEL EXCLUDE’ (for VRSEL retention method)

When a data set is created on a tape volume managed by the EXPDT retention method, the data set VRSELEXCLUDE attribute is automatically set as “Y”. If the data set is created on a tape volume managed by the VRSEL retention method, the VRSELEXCLUDE attribute can be set by an SMS MGMTCLAS VRSELEXCLUDE attribute.

•Tape data set attributes

– ‘RETAIN BY’ (for EXPDT retention method)

With the EXPDT retention method, volumes and volume sets can be retained as individual volumes, as volume sets, or based on the expiration date of the first file. The volume attribute related to the retention of a multivolume set is the “RetainBy” attribute. Retain By is only assigned if writing to the first data set of the volume chain.

– ‘WHILECATALOG’ (for EXPDT retention method)

A cataloged data set can prevent the volume from expiring on its expiration date if it has WHILECATALOG(ON). The date might decrease after a data set with WHILECATALOG(UNTILEXPIRED) is uncataloged. The WHILECATALOG attribute is used to set the WHILECATALOG attribute for a new data set on an EXPDT volume only.

To assign a characteristic for a tape volume/data set using an SMS MC, the following conditions must be met:

•MC can apply to both system-managed tape and non-system-managed tape (using &ACSENVIR='RMMVRS).

•The MC should exist and V2R3 is required.

•The created data set should be SMS-supported and be on a TCDB volume.

•MGMTCLAS must be specified in JCL DD statement.

•When MCATTR=NONE, MC will not have any effect on an attribute.

•The following RMM PARMLIB options should be set:

SMSACS(YES) and MCATTR(ALL/VRSELXDI)

For more information about using management class to retain your tape data, see z/OS DFSMSrmm Managing and Using Removable Media, SC23-6873.

4.9 Removable media manager (DFSMSrmm)

In your enterprise, you store and manage your removable media in several types of media libraries. For example, in addition to your traditional tape library (a room with tapes, shelves, and drives), you might have several automated and manual tape libraries. You probably also have both onsite libraries and offsite storage locations, also known as vaults or stores.

With the DFSMSrmm functional component of DFSMS, you can manage your removable media as one enterprise-wide library (single image) across systems. Because of the need for global control information, these systems must have accessibility to shared DASD volumes. DFSMSrmm manages your installation's tape volumes and the data sets on those volumes. DFSMSrmm also manages the shelves where volumes reside in all locations except in automated tape library data servers.

DFSMSrmm manages all tape media, and other removable media you define to it. For example, DFSMSrmm can record the shelf location for optical disks and track their vital record status. However, it does not manage the objects on optical disks. The DFSMSrmm manages different levels of storage components and locations, including these:

•Library management

DFSMSrmm can manage a removable media library, including system-managed manual tape libraries and automated tape libraries. Non-system-managed or traditional tape libraries, including automated libraries such as a library under Basic Tape Library Support (BTLS) control.

•Shelf management

DFSMSrmm groups information about removable media by shelves into a central online inventory, and tracks the volumes on those shelves. DFSMSrmm can manage the shelf space that you define in your removable media library and in your storage locations.

•Volume management

DFSMSrmm manages the movement and retention of tape volumes throughout their lifecycle.

•Data set management

DFSMSrmm records information about the data sets on tape volumes. DFSMSrmm uses the data set information to validate volumes and to control the retention and movement of those data sets.

For more information about DFSMSrmm, see z/OS DFSMSrmm Guide and Reference, SC26-7404 and z/OS DFSMSrmm Implementation and Customization Guide, SC26-7405.

4.9.1 Resources managed by DFSMSrmm

A removable media library contains all the tape and optical volumes that are available for immediate use, including the shelves where they reside. A removable media library usually includes other libraries:

•System-managed libraries, such as automated or manual tape library data servers

•Non-system-managed libraries, containing the volumes, shelves, and drives not in an automated or a manual tape library data server

In the removable media library, you store your volumes in “shelves,” where each volume occupies a single shelf location. This shelf location is referred to as a rack number in the DFSMSrmm TSO subcommands and ISPF dialog. A rack number matches the volume’s external label.

DFSMSrmm uses the external volume serial number to assign a rack number when adding a volume, unless you specify otherwise. The format of the volume serial that you define to DFSMSrmm must be one to six alphanumeric characters. The rack number must be six alphanumeric or national characters.

System-managed tape library

A system-managed tape library is a collection of tape volumes and tape devices defined in the tape configuration database. The tape configuration database is an integrated catalog facility user catalog marked as a volume catalog (VOLCAT) containing tape volumes and tape library records. A system-managed tape library can be either automated or manual:

•An automated tape library is a device that consists of robotic components, cartridge storage areas (or shelves), tape subsystems, and controlling hardware and software. It also includes the set of tape volumes that are in the library and can be mounted on the library tape drives.

•A manual tape library is a set of tape drives and the set of system-managed volumes the operator can mount on those drives. The manual tape library provides more flexibility, enabling you to use various tape volumes in a manual tape library. Unlike the automated tape library, the manual tape library does not use the library manager. With the manual tape library, a human operator responds to mount messages that are generated by the host and displayed on a console.

You can have several automated tape libraries or manual tape libraries. You use an installation-defined library name to define each automated tape library or manual tape library to the system. DFSMSrmm treats each system-managed tape library as a separate location or destination.

Non-system-managed tape library

A non-system-managed tape library consists of all the volumes, shelves, and drives not in an automated tape library or manual tape library. You might know this library as the traditional tape library that is not system-managed. DFSMSrmm provides complete tape management functions for the volumes and shelves in this traditional tape library. Volumes in a non-system-managed library are defined by DFSMSrmm as being “shelf-resident.”

All tape media and drives that are supported by z/OS are supported in this environment. Using DFSMSrmm, you can fully manage all types of tapes in a non-system-managed tape library.

Storage location

Storage locations are not part of the removable media library because the volumes in storage locations are not generally available for immediate use. A storage location consists of shelf locations that you define to DFSMSrmm. A shelf location in a storage location is identified by a bin number. Storage locations are typically used to store removable media that are kept for disaster recovery or vital records. DFSMSrmm manages two types of storage locations: Installation-defined storage locations and DFSMSrmm built-in storage locations.

You can define an unlimited number of installation-defined storage locations, using any eight-character name for each storage location. Within the installation-defined storage location, you can define the type or shape of the media in the location. You can also define the bin numbers that DFSMSrmm assigns to the shelf locations in the storage location. You can request DFSMSrmm shelf-management when you want DFSMSrmm to assign a specific shelf location to a volume in the location.

You can also use the DFSMSrmm built-in storage locations: LOCAL, DISTANT, and REMOTE. Although the names of these locations imply their purpose, they do not mandate their actual location. All volumes can be in the same or separate physical locations.

For example, an installation can have the LOCAL storage location onsite as a vault in the computer room, the DISTANT storage location can be a vault in an adjacent building, and the REMOTE storage location can be a secure facility across town or in another state. DFSMSrmm provides shelf-management for storage locations so that storage locations can be managed at the shelf location level.

4.9.2 Libraries and locations

You decide where to store your removable media based on how often the media is accessed and for what purpose it is retained. For example, you might keep volumes that are frequently accessed in an automated tape library data server, and you probably use at least one storage location to retain volumes for disaster recovery and audit purposes. You might also have locations where volumes are sent for further processing, such as other data centers within your company or those of your customers and vendors.

DFSMSrmm automatically records information about data sets on tape volumes so that you can manage the data sets and volumes more efficiently. When all the data sets on a volume have expired, the volume can be reclaimed and reused. You can optionally move volumes that are to be retained to another location.

DFSMSrmm helps you manage your tape volumes and shelves at your primary site and storage locations by recording information in a DFSMSrmm control data set.

Managing libraries and storage locations

DFSMSrmm records the complete inventory of the removable media library and storage locations in the DFSMSrmm control data set, which is a VSAM key-sequenced data set. In the control data set, DFSMSrmm records all changes made to the inventory (such as adding or deleting volumes), and also tracks all movement between libraries and storage locations.

DFSMSrmm manages the movement of volumes among all library types and storage locations. This feature lets you control where a volume, and therefore a data set, resides, and how long it is retained.

Figure 4-11 shows a sample library and location management performed by DFSMSrmm.

Figure 4-11 DFSMSrmm: Managing libraries and storage locations

DFSMSrmm helps you manage the movement of your volumes and retention of your data over their full life, from initial use to the time they are retired from service. These are some of the functions that DFSMSrmm performs:

•Automatically initializing and erasing volumes

•Recording information about volumes and data sets as they are used

•Expiration processing

•Identifying volumes with high error levels that require replacement

To make full use of all of the DFSMSrmm functions, you specify installation setup options and define retention and movement policies. DFSMSrmm provides you with utilities to implement the policies that you define. If you want to learn more about DFSMSrmm functions, check DFSMSrmm Primer, SG24-5983.

4.9.3 Managing data

Besides the library and location management, DFSMSrmm also allows tape and data set retention management. You can define policies to retain your data, or allow the users to specify the retention on JCL. DFSMSrmm also provides a strong reporting capability, so you can use this information to plan your tape environment based on its usage and retention requirements.

You can control your data set expiration by the following methods:

•Vital records specification (VRS)

You can set VRS to identify the retention and movement policies, including how long and where you want to keep data sets or volumes. You also use them to define how volumes are to be moved among the libraries that DFSMSrmm supports, and the storage locations defined for vital records and disaster recovery purposes.

•EXPDT, RETPD

Data sets that are not controlled by VRSs can be controlled by EXPDT and RETPD parameters that are defined by the user on JCL during data set creation.

•Management Class

The SMS management class also includes information so DFSMSrmm can manage tape retention. For more information about management class and tape retention, see “SMS Management Class for tape” on page 71.

•External Data Manager (EDM)

DFSMSrmm also provides the option for the tapes to be managed externally. Some programs such as DFSMShsm perform their own tape management, and are capable of identifying when tapes are no longer required and can be scratched. Allowing a tape to be EDM ensures only the application that created the tape will have the authorization to scratch the tape.

When performing tape and data set management, DFSMSrmm also considers the time that the data was created, to ensure that the data is deleted only after the correct retention was reached.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Chapter 4. Storage management software

Create new playlist

Sign In

Sign Up

Table of Contents for
Chapter 4. Storage management software