How Data Sets Are Processed - IBM Mainframe

Now that you know about the basic techniques MVS uses to store data sets, you are ready to see how user jobs and application programs process those data sets. In general, an application program that is part of a user job goes through three phases as it processes a data set—allocation, processing, and deallocation.

When you request access to an existing data set, MVS uses information you provide in your JCL along with information in the data set label and catalog to locate the data set. Similarly, if you are creating a new data set, MVS uses the information you provide to locate and set aside space for the data set. The process of locating an existing data Set or space for a new data set and preparing the system control blocks needed to use the data set is called allocution.

Under MVS, allocation occurs at three levels: first, a unit (device) is selected and allocated; then, a volume is allocated; and finally, a data set on that volume is allocated. The way MVS allocates units, volumes, and data sets affects how you request them, so you need a basic understanding of how allocation works at each level.

How MVS Allocates Units

When you request access to a data set, MVS determines which unit, or device, the data set resides on or will reside on. Then, that unit is allocated to your job. Before we see how MVS determines which unit to allocate, you should realize that in some cases, allocating a unit to your job means that no other jobs on the system can use that unit until your job is finished with it. Usually, that happens when you allocate devices like tape drives that, by their nature, cannot be shared. In contrast, a DASD unit is sharable, so it can be allocated to more than one job at once.

How MVS selects an appropriate unit for your allocation depends on how you request the unit. The simplest, but least used, way to request a unit is to specify the unit's device address. Each device in a system has a unique three-digit hexadecimal address, so requesting a unit by address causes the device at that address to be allocated.

Instead of specifying a particular device address, you are more likely to request a unit by specifying a generic name or a group name. Both have a similar effect: They indicate that you want one of a group of devices rather than a particular device. From that group, MVS uses various criteria to select the most appropriate unit to allocate. A generic name is an IBM-supplied name that indicates a device type, like 3350 or 3380; all of the devices of a particular type are included when you specify a generic name.

A group name, sometimes called an esoteric name, is a more flexible way to group devices. Each installation creates its own group names and associates specific devices with each name. One group name, SYSALLDA, is always available. It identifies every DASD unit on the system. Almost all MVS installations define a group named SYSDA, which identifies the direct access devices that are available for general usage. Similarly, most MVS shops define a group named TAPE, which identifies all of the installation's tape drives, regardless of their type. You will have to check with your installation to find out what other group names besides SYSALLDA, SYSDA, and TAPE you can use.

How MVS Allocates Volumes

There are two ways to request a volume. When you use a specific volume request, you identify a particular volume by specifying its vol-ser or letting MVS obtain the volume identification from a catalog.

When you use a non-specific volume request, you do not specify a vol-ser. Instead, you let MVS select the volume on which a new data set will be created (non-specific volume requests are not valid for existing data sets).

If you issue a specific volume request, MVS searches all of the devices that match the unit you requested. If it finds the volume, that volume and unit are allocated to your job. If MVS does not find the volume, it selects one of the units and instructs the operator to mount the volume on that unit. When the operator has mounted the volume, the unit and the volume are allocated to your job.

In the case of DASD with non-removable volumes (3350,3375, 3380, or 3390), each unit always has the same volume mounted. As a result, coding a specific volume request for one of these DASDs is similar to requesting a specific unit by specifying its device address. In most cases, though, you're better off specifying a vol-ser than a unit address.

How MVS Allocates Data Sets

Once the unit and volume for an existing data set have been allocated, the data set's file labels are read to ensure that the requested data set exists. For a new data set, file labels are created and, if the data set resides on DASD, space is allocated to the data set and the VTOC is updated to indicate the allocation. To allocate a new data set, you must supply the characteristics of the data such as the data set's organization, record and block size, and the amount of space the data set will require.

An important specification that determines how a non-VSAM data set is allocated is the file's disposition. Disposition, coded in the JCL statement that identifies the file, indicates whether the file already exists or is being created. In addition, for an existing file, disposition indicates whether the file can be shared by other jobs or should be allocated for exclusive use (DASD only). If you code a disposition for a VSAM file, it is ignored unless you're running under MVS/ESA and SMS is activated.

Another important factor that influences how a non-VSAM data set is allocated is whether the file is permanent or temporary. A permanent data set is one that existed before the job began or will be retained after the job ends. In contrast, a temporary data set is one that, is created and deleted within a single job. A permanent file must always be given a data set name, but a temporary file does not have to have a name.

Once a data set (along with its unit and volume) is allocated, application programs can process it. To do that, special operating system facilities called access methods are used.

How the Access Methods Process Data Sets

An access method is an interface between an application program and the physical operations of storage devices. When you code an I/O instruction in an application program, you actually invoke an access method, which in turn issues the proper I/O instructions to access the I/O device. Access methods relieve you of having to handle the complex technical details of using I/O devices and maintaining data sets in the correct format.

Access methods can be divided into three categories—basic, queued, and VSAM. A basic access method provides the lowest level of support for a data set type. In particular, the Basic Sequential Access Method, or BSAM, provides low-level support for sequential data sets, the Basic Indexed Sequential Access Method, or BISAM, provides low-level support for indexed sequential files, and the Basic Direct Access Method, or BDAM, provides low-level support for direct files.

The queued access methods provide a higher level of support for sequential and indexed sequential files. They let you process those files on a sequential basis in an efficient way by providing sophisticated processing techniques that anticipate your next I/O operation. For sequential files or members of partitioned data sets, the Queued Sequential Access Method, or QSAM, is used; the Queued Indexed Sequential Access Method, or QISAM, is used for indexed files. There is no queued access method for direct data sets.

VSAM provides access method support for its key-sequenced, entry-sequenced, and relative-record data sets. Under VSAM, techniques similar to those used by both basic and queued access methods are used.

Open Processing

Before a program can issue I/O instructions for a file, it must issue an OPEN instruction to establish a connection between a program, a data set, and an appropriate access method. For non-VSAM files, that connection is made through a special control block called a Data Control Block, or DCB. For VSAM files, a control block called the Access method Control Block, or ACB, has a similar function. Both the DCB and the ACB are simply tables in storage that contain vital information about the status of a data set as it is processed. The main purpose of OPEN processing is to initialize the DCB or ACB.

When a data set is opened, DCB/ACB information comes from one of three sources: the data set's label or catalog entry, the JCL, and the program itself. Usually, as little information as possible is specified in the program. That way, the program does not have to be changed whenever a minor change is made to the characteristics of the data set. You can use any of several open modes when you open a data set. In input mode, records can be read but not written to the data set; the file must exist before it is opened in this mode. In output mode, records can be written but not read. If the file does not exist, a new one is created; if it already exists, the records are added to the end of the file. In I/O mode, records can be both read and written; the file must already exist. And there are other open modes that provide other ways to process files.

I/O Requests

When a program issues instructions to perform I/O operations on a data set, those instructions are processed by one of the access methods. In general, there are four kinds of I/O operations you can issue: read a record, write a record, update (or rewrite) a record, and delete a record. During processing, most access methods handle blocking and deblocking so that the program processes one record at a time, even though the data is stored in blocks that may consist of more than one record, the access method also maintains other elements of a data set's structure, such as the index of an indexed sequential data set or a VSAM key-sequenced data set.

CLOSE Processing

When a program is finished processing a data set, it issues a CLOSE instruction to disconnect itself from the file. If a file is not properly closed, you may not be able to OPEN it the next time you need to process it. Closing a file does not deallocate it. As a result, an application program can open and close a data set several times without worrying about the file being allocated and deallocated each time.

Deallocation

Just as data sets must be allocated before they can be processed, they must be deallocated after they are processed. You do not have to do anything explicitly to deallocate a file; each file is automatically deallocated when a job is finished with it. However, there is one important factor you can influence when a data set is deallocated—the file's disposition.

Disposition indicates what MVS does with a non-VSAM file when it is deallocated. The disposition of a temporary file indicates whether the file should be retained until the end of the job or deleted immediately. For a permanent file, disposition indicates whether the file should be kept or deleted. In addition, a permanent file's disposition indicates whether an entry for the file should be retained in the master catalog or a user catalog. Once again, if you specify a disposition for a VSAM file, it is ignored unless you are running under MVS/ESA and SMS is activated.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Mainframe Topics