[attachment=1563]
ABSTRACT
Virtual storage access method (VSAM) is an IBM disk file storage
access method, first used in the OS/VS2 operating system, later used
throughout the Multiple Virtual Storage (MVS) architecture and now in
z/OS. Originally a record-oriented filesystem, VSAM comprises four
data set organizations: Key Sequenced Data Set (KSDS), Relative
Record Data Set (RRDS),Entry Sequenced Data Set (ESDS) and Linear
Data Set (LDS). The KSDS, RRDS and ESDS organizations contain
records, while the LDS organization (added later to VSAM) simply
contains a sequence of bytes with no intrinsic record structure.
IBM uses the term data set in official documentation as a synonym of
file, and DASD instead of disk drive.
VSAM records can be of fixed or variable length. They are organised
in fixed-size blocks called Control Intervals (CIs), and then into
larger divisions called Control Areas (CAs). Control Interval sizes
are measured in bytes ” for example 4 kilobytes ” while Control Area
sizes are measured in disk tracks or cylinders. Control Intervals are
the units of transfer between disk and computer so a read request
will read one complete Control Interval. Control Areas are the units
of allocation so, when a VSAM data set is defined, an integral number
of Control Areas will be allocated.
The Access Method Services utility program IDCAMS is commonly used to
manipulate ("delete and define") VSAM data sets.
Custom programs can access VSAM datasets through data definitions
(DDs) in Job Control Language (JCL) or in online regions such as in
Customer Information Control Systems (CICS).
Both IMS/DB and DB2 are implemented on top of VSAM and use its
underlying data structures.

INTRODUCTION
Virtual Storage Access Method - VSAM - is a data management system
introduced by IBM in the 1970s as part of the OS/VS1 and OS/VS2
operating systems. Although there are still datasets that are best
managed with the several other (non-VSAM) data management methods,
VSAM is a major component of modern IBM operating systems. Since MVS
3.8 is one of those operating systems, Multiple Virtual Storage, more
commonly called MVS, was the most commonly used operating system on
the System/370 and System/390IBM mainframe computers. It was
developed by IBM, but is unrelated to IBM's other mainframe operating
system, VM.
First released in 1974, MVS had been renamed multiple times, first to
MVS/XA (eXtended Architecture), next to MVS/ESA (Enterprise Systems
Architecture), then to OS/390 (when UNIX System Services (USS) were
added), and finally to z/OS (when 64-bit support was added with
thezSeries models). Its core remains fundamentally the same operating
system. By design, programs written for MVS can still run on z/OS
without modification.
At first IBM described MVS as simply a new release of OS/VS2. But it
was in fact a complete re-write - previous OS/VS2 releases were
upgrades of OS/MVT and, like MVT, were mainly written in Assembler;
the core of MVS was almost entirely written in PL/S. IBM's use of
"OS/VS2" emphasized upwards compatibility: application programs which
ran under MVT did not even need to be re-compiled in order to run
under MVS; the same Job Control Language files could be used
unchanged; the utilities and other non-core facilities like TSO ran
unchanged. But users almost unanimously called the new system MVS
from the start, and IBM followed their lead in the naming of later
major versions such as MVS/XA. After the release of MVS, users
described earlier OS/VS2 releases as SVS (Single Virtual Storage).
Evolution of MVS
OS/MFT (Multitasking with a Fixed number of Tasks) provided
multitasking: several memory partitions, each of a fixed size, were
set up when the operating system was installed. For example, there
might be a small partition, two medium partitions, and a large
partition. If there were two large programs ready to run, one would
have to wait on the other until it finished and vacated the large
partition.
OS/MVT (Multitasking with a Variable number of Tasks) was an
enhancement which further refined memory usage. Instead of using
fixed-size memory partitions, MVT allocated memory to programs as
needed provided there was enough contiguous physical memory
available. This was a significant advance over MFT's memory
management: there was no predefined limit on the number of jobs that
could run at the same time; and two or more large jobs could run at
the same time if enough memory was available. But it had some
weaknesses: if a job allocated memorydynamically (as most sort
programs and database management systems do), the programmers had to
estimate the job's maximum memory requirement and pre-define it for
MVT; a job which contained a mixture of small and large programs
would waste memory while the small programs were running; most
seriously, memory could become fragmented, i.e. the memory not used
by current jobs could be divided into uselessly small chunks between
the areas used by current jobs, and the only remedy was to wait until
all current jobs finished before starting any new ones.
In the early 1970s IBM sought to mitigate these difficulties by
introducing virtual memory (referred to by IBM as "virtual storage"),
which allowed programs to request address spaces larger than physical
memory. The original implementations had a single virtual address
space, shared by all jobs. OS/VS1 was OS/MFT within a single virtual
address space; OS/VS2 SVS was OS/MVT within a single virtual address
space. So OS/VS1 and SVS in principle had the same disadvantages as
MFT and MVT but the impacts were less severe because jobs could
request much larger address spaces.
MVS address spaces - global view
MVS (shared part of all address spaces)
App 1 App 2 App 3
Shared virtual area (controlled by MVS)
One application's view
MVS
App 1
Shared virtual area
In the mid-1970s IBM introduced MVS, which allowed an indefinite
number of applications to run in different address spaces - two
concurrent programs might try to access the same virtual memory
address, but the virtual memory system redirected these requests to
different areas of physical memory. Each of these address spaces
consisted of 3 areas: operating system (one instance shared by all
jobs); application area which was unique for each application; shared
virtual area which was used for various purposes including inter-job
communication. IBM promised that the application areas would always
be at least 8MB.
MVS originally supported 24-bit addressing (i.e. up to 16MB). As the
underlying hardware progressed it supported 31-bit (XA and ESA; up to
2048MB) and now (as z/OS) 64-bit addressing. Two of the most
significant reasons for the rapid upgrade to 31-bit addressing were:
the growth of large transaction-processing networks, mostly
controlled by CICS, which ran in a single address space; theDB2
relational database management system needed more than 8MB of
application address space in order to run efficiently (early versions
were configured into two address spaces which communicated via the
shared virtual area, but this imposed a significant overhead since
all such communications had to be transmitted via the operating
system).
The main user interfaces to MVS are: Job Control Language (JCL),
which was originally designed for batch processing but from the 1970s
onwards was also used to start and allocate resources to long-running
interactive jobs such CICS; and TSO (Time Sharing Option), the
interactive time-sharing interface, which was mainly used to run
development tools and a few end-user information systems. ISPF is a
TSO application for users on 3270-family terminals (and later, on VM
as well) which allows the user to accomplish the same tasks as TSO's
command line but in a menu and form oriented manner, and with a full
screen editor and file browser. TSO's basic interface is command
line, although facilities were added later for creating form-driven
interfaces).
Early editions of MVS (mid-1970s) were among the first of the IBM OS
series to support multiprocessor configurations, though it had
previously been supported in the 1960s on a limited basis by the
M65MP variant of OS/360 running on 360/65 and 360-67. The 360-67 had
also hosted the multiprocessor capable TSS/360 and MTS operating
systems. In tightly-coupled systems, two CPUs shared concurrent
access to the same memory (and copy of the operating system) and
peripherals, providing greater processing power and a degree of
graceful degradation if one CPU failed. In loosely-coupled
configurations each of a group of processors (single and / or
tightly-coupled) had its own memory and operating system but shared
peripherals and the operating system component JES3 allowed the whole
group to be managed from one console - this provided greater
resilience and enabled operators to decide which processor should run
which jobs from a central job queue.
MVS took a major step forward in fault-tolerance that IBM called
'software recovery'. IBM decided to do this after years of practical
real-world experience with MVT in the business world - system
failures were now having major impacts on customer businesses and IBM
decided to take a major design jump, to assume that despite the very
best software development and testing techniques, that 'problems WILL
occur'. This profound assumption was pivotal in adding great
percentages of fault-tolerance code to the system, but likely
contributed to the system's success in tolerating software and
hardware failures. Statistical information is hard to come by to
prove the value of these design features (how can you measure
'prevented' or 'recovered' problems?), but IBM has, in many
dimensions, enhanced these fault-tolerant software recovery and rapid
problem resolution features, over time.
This design specified a hierarchy of error-handling programs, in
system (kernel/'privileged') mode, called Functional Recovery
Routines, and in user ('task' or 'problem program') mode, called
"ESTAE" (Extended Specified Task Abnormal Exit routines) that were
invoked in case the system detected an error (actually, hardware
processor or storage error, or software error). The purpose of each
recovery routine was to make the 'mainline' function reinvokable,
capture error diagnostic data sufficient to debug the causing
problem, and either 'retry' (reinvoke the mainline) or 'percolate'
(escalate error processing to the next recovery routine in the
hierarchy).
Thus, with each and every error: diagnostic data was captured, an
attempt was made to perform a repair and keep the system up. The
worst thing possible was to take down a user address space (a 'job')
in the case of unrepaired errors. Although it was an initial design
point, it was not until the most recent MVS version (z/OS), that
recovery program was not only guaranteed its own recovery routine,
but each recovery routine now has its own recovery routine.
This recovery structure was embedded in the basic MVS control
program, and programming facilities are available and used by
application program developers and 3rd party developers.
Practically, it has been observed that the MVS software recovery made
problem debugging both easier and more difficult: Software recovery
required that programs leave 'tracks' of where they were and what
they were doing, thus facilitating debugging, but the fact that
processing does not stop at the time of an error, but rather
progresses, can make the tracks over-written. Early date capture at
the time of the error maximizes debugging, and facilities exist for
the recovery routines (task and system mode, both) to do this.
IBM included additional criteria for a major software problem that
would require IBM service to repair it: If a mainline component
failed to initiate software recovery, that was considered a
reportable valid failure. Also, if a recovery routine failed to
collect significant diagnostic data such that the original problem
was solvable by data collected by that recovery routine, IBM
standards dictated that this fault was reportable and required
repair. Thus, IBM standards, when applied rigorously, would encourage
continuous improvement.
IBM introduced an on-demand hypervisor, a major serviceability tool,
called Dynamic Support System (DSS), in the first release of MVS.
This facility could be invoked to initiate a session to create
diagnostic procedures, or invoke already-stored procedures. The
procedures 'trapped' special events, such as the loading of a
program, device I/O, system procedure calls, and then triggered the
activation of the previously-defined procedures. These procedures,
which could be invoked recursively, allowed for reading and writing
of data, and alteration of instruction flow. Program Event Recording
hardware was used. Due to the overhead of this tool, it was removed
from customer-available MVS systems. Program-Event Recording (PER)
exploitation was performed by the enhancement of the diagnostic
"SLIP" command with the introduction of the PER support (SLIP/Per) in
SU 64/65 (1978).
Multiple copies of MVS (or other IBM operating systems) could share
the same machine if that machine was controlled by VM/370 - in this
case VM/370 was the real operating system and regarded the "guest"
operating systems as applications with unusually high privileges. As
a result of later hardware enhancements one instance of an operating
system (either MVS, or VM with guests, or other) could also occupy a
Logical Partition (LPAR) instead of an entire physical system.
Multiple MVS instances can be organized and collectively administered
in a structure called a systems complex or sysplex, introduced in
September, 1990. Instances interoperate through a software component
called a Cross-system Coupling Facility (XCF) and a hardware
component called a Hardware Coupling Facility (CF or Integrated
Coupling Facility, ICF, if co-located on the same mainframe
hardware). Multiple sysplexes can be joined via standard network
protocols such as IBM's proprietary Systems Network Architecture
(SNA) or, more recently, viaTCP/IP.
The z/OS operating system (MVS' most recent descendant) also has
native support to execute POSIX applications.
Files are properly called data sets in MVS. Names of those files are
organized in catalogs which are VSAM files themselves.
The native encoding scheme of IBM mainframes and their peripherals is
Big Endian EBCDIC, but MVS provides hardware-accelerated services to
perform translation and support of ASCII, Little Endian, and Unicode.
Two main segments -
Concepts and Facilities
Access Method Services
In the first segment, is a simple description of the components of
VSAM, with the goal of introducing VSAM to those who have not had
practical experience with it. It is perception that quite a few
people are coming into the Hercules (and MVS) community who have not
had any formal exposure to this type of material.
In the second segment, it includes of the functions provided by
Access Method Services. Access Method Services is the single,
general-purpose utility that is used to manipulate VSAM components by
both Systems and Applications Programmers.

OBJECTIVES
Concepts and Facilities
VSAM was, by several accounts, intended to replace all of the earlier
data management systems in use by IBM's operating systems.
Conventional (non-VSAM) access methods generally provide only a
single type of dataset organization. VSAM provides three:
¢ Key Sequenced Data Set (KSDS), where each record is
identified for access by specifying its key value - a sequence of
characters embedded in each data record which uniquely identifies
that record from all other records in the dataset. KSDS datasets are
similar to Indexed Sequential Access Method (ISAM) datasets, with
many of the same characteristics, but also having distinct advantages
over ISAM.
¢ Entry Sequenced Data Set (ESDS), where each record is
identified for access by specifying its physical location - the byte
address of the first data byte of each record in relationship to the
beginning of the dataset. ESDS datasets are similar to Basic
Sequential Access Method (BSAM) or Queued Sequential Access Method
(QSAM) datasets.
¢ Relative Record Data Set (RRDS), where each record is
identified for access by specifying its record number - the sequence
number relative to the first record in the dataset. RRDS datasets
are similar to Basic Direct Access Method (BDAM) datasets.
VSAM datasets are frequently referred to as clusters. A KSDS cluster
consists of two physical parts, an index component, and a data
component. ESDS and RRDS clusters consist of only a single
component, the data component.
KSDS Cluster Components
In a KSDS, records are placed in the data set in ascending collating
sequence by key. The key contains a unique value that determines the
record's collating position in the data set. The key must be in the
same position in each record. The key data must be contiguous and
each record's key must be unique. After it is specified, the value of
the key cannot be altered, but the entire record can be deleted. When
a new record is added to the data set, it is inserted in its
collating sequence by key. This could be fixed or variable length
record. There are three methods by which to access a KSDS. These are
sequential, direct, or skip-sequential.
SEQUENTIAL ACCESS is used to load a KSDS, and to retrieve, update,
add and delete records in an existing data set. VSAM uses the index
to access data records in ascending or descending sequence by key.
When retrieving records, you do not need to specify key values
because VSAM automatically obtains the next logical record in
sequence. The sequence set is used to find the next logical CI.
Sequential access allows you to avoid searching the index more than
once. Sequential is faster than direct for accessing multiple data
records in ascending key order.
DIRECT ACCESS is used to retrieve, update, add and delete records in
an existing data set. You need to supply a key value for each record
to be processed. You can supply the full key or a generic key. The
generic key is the high order portion of a full key. For example, you
might want to retrieve all records whose keys begin with XY (where XY
is the generic key), regardless of the full key value. VSAM searches
the index from the highest-level index set CI to the sequence set for
a record to be accessed. Vertical pointers in the sequence set CI are
used to access the data CA containing the record. Direct access saves
you a lot of overhead by not retrieving the entire data set
sequentially to process a small percentage of the total number of
records.
SKIP-SEQUENTIAL ACCESS is used to retrieve, update, add and delete
records in an existing data set. VSAM retrieves selected records, but
in ascending sequence of key values. Skip sequential processing
allows you to - Avoid retrieving the entire data set sequentially in
order to process a relatively small percentage of the total number of
records. Avoid retrieving the desired records directly, which causes
the index to be searched from top to bottom level for each record For
each request the sequence set is used to find the next logical CI and
to check if it contains the requested record. If the first skip-
sequential search is the first access after opening the data set, a
direct search is initiated by VSAM to find the first record. From
then on the index sequence set level will be used to find the
subsequent records. If other operations were performed before (for
example, read sequential), either the last position of that operation
will be used as a starting point to search the sequence set records,
or a re-positioning is necessary. You specify the KSDS organization
using the IDCAMS DEFINE command with the INDEXED parameter
ESDS Cluster Components
An ESDS is comparable to a sequential non-VSAM data set in the sense
that key field in the logical record sequences records by the order
of their entry in the data set, rather than. This could be fixed or
variable length record. All new records are placed at the end of the
data set. 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. It is the
responsibility of the application program to identify that record as
invalid. Records can be updated, but without length change. To change
the length of a record, you must either store it at the end of the
data set as a new record, or override an existing record of the same
length that you have flagged as inactive.
A record can be accessed sequentially or directly by its RBA:
Sequential processing: VSAM automatically retrieves records in stored
sequence. Sequential processing can be started from the beginning or
somewhere in the middle of a data set. If processing is to begin in
the middle of a data set, positioning is necessary before sequential
processing can be performed.
Direct processing: When a record is loaded or added, VSAM indicates
its RBA. To retrieve records directly, you must supply the RBA for
the record as a search argument. Although an ESDS does not contain an
index component, you can build an alternate index to keep track of
these RBAs. Skip sequential processing is not allowed for an ESDS.
RRDS Cluster Components
An RRDS consists of a number of pre-formatted fixed-length slots.
Each slot has a unique relative record number, and ascending relative
record number sequences the slots. Each fixed length logical record
occupies a slot, and is stored and retrieved by the relative record
number of that slot. The position of a data record is fixed and its
relative record number cannot change.
Because the slot can either contain data or be empty, a data record
can be inserted or deleted without affecting the position of other
data records in the RRDS. The RDF shows whether the slot is occupied
or empty. Free space is not provided because the entire data set is
divided into fixed-length slots.
Typical RRDS processing:-
The application program inputs the relative record number of the
target record and VSAM is able to find its location quickly using a
formula that takes into consideration the geometry of the DASD
device. The relative record number is always used as a search
argument. An RRDS can be processed sequentially, directly or skip-
sequentially.
RRDS sequential processing is treated the same way as ESDS sequential
processing. Empty slots are automatically skipped by VSAM.
RRDS can be processed directly by supplying the relative record
number as a key. VSAM calculates the RBA and accesses the appropriate
record or slot. RRDS direct address processing by supplying the RBA
is not supported.
Skip-sequential processing is treated like an RRDS direct processing
request, but the position is maintained. Records must be in ascending
sequence. You specify the RRDS organization using the IDCAMS DEFINE
command with the NUMBERED option.


FILE MANAGEMENT SYSTEM USING SQL QUERIES.

VSAM MODULES
Access Method Services
Pre-VSAM data management required many utility programs for
housekeeping -
¢ IEBGENER to copy the contents of sequential datasets
¢ IEHMOVE and IEBCOPY to copy, move, reorganize, expand, backup
and restore the contents of partitioned dataset
¢ IEBISAM to load, backup, restore, and reorganize the contents
of ISAM datasets to name a few. However, there is only a single
utility for managing all of the housekeeping needs of VSAM -
IDCAMS:-
Which is also known by the functionality it provides, Access Method
Services or, simply, AMS. IDCAMS is a utility that exclusively
handles all types of VSAM data sets. The following list provides an
overview of the functions that can be performed with this utility on
the VSAM datasets.
Function Command
To Create any VSAM object DEFINE
To copy data from a VSAM object to
another or a non-VSAM dataset
REPRO
To Print a VSAM file PRINT
To delete any VSAM object DELETE
To List the Characteristics of a VSAM object
LISTCAT
This command is a necessary and very useful facility. The catalog
contains all the information about the VSAM file.
The basic JCL to run the utility is:
//IDCAMS JOB 'JAY MOSELEY',CLASS=A,MSGLEVEL=(1,1),MSGCLASS=A
//IDCAMS EXEC PGM=IDCAMS,REGION=4096K
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
/* UTILITY COMMAND STATEMENTS */
/*
//
Some of the functions require additional DD statements when they are
referenced by the AMS command statements, but SYSPRINT and SYSIN are
the only absolute requirements.
Access Methods:-
Data (Records) from the files (databases) can be retrieved in the
following modes:
Sequential “ This access method allows users to read the records in
the order of entry into the file. This mode is most useful while
preparing reports on VSAM
Random “ This access method allows users to access the file based on
a key value, or in a sequential mode starting from a key value as
desired. This mode is more used in updating master files through
online real time applications.
Direct “ This access mode facilitates records to be selected on the
basis of the location of the record in the file. The address of the
record to be read is used to locate the record.
Other Access methods:-
The following are the access methods that were used for accessing
files before the advent of VSAM.
VSAM as an access method provides ability to maintain and access data
in all the following formats.
QSAM “ Queried Sequential Access Method
BSAM “ Basic Sequential Access Method for ˜flat™ files
ISAM “ Index Sequential Access Method for Index files
BDAM “ Basic Direct Access Method for direct access files
VSAM Data Space:-
Before VSAM clusters can be created on a volume, one or more data
spaces must be created. A data space is an area of the direct access
storage device that is exclusively allocated for VSAM use. That is,
the area occupied by the data space is recorded in the Volume Table
of Contents (VTOC) of the volume as allocated to a dataset, so that
the space will not be available for allocation to any other use,
either VSAM or non-VSAM. There are three data spaces shown in the
chart (#4, #5, and #6).
Actually, when either the master catalog or a user catalog is
defined, VSAM creates a data space to hold the user catalog entries,
allocating the amount of space specified for the user catalog from
the space available on the volume as a data space which will be
completely allocated to the catalog.
The name of the files that are recorded in the VTOC for space
allocated to catalogs and data spaces is generated by VSAM. However,
they can be easily recognized for what they contain from the high
level qualifier of the generated name. For catalogs (both master and
user), the high level qualifier is Z9999992. For data spaces, the
high level qualifier is Z9999994.
Unique Clusters:-
It is possible to create VSAM clusters out of unallocated space on
direct access storage. This type of cluster has a designation of
UNIQUE and essentially consists of a separate data space which is
utilized completely by the cluster created within it. From a data
management viewpoint, it is not a good idea to create unique VSAM
clusters, although in some cases there are system datasets which are
created in this manner. There is an indication of this type of
cluster allocation on the chart (#9).
The most frequent manner of creating VSAM clusters is to suballocate
the space required for the cluster's records from available space in
a previously defined data space. Suballocated clusters are indicated
on the chart for both system and user datasets (#7, #8, and #10).
For all VSAM objects except suballocated clusters, there is an entry
placed in the VTOC of the direct access storage device volume on
which the object resides. The entry name generated by VSAM for these
objects is usually not mnemonic enough to visually indicate the
contents of the VSAM object.
Non-VSAM Datasets:-
In addition to VSAM objects, non-VSAM datasets (residing on both tape
and direct access storage) may have entries in both the master
catalog and user catalogs. As with VSAM objects, it is best if only
system datasets are cataloged in the master catalog. Since the main
function of cataloging non-VSAM datasets is to retain Unit and Volume
Serial information, the amount of information stored for a non-VSAM
dataset is minimal compared to the information stored for a VSAM
object. Non-VSAM objects are indicated on the chart as #11, #12, and
#13.

VSAM CATALOGS
When a non-VSAM dataset is created, the user has the option, by means
of the DISP=(,CATLG) JCL entry, of creating a catalog entry for the
dataset. The catalog keeps track of the unit and volume on which the
dataset resides and can be used for later retrieval of the dataset.
With VSAM datasets, creation of a catalog entry to record the unit
and volume, as well as many other characteristics of the dataset, is
not optional.
Prior to VSAM, catalog entries for non-VSAM datasets were contained
in OS CVOLS (operating system control volumes). VSAM maintains its
own catalog, which is itself a KSDS cluster, into which catalog
entries describing VSAM clusters are recorded. The same VSAM catalog
may also be used to contain the catalog entries for non-VSAM
datasets.
Later releases of OS/390, the operating system into which MVS
evolved, and z/OS, the current incarnation of MVS-OS/390, use yet
another catalog system - the Integrated Catalog Facility. On the
latest versions of OS/390 and z/OS, ICF catalogs are the only type of
catalogs supported.
For MVS 3.8j, the relevant catalog system is the VSAM catalog, which
is where information for both VSAM and non-VSAM datasets is recorded.
Catalogs, Data Spaces, and Clusters :-
Begining with a graphic representation of the components and their
relationships to one another, and then describe the rules governing
the relationships.

VSAM CATALOG & DATA SAPCE STRUCTURE
Master Catalog:-
Every system that uses VSAM has one, and only one, master catalog.
The master catalog contains entries about system datasets and VSAM
structures used to manage the operation of VSAM. It is possible for
any dataset (VSAM or non-VSAM) to be cataloged in the master catalog,
but that is rarely allowed in well managed systems. In most computer
systems, the Systems Programming staff will have created user
catalogs, which are cataloged in the master catalog; all other users
of the computer system will only be allowed to catalog datasets in
those user catalogs. In the chart, the objects which have been
shaded gray are the objects (excluding user catalogs) which are
cataloged in the master catalog. In a typical system, these objects
would all be system datasets, such as the system libraries (non-VSAM
datasets) and page datasets.
The master catalog is created during the System Generation process
and usually resides on the System Residence volume. The master
catalog "owns" all other VSAM resources in a computer system, and
this is denoted by the position of the master catalog (#1) in the
chart. To quote a fairy tale that was popular in the 1970s that was
used to describe the relationship of VSAM components, the master
catalog is the "VSAM King".
User Catalogs:-
A user catalog is a catalog created to contain entries about
application specific datasets. The information defining a user
catalog is stored into a catalog entry in the master catalog. A
production system might have any number of user catalogs, with the
datasets cataloged in a specific user catalog related by application
type. There are two user catalogs shown in the chart (#2 and #3).
Control Intervals:-
In non-VSAM data management methods, the unit of data that is moved
between memory and the storage device is defined by the block. In
VSAM, the unit of data that is transferred in each physical I/O
operation is defined as a control interval. A control interval
contains records, control information, and (in the case of KSDS
clusters) possibly free space which may later be used to contain
inserted records.
When a VSAM dataset is loaded, control intervals are created and
records are written into them. With KSDS clusters, the entire
control interval is usually not filled. Some percentage of free
space is left available for expansion. With ESDS clusters, each
control interval is completely filled before records are written into
the next control interval in sequence. With RRDS clusters, control
intervals are filled with fixed-length slots, each containing either
an active record or a dummy record. Slots containing dummy records
are available for use when new records are added to the dataset.
Control Areas:-
Control intervals are grouped together into control areas. The rules
used for filling and writing control areas are similar to those which
apply for control intervals. For ESDS and RRDS clusters, control
areas are filled with control intervals that contain records. For
KSDS clusters, some of the control intervals in each control area may
consist entirely of free space that can be used for dataset
expansion.
Defining an Alias:-
There are several ways that VSAM determines which catalog to use when
a catalog search is required, either to locate a catalog entry for an
existing object or to create a catalog entry one for a new object.
Most AMS commands can explicitly specify which catalog is to be used
by including a CATALOG parameter in the command. The inclusion of a
CATALOG parameter overrides any other method for determining the
catalog to use. Another way to explicitly define the catalog to be
used is by including the JOBCAT and/or STEPCAT DD statements in the
JCL for the job. If neither of these methods is used to designate
the catalog to use, AMS uses the high level qualifier of the object
or dataset name and attempts to determine the catalog to search. If
the high level qualifier matches the name of a user catalog, that
user catalog is used. Otherwise, the master catalog is used.
It is possible to establish any number of alias entries to associate
multiple high level qualifier values with a specific user catalog.
The AMS command to create aliases is DEFINE ALIAS.
Model syntax for the command:
DEFINE ALIAS
(NAME(aliasname)
RELATE(entryname))
[CATALOG(catname[/password])]
Deleting VSAM and non-VSAM Objects:-
The DELETE command removes the entry for the specified object(s) from
the catalog and optionally removes the object, thereby freeing up the
space occupied by the object (in the case of datasets residing on
direct access storage).
Variety of VSAM and non-VSAM objects may be deleted with the DELETE
command. The DELETE command deletes all objects associated with the
entry name specified. By default, objects with a retention period
that has not expired will not be deleted. This behavior can be
overridden by the inclusion of the PURGE option.
The ERASE / NOERASE option may be specified to override the ERASE
attributed specified for the object in the catalog.
The FORCE option may be specified to cause the deletion of specific
objects (SPACE, USERCATALOG, GENERATIONDATAGROUP) even though they
may be non-empty.
The SCRATCH option may be specified to cause the associated entry for
the object to be removed from the Volume Table of Contents. This is
most often applicable to non-VSAM datasets.
The CATALOG option may not be specified for DELETE commands used to
delete user catalogs. User catalog entries may only be deleted from
the master catalog. Note: It is possible with MVS 3.8j to catalog a
user catalog entry in another user catalog, but if you do, you cannot
delete it.
Listing Catalog Entries:-
The LISTCAT command is provided to list the information from catalog
entries. If you have been reading this page in sequence, you have
already seen output from the LISTCAT command in the SYSOUT listings
from my examples of many of the other AMS commands. It is almost
always a good idea to list the catalog entries for objects
immediately following their creation to visually verify that all of
the options you intended to specify were entered correctly and had
the desired effect on the entry created. It is also frequently
necessary to list fields from the catalog entry for a VSAM object to
diagnose problems.
All parameters of the LISTCAT command are optional.
The first group of parameters (beginning with ALIAS and concluding
with USERCATALOG) are positional parameters that specify which types
of catalog entries are to be listed. One or more of these parameters
may be specified. If none are specified, the listing will include
all entries from the catalog regardless of type.
CREATION specifies a number of days; entries are listed only if they
were created the specified number of days ago or earlier.
EXPIRATION also specifies a number of days; entries are listed only
if they will expire in the specified number of days or earlier.
The parameters NAME, HISTORY, VOLUME, ALLOCATION, and ALL specify the
type of information to list for catalog entries. NAME (the default)
specifies that only the name and entry type should be listed.
HISTORY specifies that the name, entry type, ownerid, creation date,
and expiration date should be listed. VOLUME specifies that all
information listed by the HISTORY parameter, plus the volume serial
numbers and device type should be listed. ALLOCATION specifies that
all information listed by the VOLUME parameter, plus the detail
information about space allocation should be listed. ALL specifies
that all information from the catalog entry should be listed.
SPACE ALLOCATION
One of the three space allocation sub-parameters must be coded to
specify the size of the cluster. Space may be requested in terms of
cylinders, tracks, or records. Both a primary and secondary quantity
may be specified for either of the three specification units. The
primary quantity is the amount of space initially allocated to the
cluster. The secondary quantity is the amount of additional space
allocated when the available space is completely used and an
additional record is added to the cluster. The number of times that
a cluster can be expanded (secondary quantities of space allocated)
varies based on several factors, but may be as high as 123 times.
The RECORD method of allocation space is preferred, as AMS will
calculate the appropriate amount of space for the type of direct
access storage device upon which the cluster is allocated.
The VOLUMES parameter specifies one or more direct access storage
volumes on which space may be allocated for the cluster.
Where the space is obtained for allocation is determined by the
UNIQUE / SUBALLOCATION parameter. If UNIQUE is specified, free space
must exist on the VOLUMES specified; an independent data space is
created on the volume and is allocated entirely to the cluster being
defined. From a data management viewpoint, this is usually not a
good idea. A better method is to allow AMS to suballocate the
required space from an already defined VSAM data space.
Type of Cluster - Key Sequenced, Entry Sequenced, or Relative
Record:-
The presence of the INDEXED, NONINDEXED, or NUMBERED parameters
determine the type of cluster created. INDEXED specifies a Key
Sequenced cluster; NONINDEXED specifies an Entry Sequenced cluster;
and NUMBERED specifies a Relative Record cluster.
Record Size:-
The RECORDSIZE parameter specifies both the size of the logical
record which can be written to the cluster and also whether the
records will be fixed or variable length. If the integer values of
bothaverage and maximum are identical, the records which can be
written to the cluster will be fixed length and of the size specified
by the value. If the values specified differ, the records written to
the cluster may be in varying length, up to the value specified for
maximum.
Keys (INDEXED clusters only):-
The KEYS parameter specifies the length and position (relative to the
beginning of the record, with 0 indicating the first character) of
the primary key in the records written to the cluster.
Re-Usable Clusters:-
The REUSE parameter allows clusters to be defined that may be reset
to empty status without deleting and re-defining them. This is most
often used for clusters used as work datasets.
Buffer Space:-
BUFFERSPACE is used to specify the minimum amount of buffer space
required to process the dataset. The value specified affects the
control interval size. AMS ordinarily chooses a control interval
size large enough that two control intervals and one index record
will fit in the specified amount of buffer space. Regardless of what
value is coded here (or the default), the value may be overridden at
execution time by JCL parameter.
Control Interval Size:-
In most cases, the CONTROLINTERVALSIZE parameter should be omitted.
This allows AMS to choose the most efficient value for the dataset.
A control interval can range from 512 to 32,768 bytes in size. If
the size is between 512 and 8,192 bytes, a multiple of 512 should be
specified. If it is between 8,192 and 32,768 bytes, a multiple of
2,048 should be specified. If the size is not a multiple of the
appropriate value, AMS rounds the size up to the next appropriate
multiple. If CONTROLINTERVALSIZE is specified for the INDEX
component of a KSDS, the specified size must be 512, 1,024, 2,048, or
4,096.
Erase:-
The ERASE parameter specifies that when the cluster is deleted, the
space occupied by the cluster should be physically erased by
overwriting the space with binary zeros prior to freeing the space
for reuse.
Free Space (INDEXED clusters only):-
The FREESPACE parameter specifies a percentage of space to leave
unallocated for future expansion. The percentage applies when
records are initially loaded into the cluster and when control
interval and control area splits occur as records are inserted
between existing records. If FREESPACE is not specified, control
intervals are filled as completely as possible and no space is left
for addition of records in the future.
Replicate and Imbed (INDEXED clusters only):-
REPLICATE specifies that VSAM should write each index record on a
track as many times as it will fit. IMBED specifies that sequence
set records are to be imbedded with the data in the data component of
the cluster. When the sequence set is imbedded in the data
component, VSAM writes each sequence set record on the first track of
its associated control area. IMBED automatically implies REPLICATE.
Without imbedding, the sequence set records are kept in the index
component with other index records. The use of REPLICATE and IMBED
may improve performance at the expense of an increase in storage
requirements.
Pre-Formatting Space:-
The SPEED / RECOVERY parameters are used to specify whether or not
VSAM should preformat the space allocated to the cluster as part of
the DEFINE process. Specifying RECOVERY (the default) causes the
allocated space to be filled with end-of-file markers. If the
initial load of the cluster with data should fail before completion,
the end-of-file markers can be used to resume the load from the point
of failure. For large datasets, this can save recovery time, however
there is a trade-off in time to write the end-of-file markers during
the definition of the cluster.

STATEMENT SYNTAX
The format of AMS commands is basically free form, and resembles REXX
or PL/1. The default statement margins are positions 2 through 72.
Any command statement may be continued from one line to the next by
following the last parameter in a line with a hyphen (-). A value
may be continued by immediately following it with a plus sign (+). A
comment may be embedded in the command statements by enclosing the
comment characters with /* and */. Blank lines may be included at
any point before, interspersed with, or following AMS commands.
Positional parameters are not optional and must precede all keyword
parameters. Keyword parameters can stand alone or they may have an
associated set of values or a subparameter list enclosed in
parentheses. Parameters, subparamenters, and values are separated
from one another by spaces, commas, or comment blocks.
TSO:- TIME SHARING OPERATING
Most IDCAMS commands such as DELETE, DEFINE, ALTER, BLDINDEX and
REPRO are also available as TSO commands. The syntax of TSO commands
is the same as the syntax of the corresponding IDCAMS commands,
although the rules for abbreviating key-words are somewhat different.
Note that Dynamic Allocation may use different defaults in TSO and in
batch; a cluster DEFINEd in TSO may be allocated on a different
volume than if it had been DEFINED in an IDCAMS batch job. Example of
a DEFINE command for a KSDS, using system defaults for VOLUME, SPACE
and RECSIZE:
DEFINE CL(NAME(TESTKSDS) KEYS(8 0))
The TSO/E ALLOCATE and FREE commands fully support VSAM. In
particular, ALLOCATE provide the same capability to allocate a VSAM
cluster as exists in the JCL; here is an example:
ALLOC DS(TESTKSDS) RECORG(KS) LRECL(500) KEYLEN(8) NEW
Similarly, the DELETE option of the FREE command can be used to
DELETE a previously allocated VSAM data set:
FREE DS(TESTKSDS) DELETE
The following VSAM-related TSO commands are available on the CBT
Tape.
¢ REVIEW is a free TSO command currently maintained by Greg
Price; REVIEW allows the user to display all sorts of data sets
(including VSAM and SMF) in full-screen mode. The source code for
REVIEW can be found in file 134 of the CBT Tape, and the load-module
in file 135.
¢ INITKSDS is a free TSO command written in assembler which
initialises a newly-defined KSDS by writing a dummy record into it,
then deleting it. INITKSDS is part of the author's contribution to
the CBT Tape.
The TSO RENAME command does not support VSAM data sets; ALTER should
be used instead.

MODAL COMMANDS
It is possible to include AMS commands to perform more than one
function in a single execution of the IDCAMS utility. Therefore, AMS
sets a return code following the execution of each command, and also
maintains a maximum return code value for each execution. AMS
commands are provided to interrogate these return codes and
conditionally execute command statements based on the return code set
during the execution of prior commands.
The return codes set by AMS can be interpreted as -
¢ 0 - Normal Completion - the functional command completed its
processing successfully
¢ 4 - Minor Error - processing is able to continue, but a minor
error occurred, causing a warming message to be issued
¢ 8 - Major Error - processing is able to continue, but a more
severe error occurred, causing major command specifications to be
bypassed
¢ 12 - Logical Error - generally, inconsistent parameters are
specified, causing the entire command to be bypassed
¢ 16 - Severe Error - an error of such severity occurred that
not only can the command causing the error not be completed, the
entire AMS command stream is flushed
IF - THEN - ELSE Structure:-
The statement structure used to conditionally execute commands based
upon the return code values is an IF - THEN - ELSE structure:
IF {LASTCC | MAXCC} {operator} {numeric value}
THEN {command} |
DO
{command set}
END
[ELSE {command} |
DO
{command set}
END]
In the IF statement, the return code to be tested is specified as one
of LASTCC or MAXCC, where LASTCC specifies the return code set during
the execution of the command just prior to the IF structure and MAXCC
specifies the largest return code value set during this execution if
IDCAMS. The {operator} is specified as one of the following
comparison operators:
EQ or = equal to
NE or ¬= not equal to
GT or > greater than
LT or < less than
GE or >= greater than or equal to
LE ro <= less than or equal to
Following the THEN keyword or the optional ELSE keyword, either a
single AMS command or a block of AMS commands enclosed in a DO/END
pair may be coded.
Null Commands:-
If a THEN keyword or ELSE keyword in an IF-THEN-ELSE structure is not
followed by an AMS functional command, or does not include a
continuation character indicating that a functional command follows
on the next line, then a null THEN or ELSE clause is assumed.
SET Command:-
The SET command may be used to set either the LASTCC value or the
MAXCC value to a specific value. Frequently the SET command is used
to reset the return code(s) to a value of 0 following an expected
warning level error condition.
Defining User Catalogs:-
Model syntax for the command:
DEFINE USERCATALOG
(NAME(entryname)
{ CYLINDERS(primary[ secondary]) |
RECORDS(primary[ secondary]) |
TRACKS(primary[ secondary]) }
VOLUME(volser)
[FILE(ddname)]
[TO(date) | FOR(days)]

[DATA (
[CYLINDERS(primary[ secondary]) |
RECORDS(primary[ secondary]) |
TRACKS(primary[ secondary])]
[INDEX (
[CYLINDERS(primary[ secondary]) |
RECORDS(primary[ secondary]) |
TRACKS(primary[ secondary])]
[CATALOG(mastercatname[/password])]
//
Space Allocation:-
Since a VSAM catalog owns the volume on which it resides, the VSAM
catalog must be the first VSAM object stored on a volume. When a
VSAM catalog is defined, AMS automatically defines a data space on
that volume and then allocates space for the VSAM catalog from within
that data space. Separate space allocation sub-parameters can be
specified for the index and data components. If space is allocated
only to the catalog as a whole, and separate SPACE sub-parameters are
not specified for the index and data components, the entire data
space (created automatically by AMS) is assigned to the catalog. In
this situation, it is then necessary to use a separate AMS function
command to define one or more data spaces owned by the catalog in
which to create future VSAM objects. If separate index and data
component space allocation sub-parameters are coded. The SPACE
parameter for the catalog as a whole defines the size of the data
space that is created, and the SPACE sub-parameters that are
specified for the data and index components determine the portion of
the data space that is assigned to the catalog. The remainder of the
data space becomes available for other VSAM objects. In most cases,
a cylinder of space will be adequate for catalogs.
The difference between the two catalogs created shows how using the
SPACE parameter on the optional DATA and INDEX components can be used
to define both the catalog and also leave available data space in a
single operation. If you look at the catalog listing in the SYSOUT
(following the AMS statements defining the user catalog UCMVS801),
you can see that under MVS801's data space extent information 13,259
tracks have been allocated to the data space, of which only 30 have
been used (to contain the user catalog). Compare this to the listing
for MVS802 and you can see that only 15 tracks were allocated for the
data space and all 15 have been used for the catalog. Before any
VSAM objects can be created on volume MVS802, a separate data space
will need to be defined.
Defining Data Space:-
Model syntax for the command:
DEFINE SPACE
({CANDIDATE
CYLINDERS(primary[ secondary]) |
RECORDS(primary[ secondary]) RECORDSIZE(average maximum) |
TRACKS(primary[ secondary])}
VOLUMES(volser[ volser...])
[FILE(ddname)]))
[CATALOG(catname[/password])]
A data space can be defined implicitly for a new VSAM object by
coding the UNIQUE parameter in the DEFINE command for the object.
This causes a new data space, of the requested size, to be defined
for the sole use of that object. From a data management viewpoint,
it is usually better to allocate an entire direct access storage
volume as VSAM data space and suballocate space for defined objects
from that space. The purpose of the DEFINE SPACE AMS command is to
allocate data space and place it under the control of a user catalog.

VSAM DATA SPACE ALLOCATION USING CATALOGING.

CURRENT APPLICATION DOMAIN
As part of a continual process of product improvement, CICS VSAM
Recovery for z/OS, Version 4.2 delivers important new features and
enhancements. Support for CICS Transaction Server for z/OS, Version
3.2 New support for IBM CICS Transaction Server for z/OS, Version 3.2
means that CICS VSAM Recovery now supports extended entry sequenced
data sets (ESDSs) used by CICS Transaction Server and also provides
support in batch through CICS VSAM Recovery batch logging.
Extended ESDSs can also be used in a combined environment, sharing
CICS VSAM record-level sharing (RLS) files with batch applications.
(This support requires APAR OA19958 for transactional VSAM services
[TVS].)
Enhanced backout-failure detection in CICS VSAM Recovery can now
operate in a threadsafe mode to complement the file-control
threadsafe support in CICS Transaction Server for z/OS, Version 3.2.
Integration with external backup products, including ABARS
Enhanced notification support helps improve control of the VSAM
environment by enabling file recovery through the IBM Aggregate
Backup and Recovery System (ABARS) function within the DFSMShsm„¢ and
DFSMSdss„¢ components of z/OS, and IDCAMS REPRO. CICS VSAM Recovery
also delivers a new NOTIFY utility for backing up a VSAM sphere
created by IBM or non-IBM products. It can then register information
about the backup in the recovery-control data set (RCDS) in CICS VSAM
Recovery. This feature makes backup information available for the
CICS VSAM Recovery ISPF dialog. Keep in mind, though, that you should
not use this utility for those backup products that already have
implemented CICS VSAM Recovery notification service, DFSMSdss,
DFSMShsm and ABARS.
CICS VSAM Recovery for z/OS includes a range of other features to
meet your business needs.
¢ Operations capabilities enable easier day-to-day use, such as
initiating backups and assistance with restores that require
preallocation of data sets such as IDCAMS REPRO.
¢ The backup process can be invoked from the CICS VSAM Recovery panel
interface, to allow both sharp and fuzzy (if enabled) backups to be
created.
¢ The target data-set can be allocated before it is restored from a
backup. This feature supports backups by REPRO (a DFSMS data-set copy
utility on the IBM z/OS® platform) and other backup types where
restore processing does not include allocating data sets.
¢ Automated recovery following failure helps reduce data-set
downtime.
¢ Authorization-management capabilities enable you to manage
authorization for specific tasks initiated through the panel
interface, based on user ID.
¢ Selective forward recovery enables you to remove specific unwanted
changes or eliminate bad data, by choosing or omitting records from
the forward-recovery logs that are used as input to your recovery
job.
¢ Change-accumulation processing sorts forward-recovery records into
change-accumulation data sets, which can speed up forward recovery if
individual VSAM records have been updated many times.
¢ Commands and disaster-recovery reports enable you to review and
validate what is needed at a remote disaster-recovery site.
¢ The ability to test forward-recovery and backout procedures enables
you to test recovery processes without affecting production data.
¢ The ability to manage log streams with powerful functions helps
simplify recovery tasks.
Use the System z tools portfolio:-
CICS VSAM Recovery for z/OS is part of an extensive portfolio of
System z tools that can help you to modernize and transform existing
CICS and other System z applications whether your goal is to:
¢ Develop and deploy new workloads to take advantage of the unique
performance, availability, security and cost benefits of the System z
platform.
¢ Increase your responsiveness to business requirements by
modernizing your mainframe platform.
¢ Optimize management of your IT environment, helping to reduce cost
and complexity while improving governance and compliance

FUTURE PROSPECTS
MVS took a major step forward in fault-tolerance that IBM called
'software recovery'. IBM decided to do this after years of practical
real-world experience with MVT in the business world - system
failures were now having major impacts on customer businesses and IBM
decided to take a major design jump, to assume that despite the very
best software development and testing techniques, that 'problems WILL
occur'. This profound assumption was pivotal in adding great
percentages of fault-tolerance code to the system, but likely
contributed to the system's success in tolerating software and
hardware failures. Statistical information is hard to come by to
prove the value of these design features (how can you measure
'prevented' or 'recovered' problems?), but IBM has, in many
dimensions, enhanced these fault-tolerant software recovery and rapid
problem resolution features, over time.
Thus, with each and every error: diagnostic data was captured, an
attempt was made to perform a repair and keep the system up. The
worst thing possible was to take down a user address space (a 'job')
in the case of unrepaired errors. Although it was an initial design
point, it was not until the most recent MVS version (z/OS), that
recovery program was not only guaranteed its own recovery routine,
but each recovery routine now has its own recovery routine.
This recovery structure was embedded in the basic MVS control
program, and programming facilities are available and used by
application program developers and 3rd party developers.
Multiple copies of MVS (or other IBM operating systems) could share
the same machine if that machine was controlled by VM/370 - in this
case VM/370 was the real operating system and regarded the "guest"
operating systems as applications with unusually high privileges. As
a result of later hardware enhancements one instance of an operating
system (either MVS, or VM with guests, or other) could also occupy a
Logical Partition (LPAR) instead of an entire physical system.
Multiple MVS instances can be organized and collectively administered
in a structure called a systems complex or sysplex, introduced in
September, 1990. Instances interoperate through a software component
called a Cross-system Coupling Facility (XCF) and a hardware
component called a Hardware Coupling Facility (CF or Integrated
Coupling Facility, ICF, if co-located on the same mainframe
hardware). Multiple sysplexes can be joined via standard network
protocols such as IBM's proprietary Systems Network Architecture
(SNA) or, more recently, viaTCP/IP.
The z/OS operating system (MVS' most recent descendant) also has
native support to execute POSIX applications.
MVS originally supported 24-bit addressing (i.e. up to 16MB). As the
underlying hardware progressed it supported 31-bit (XA and ESA; up to
2048MB) and now (as z/OS) 64-bit addressing. Two of the most
significant reasons for the rapid upgrade to 31-bit addressing were:
the growth of large transaction-processing networks, mostly
controlled by CICS, which ran in a single address space; theDB2
relational database management system needed more than 8MB of
application address space in order to run efficiently (early versions
were configured into two address spaces which communicated via the
shared virtual area, but this imposed a significant overhead since
all such communications had to be transmitted via the operating
system).
The main user interfaces to MVS are: Job Control Language (JCL),
which was originally designed for batch processing but from the 1970s
onwards was also used to start and allocate resources to long-running
interactive jobs such CICS; and TSO (Time Sharing Option), the
interactive time-sharing interface, which was mainly used to run
development tools and a few end-user information systems. ISPF is a
TSO application for users on 3270-family terminals (and later, on VM
as well) which allows the user to accomplish the same tasks as TSO's
command line but in a menu and form oriented manner, and with a full
screen editor and file browser. TSO's basic interface is command
line, although facilities were added later for creating form-driven
interfaces).

PERFORMANCE IMPROVISATION
Your system programmer is most likely responsible for tuning the
performance of COBOL and VSAM. As an application programmer, you can
control the aspects of VSAM that are listed below.
Table 1. Methods for improving VSAM performance
Aspect of VSAM What you can do Rationale and comments
Invoking access methods service Build your alternate indexes in
advance, using IDCAMS.
Buffering For sequential access, request more data buffers; for
random access, request more index buffers. Specify both BUFND and
BUFNI when ACCESS IS DYNAMIC.
Avoid coding additional buffers unless your application will run
interactively; then code buffers only when response-time problems
arise that might be caused by delays in input and output. The
default is one index (BUFNI) and two data buffers (BUFND).
Loading records, using access methods services Use the access
methods service REPRO command when:
¢ The target indexed data set already contains records.
¢ The input sequential data set contains records to be updated
or inserted into the indexed data set.
If you use a COBOL program to load the file, use OPEN OUTPUT and
ACCESS SEQUENTIAL. The REPRO command can update an indexed data
set as fast or faster than any COBOL program under these conditions.
File access modes For best performance, access records
sequentially. Dynamic access is less efficient than sequential
access, but more efficient than random access. Random access results
in increased EXCPs because VSAM must access the index for each
request.
Key design Design the key in the records so that the high-order
portion is relatively constant and the low-order portion changes
often. This method compresses the key best.
Multiple alternate indexes Avoid using multiple alternate
indexes. Updates must be applied through the primary paths and
are reflected through multiple alternate paths, perhaps slowing
performance.
Relative file organization Use VSAM fixed-length relative data
sets rather than VSAM variable-length relative data sets.
Although not as space efficient, VSAM fixed-length relative data sets
are more runtime efficient than VSAM variable-length relative data
sets.
Control interval sizes (CISZ) Provide your system programmer with
information about the data access and future growth of your VSAM data
sets. From this information, your system programmer can determine the
best control interval size (CISZ) and FREESPACE size (FSPC).
Choose proper values for CISZ and FSPC to minimize control area (CA)
splits. You can diagnose the current number of CA splits by issuing
the LISTCAT ALL command on the cluster, and then compress (using
EXPORT,IMPORT, or REPRO) the cluster to omit all CA splits
periodically. VSAM calculates CISZ to best fit the direct-access
storage device (DASD) usage al