JCL: Working with Data Sets
Unit 1. Concatenating Data Sets
In this course, you will learn about data set information, including defining and working with generation data sets and storing data.
In this unit, you will learn how to concatenate sequential non-VSAM data sets. The rules for this process apply to all the different types of sequential data sets members of partitioned data sets (PDSs and PDSEs) permanent data sets temporary data sets, as well as all the different devices tape disk. Please note that HFS data sets cannot be concatenated.
After completing this unit, you should be able to:
- Concatenate permanent data sets
- Concatenate data sets on different devices
- Concatenate libraries
Topic 1.1: Concatenating Permanent Data Sets
*ConcatenationAt times, you might want your program to read in sequence several input data sets as if they were one.
You can accomplish this without physically putting the data in one data set. You do this by concatenating the data sets in your JCL code.
Concatenation has meaning only for sequentially processed non-VSAM data sets.
*Using the IEBGENER Utility
Say for example that your department receives marketing data on tape from the western, eastern and northern regions. You need to copy the data from all three tapes to one data set on disk.
To accomplish this task, you use a utility, such as IEBGENER, to copy the input data to an output data set. The input data is made up of the three concatenated tape files.
First, look at the DD statements for the concatenated files. Then you'll see the JCL for the entire job.
//SYSUT1 DD DSN=WEST.REGION,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
// DD DSN=EAST.REGION,UNIT=TAPE,VOL=SER=TAPE2,DISP=OLD
// DD DSN=NORTH.REGION,UNIT=TAPE,VOL=SER=TAPE3,DISP=OLD
*Blank DD Statements
The input to IEBGENER is supplied on SYSUT1.
Notice that SYSUT1 is followed by two DD statements with blank ddnames. The blank ddname indicates concatenation.
Now look at the rules for concatenating data sets.
//SYSUT1 DD DSN=WEST.REGION,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
// DD DSN=EAST.REGION,UNIT=TAPE,VOL=SER=TAPE2,DISP=OLD
// DD DSN=NORTH.REGION,UNIT=TAPE,VOL=SER=TAPE3,DISP=OLD
*Concatenation Rules
Rules for concatenating data sets include the following:
- Code a DD statement for each data set in the sequence it is to be read.
- Use a ddname for the first data set only. Do not code ddnames for the other data sets. The data sets containing blank ddnames must immediately follow the first DD statement.
//SYSUT1 DD DSN=WEST.REGION,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
// DD DSN=EAST.REGION,UNIT=TAPE,VOL=SER=TAPE2,DISP=OLD
// DD DSN=NORTH.REGION,UNIT=TAPE,VOL=SER=TAPE3,DISP=OLD
*More Concatenation Rules
Rules for concatenating data sets include the following:
- Ensure that all data sets in the concatenation have compatible record formats. For example, if the first data set has fixed-length records, all data sets in the concatenation must have fixed-length records. You can't concatenate fixed-length record data sets with variable-length record data sets.
- Ensure that all data sets in the concatenation have the same logical record lengths. They can have different block sizes, but in some cases the data set with the largest block size must be first. It's a good idea to put the largest first as a default.
//SYSUT1 DD DSN=WEST.REGION,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
// DD DSN=EAST.REGION,UNIT=TAPE,VOL=SER=TAPE2,DISP=OLD
// DD DSN=NORTH.REGION,UNIT=TAPE,VOL=SER=TAPE3,DISP=OLD
*Assumptions In the Marketing Data Example
This example assumes the following:
1. The first tape has the volume ID TAPE1. The data set it contains is named WEST.REGION.
2. The second tape's ID is TAPE2. Its data set is named EAST.REGION.
3. The third tape's ID is TAPE3. The data set on it is NORTH.REGION.
//SYSUT1 DD DSN=WEST.REGION,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
// DD DSN=EAST.REGION,UNIT=TAPE,VOL=SER=TAPE2,DISP=OLD
// DD DSN=NORTH.REGION,UNIT=TAPE,VOL=SER=TAPE3,DISP=OLD
*More Assumptions In the Marketing Data Example
This example assumes the following:
4. On all tapes the data sets are the first in sequence. That is, the default LABEL=(1,SL) is assumed.
5. All tapes are standard labeled tapes. That is, the volume IDs and the physical characteristics (DCB) of each data set are recorded on them.
//MKT JOB
// EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=A
//SYSIN DD DUMMY
//SYSUT1 DD DSN=WEST.REGION,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
// DD DSN=EAST.REGION,UNIT=TAPE,VOL=SER=TAPE2,DISP=OLD
// DD DSN=NORTH.REGION,UNIT=TAPE,VOL=SER=TAPE3,DISP=OLD
//SYSUT2 DD DSN=MARKET.FILE,DISP=(NEW,CATLG,DELETE),
// (other parameters as needed)
*The Entire Job
You saw the DD statements for the concatenated files. Now, here's the entire job necessary to run the IEBGENER.
The utility IEBGENER copies one input data set to one output data set. The input data set consists of the concatenated tape files.
//MKT JOB
// EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=A
//SYSIN DD DUMMY
//SYSUT1 DD DSN=WEST.REGION,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
// DD DSN=EAST.REGION,UNIT=TAPE,VOL=SER=TAPE2,DISP=OLD
// DD DSN=NORTH.REGION,UNIT=TAPE,VOL=SER=TAPE3,DISP=OLD
//SYSUT2 DD DSN=MARKET.FILE,DISP=(NEW,CATLG,DELETE),
// (other parameters as needed)
*The Output Data Set
The output data set is named MARKET.FILE. We did not code all the DD statement parameters for this data set because they differ for SMS and non-SMS-managed data sets.
*All the Rules for Concatenation
Let's state all the rules for concatenation:
1. The maximum number of data sets that can be concatenated is 255.
2. Code a DD statement for each data set in the sequence they are to be read.
3. Use a ddname for the first data set only. Do not code ddnames on the following concatenated DD statements.
4. If the data sets have different block sizes, the one with the largest block size should be first.
5. If the data sets are on tape, each tape must be standard labeled.
6. The data sets must have compatible record formats and the same record lengths.
*Get Ready!
On the next several pages, you'll complete the input DD statement for an IEBGENER jobstream that concatenates three data sets.
Topic 1.2: Concatenating Data Sets on Different Devices
*What Else Do the Rules Apply To?You've seen the rules for concatenating sequential data sets. Although the examples you saw dealt with permanent data sets, the rules also apply to ...
- All the different types of sequential data sets members of partitioned data sets (PDSs and PDSEs) permanent data sets temporary data sets
//SYSUT1 DD DSN=WEST.REGION,UNIT=TAPE,
// VOL=SER=TAPE1,DISP=OLD
// DD DSN=MY.LIBR(MEMBER1),DISP=OLD
// DD DSN=&&TEMP,DISP=(OLD,PASS)
*Concatenating Permanent and Temporary Data Sets
Here a tape data set WEST.REGION is concatenated with a PDS member MY.LIBR(MEMBER1) on disk.
The example also includes a concatenation of a permanent data set WEST.REGION with a temporary data set &&TEMP.
WEST.REGION is read first, then member MEMBER1 in MY.LIBR and finally the data set &&TEMP.
The important point here is that all of these data sets are sequential.
*The Next Step
You've concatenated permanent and temporary files.
You've also concatenated data sets on different devices such as tape and disk.
The last concept to examine in this unit on concatenation is concatenating libraries or partitioned data sets (PDSs and PDSEs).
Topic 1.3: Concatenating Libraries
*Why Concatenate Libraries?Concatenation of libraries is useful for testing programs.
For example, say you changed a program in the billing system and you must test it.
- You put the changed program in PROG.TESTLIB.
- All other programs in the jobstream are unchanged and can be accessed from the production library, BILL.PRODLIB.
*Making Sure the Test Library is Searched First
By concatenating the libraries with this JCL ...
//JOBLIB DD DSN=PROG.TESTLIB,DISP=SHR
// DD DSN=BILL.PRODLIB,DISP=SHR
You can ensure that PROG.TESTLIB is always searched first. Your test copy of the program is found there rather than in the production library.
All programs not found in PROG.TESTLIB will come from BILL.PRODLIB.
*Rules for Concatenating Libraries
When concatenating libraries, follow the rules introduced earlier except ...
- Use the library name for the DSN and code a disposition of share (DISP=SHR)
- The maximum number of PDSs and PDSEs that can be concatenated depends on the total number of extents used by the data sets. A discussion of calculating the maximum is beyond the scope of this course.
To refresh your memory, the next screen shows you the rules for concatenation again.
*All the Rules for Concatenation
Let's state all the rules for concatenation:
1. The maximum number of data sets that can be concatenated is 255. The maximum number of PDSs and PDSEs that can be concatenated depends on the total number of extents used by the data sets.
2. Code a DD statement for each data set in the sequence it is to be read.
3. Use a ddname for the first data set only. Do not code ddnames on the following concatenated DD statements.
4. If the data sets have different block sizes, the one with the largest block size should be first.
5. If the data sets are on tape, each tape must be standard labeled.
6. The data sets must have compatible record formats and the same record lengths.
Topic 1.4: Unit 1 Summary
The following points were covered in this unit:- Concatenation allows a program to read in sequence several input data sets
as if they were one.
- Concatenation has meaning only for sequentially processed non-VSAM data
sets.
- The rules for concatenation include the following: The maximum number of
data sets that can be concatenated is 255. Code a DD statement for
each data set in the sequence it is to be read. Use a ddname for the first
data set only. Do not code ddnames on the following concatenated DD
statements. If the data sets have different block sizes, the one with the
largest block size should be first. If the data sets are on tape, each tape
must be standard labeled. The data sets must have compatible record formats
and the same record lengths.
- When concatenating libraries, follow the rules introduced earlier except:
Use the library name for the DSN and code a disposition of share
(DISP=SHR). The maximum number of PDSs and PDSEs
that can be concatenated depends on the total number of extents used by the
data sets.
- Another consideration is to place the DD statements in the order the libraries are to be searched for retrieval.
Unit 2. Defining Generation Data Sets
In this unit, you will learn about generation data sets. More specifically, you will learn how to define a generation data group or GDG base entry.After completing this unit, you should be able to:
- Understand generation data sets
- Define GDG base entries
Topic 2.1: Understanding Generation Data Sets
*Version ControlIn many cases, you might need to maintain several versions of a data set.
For example, you might have a data set containing information about daily orders (DSN=ORDERS.DAILY).
Not only do you need to maintain a version for today, but you also need a version for yesterday, the day before yesterday, and so on.
These versions might be used for backup and archive purposes. Each data set in the group is chronologically and functionally related to the other data sets.
*Keeping Track of Multiple Versions
One way to keep track of multiple versions of a data set is to name each version in such a way that you always know which one is the most recent copy, which one is the previous copy, and so on.
The operating system offers a way to automate and simplify tracking multiple versions of a data set through the use of a generation data group or GDG.
A generation data group (GDG) is a collection of cataloged data sets that are chronologically and functionally related. Each data set in a GDG is called a generation data set.
*Relative Generation Numbers
With a GDG, you refer to each generation of a data set using its base GDG name, followed by a relative generation number in parentheses. If, for example, the name of your data set is ORDERS.DAILY:
- Refer to the latest generation ORDERS.DAILY(0) (today's orders)
by using 0 (zero) as the relative generation number.
- Refer to the previous generation ORDERS.DAILY(-1) (yesterday's
orders) by using -1 (minus one) as the relative generation
number.
- Refer to the generation before that ORDERS.DAILY(-2) (day before yesterday's orders) by using -2 (minus two) as the relative generation number.
*A Note About Generation Data Sets
One more general note before examining how to define a base entry for a GDG ...
Generation data sets are:
- Cataloged non-VSAM sequential or direct access data sets.
- Stored on direct access volumes. (If you're not using SMS to manage your data sets, generation data sets can also be stored on tape.)
Next, we'll look at how to define a GDG base entry.
Topic 2.2: Defining GDG Base Entries
GDG Base EntriesEach GDG is represented by a GDG base entry which is stored in a catalog. The base entry must be defined before you create and catalog any generation data sets.
The base entry specifies:
- The base entry name, which is the name you use in the DSN
parameter to refer to the generation data set.
- The maximum number of generations that the operating system should
maintain for this GDG.
- The action to be taken when the maximum number of generations is reached and another generation needs to be cataloged.
*Selecting a Catalog
The catalog in which you define a GDG base entry depends on whether your installation is using SMS to manage its data sets:
- For SMS-managed data sets, you must define the base entry in an integrated catalog facility (ICF) catalog.
- For non-SMS-managed data sets, you can define the base entry in an integrated catalog facility catalog, a VSAM catalog or a CVOL. (The recommended approach, however, is to use an integrated catalog facility catalog.)
*Integrated Catalog Facility Catalog
Because using an integrated catalog facility catalog is common to both SMS and non-SMS managed data sets, you'll learn how to use this approach first.
Then, if you're not using SMS, you'll be given the option to learn how to define a base entry in a VSAM catalog or in a CVOL.
The following screens show how to define a GDG base entry in an integrated catalog facility catalog.
//DEFINE JOB
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
DEFINE GENERATIONDATAGROUP -
(NAME(ACCOUNT.MASTER) -
LIMIT(3) -
NOEMPTY -
SCRATCH)
/*
*Defining the GDG Base Entry for ACCOUNT.MASTER
You use the Access Method Services utility, IDCAMS, to define a GDG base entry in an integrated catalog facility catalog. The example above shows how to define the GDG base entry ACCOUNT.MASTER.
This job defines the GDG base entry for ACCOUNT.MASTER in an integrated catalog facility catalog.
NAME and LIMIT Parameters
The control statement,
DEFINE GENERATIONDATAGROUP -
NOEMPTY -
SCRATCH)
specifies that a GDG base entry is to be defined. The parameters for this statement are listed below.
| NAME | specifies the GDG base name. In this example, ACCOUNT.MASTER. |
| LIMIT | indicates the maximum number of generations to be maintained for this GDG. This can be a value from 1 to 255. In the example above, the limit is set to 3 generations. |
EMPTY and NOEMPTY Parameters
The control statement,
DEFINE GENERATIONDATAGROUP -
(NAME(ACCOUNT.MASTER) -
LIMIT(3) -
SCRATCH)
specifies that a GDG base entry is to be defined. The parameters for this statement are discussed below.
| EMPTY | specifies that all generation data sets are to be uncataloged when the maximum (LIMIT) is reached and another generation needs to be cataloged. |
| NOEMPTY | specifies that only the oldest generation data set is to be uncataloged when the maximum (LIMIT) is reached and another generation needs to be cataloged. In the example, NOEMPTY is specified. This means that, when the system tries to catalog the fourth generation, it will first uncatalog the oldest, or (-3), generation. |
SCRATCH and NOSCRATCH Parameters
The control statement,
DEFINE GENERATIONDATAGROUP -
(NAME(ACCOUNT.MASTER) -
LIMIT(3) -
NOEMPTY -
specifies that a GDG base entry is to be defined. The parameters for this statement are discussed below.
| SCRATCH | deletes the generation data set when it is uncataloged. SCRATCH is used in the example above. |
| NOSCRATCH | does not delete the generation data set when it is uncataloged. |
*Other Parameters
There are a few other parameters that can be used when you define a GDG base entry. Because these parameters are not frequently used, we only mention them here.
| OWNER | identifies the generation data set's owner. |
| TO and FOR | specifies the retention period. |
| CATALOG | identifies the catalog in which the GDG is to be defined. Do not use this parameter for SMS-managed data sets unless you have special authority. Instead, allow the system to determine the catalog. |
*More Options
The IDCAMS coding you just learned defines a GDG base entry in an integrated catalog facility catalog.
If your data sets are managed by SMS, this is the only option available.
If your data sets are not managed by SMS, there are other options for defining a GDG base entry. You can define the entry in a VSAM catalog or in a CVOL.
*Using VSAM Catalogs
The IDCAMS DEFINE statement you just learned is also used to define a GDG base entry in a VSAM catalog.
While the basic coding is the same, there are a few points you should understand if you plan to use a VSAM catalog:
- You can use the CATALOG parameter in the DEFINE GENERATIONDATAGROUP control statement.
- If you omit the CATALOG parameter, where will your GDG base entry be defined?
*Understanding the CATALOG Parameter
The CATALOG parameter is optional. You only need to code it if you want to direct the system to define the base entry in a specific VSAM catalog.
If you omit this parameter, the system uses a specific selection order to determine where to put the GDG base entry. Here, we'll briefly review the major points of this selection order.
*The Order of Operations
The system determines which catalog to use based on the following sequence:
1. The catalog specified in the CATALOG parameter if coded.
2. The catalog specified in the a STEPCAT DD statement if coded.
3. The catalog specified in the a JOBCAT DD statement if coded.
4. An integrated catalog facility catalog if your GDG base entry name is qualified and one or more of the qualifiers are the same as the name or the alias of an integrated catalog facility catalog.
5. A VSAM user catalog if your GDG base entry name is qualified and the first qualifier (high-level index) is the same as the name or the alias of a VSAM user catalog.
6. The master catalog if no catalog has been identified, either explicitly or implicitly.
*Using IEHPROGM to Define a GDG Base Entry
You can also use IEHPROGM to define a GDG base entry. When you use this utility, you define the base entry in a CVOL.
As you learn how to use IEHPROGM, you'll notice a number of similarities between its parameters and those used for IDCAMS. This should make it easier for you to learn IEHPROGM.
Before you specify which catalog to use for a GDG base entry, make sure to refer to the standards and guidelines used in your installation.
If you read the IBM documentation for IEHPROGM, you'll see the term "generation index" used instead of "GDG base entry." These terms are synonymous. Throughout this section, we'll use the term "GDG base entry."
This will make it easier for you to relate the material you learn here to the material you learned earlier in this unit.
//DFNC JOB
//STEP1 EXEC
//SYSPRINT DD SYSOUT=A
//ANYNAME DD UNIT=DISK,VOL=SER=DISK01,DISP=OLD
//SYSIN DD *
*Something to Keep In Mind
In this example, IEHPROGM defines a GDG base entry in a CVOL. Assume that the data set name's high-level index ACCOUNT points to the CVOL on disk volume DISK01.
The BLDG control statement is discussed in detail on subsequent screens. Briefly, this job creates a base entry for ACCOUNT.MASTER, which allows for three generations.
//DFNC JOB
//STEP1 EXEC PGM=IEHPROGM
BLDG INDEX=ACCOUNT.MASTER,ENTRIES=3,CVOL=DISK=DISK01
*Input/Output Commands
The results from IEHPROGM's execution are placed on SYSPRINT. A DD statement with an arbitrary name (ANYNAME) is required to provide access to the volume where the CVOL resides (DISK01). The input commands are supplied on SYSIN.
*The BLDG Control Statement
The generic statement to define a GDG base entry in a CVOL is
BLDG INDEX=index,ENTRIES=n<,CVOL=device type=volume name>,EMPTY<,DELETE>
In the previous example, you saw the statement
BLDG INDEX=ACCOUNT.MASTER,ENTRIES=3,CVOL=DISK=DISK01
| BLDG | specifies that a base entry is to be defined. |
| INDEX | specifies the GDG base entry name. |
| ENTRIES | indicates the maximum number of generations. The largest number you can specify is 255. |
| CVOL | identifies the device-type and volume name of the volume that contains the CVOL. This parameter, though shown above, is not required since you assumed the high-level index ACCOUNT points to the CVOL identified in the arbitrary DD statement. |
*The EMPTY and DELETE Parameters
The generic statement to define a GDG base entry in a CVOL is
BLDG INDEX=index,ENTRIES=n<,CVOL=device type=volume name>,EMPTY<,DELETE>
Two parameters were not specified in the example:
BLDG INDEX=ACCOUNT.MASTER,ENTRIES=3,CVOL=DISK=DISK01
| EMPTY | uncatalogs all the generations when the maximum is reached and another generation needs to be cataloged. By not specifying EMPTY, you take the default. The default uncatalogs the oldest generation when the maximum is reached. |
| DELETE | deletes the generation data set from the disk volume where it resides when a generation is uncataloged. This does not apply if a generation resides on tape. Data sets on tape are not deleted; they are written over. By not specifying DELETE, the generation data set is uncataloged but not deleted. |
//DFNC JOB
//STEP1 EXEC PGM=IEHPROGM
//SYSPRINT DD SYSOUT=A
//ANYNAME DD UNIT=DISK,VOL=SER=DISK01,DISP=OLD
//SYSIN DD *
BLDG INDEX=ACCOUNT.MASTER,ENTRIES=3,CVOL=DISK=DISK01
*If the Command Doesn't Fit...
If all the parameters for an IEHPROGM command cannot fit on one line:
- End the first line with a comma.
- Place any non-blank character in column 72.
- Resume the remainder of the parameters in column 16 of the next line.
Topic 2.3: Unit 2 Summary
The following points were covered in this unit:- A generation data group (GDG) is a collection of cataloged data
sets that are chronologically and functionally related. Each data set in a
GDG is called a generation data set.
- With a GDG, you refer to each generation of a data set using its
base GDG name, followed by a relative generation number in
parentheses. Each GDG is represented by a GDG
base entry which is stored in a catalog. The base entry must be defined before
you create and catalog any generation data sets.
- How to use the Access Method Services utility, IDCAMS, to define
a GDG base entry in an integrated catalog facility catalog.
- How to use the IDCAMS DEFINE statement to define a GDG
base entry in a VSAM catalog.
- How to use IEHPROGM to define a GDG base entry. When you use this utility, you define the base entry in a CVOL.
Unit 3. Creating Generation Data Sets
In this unit, you will learn how to create and catalog generation data sets.
After completing this unit, you should be able to:
- Create new generation data sets
Topic 3.1: Creating Generation Data Sets
*Referring to Previous GenerationsIn the last unit, you learned that a generation data set is referred to by its base entry name followed by a relative generation number in parentheses.
For example, ACCOUNT.MASTER(0) is the latest generation, ACCOUNT.MASTER(-1) is the previous generation, and so on.
Topic 3.1.1: Coding the DSN Parameter
*Creating New GenerationsWhen you create a generation data set, you refer to it using its base entry name followed by a positive relative generation number.
For example, you use ACCOUNT.MASTER (+1) to create a new generation of the GDG named ACCOUNT.MASTER.
Generation data sets names can be a maximum of 35 characters long, including the periods and excluding the relative generation number.
//CREATE JOB
//STEP1 EXEC PGM=CREATE
//IN1 DD DSN=INFILE1.TST,DISP=OLD
//OUT1 DD DSN=ACCOUNT.MASTER(+1),DISP=(NEW,CATLG),
:
:
//STEP2 EXEC PGM=CREATE
//IN2 DD DSN=INFILE2.TST,DISP=OLD
//OUT2 DD DSN=ACCOUNT.MASTER(+2),DISP=(NEW,CATLG),
:
:
*Creating Multiple Generations
You can create more than one generation of the same GDG in a job. The partial job shown above illustrates how you'd code the generation numbers to accomplish this.
In this example, STEP1 creates generation (+1) and STEP2 creates generation (+2).
*Specifying Relative Generation Numbers
Relative generation numbers (+1), (+2), (+3) and so on, used consecutively in a job, indicate the newest generation being created.
If only one generation is being created in the job, use (+1).
If multiple generations are being created, use (+1) for the first, (+2) for the second, and so on. Never skip generation numbers!
Topic 3.1.2: Coding the DISP Parameter
*Switching GearsNow that you understand how to specify the relative generation numbers for new generation data sets in the DSN parameter, let's turn our attention to the DISP parameter.
NEW, CATLG, and DELETE Parameters
When you create a new generation data set, use
DISP=(NEW,CATLG,DELETE)
on the DD statement.
| NEW | specifies that you're creating a new generation. |
| CATLG | tells the system to catalog the new generation if the step terminates normally. |
| DELETE | tells the system to delete the new generation if the step terminates abnormally. |
You can, of course, omit NEW because it is the default. However, you must code CATLG because DELETE is the default disposition for new data sets.
The third subparameter, DELETE, is optional. However, if you omit it, the system performs the action specified in the second subparameter, CATLG, if the step terminates abnormally.
Topic 3.1.3: Coding Other DD Parameters
*Coding the Rest of the DD StatementAt this point, you know how to code the DSN and DISP parameters for a new generation data set. As you know, the system needs additional information when you create a data set. This information is supplied using the other parameters of the DD statement.
Next, you'll learn how to code the rest of the DD statement for a new generation data set.
*SMS Considerations
With SMS, you code the remaining DD statement parameters just as you do for any other new permanent non-VSAM data set.
You can use any of the following to create a generation data set:
| DATACLAS and STORCLAS | to specify the appropriate data and storage classes. (Check with your storage administrator to determine if you need to use MGMTCLAS.) |
| LIKE or REFDD | to copy the attributes from another cataloged data set. |
You can also omit parameters other than DSN and DISP if there is an ACS exit routine that assigns appropriate data, storage and management classes.
Question 25
*Non-SMS Considerations
Before you create generation data sets, make sure to check your installation standards to determine which parameters are needed for a new generation data set.
When you create a generation data set, you code the remaining DD statement parameters, except DCB, just as you do for any other new permanent non-VSAM data set.
Because you already know how to code these parameters, we won't discuss them here. Instead, we'll focus on coding the DCB parameter.
Topic 3.1.4: Coding the DCB Parameter
*Requirements for the DCB ParameterWhen you create a generation data set, the DCB parameter must refer to one of the following:
- A cataloged non-VSAM data set whose attributes you want to copy
- or
- A model DSCB
*Copying Attributes
Below is the format of the DCB parameter to copy the attributes of a cataloged non-VSAM data set:
DCB=(dsname,list of attributes)
| dsname | specifies the name of the data set whose attributes you want to copy |
| list of attributes | specifies the DCB subparameters you want to either override or supply |
*Requirements/Options
The dsname is required. The list of attributes is optional and is only needed if you want to:
- Override DCB information specified for the referenced data set
- or
- Supply additional DCB information not specified for the referenced data set
*Copying DCB Information from a Cataloged Data Set
Assume that you're creating a generation data set and you want to copy the DCB information from a cataloged data set called REF.NAME. Here's how you'd code the DCB for the generation data set:
DCB=REF.NAME
This copies all the DCB information from REF.NAME and uses it for the new generation data set.
If you want to override or add to the DCB information from REF.NAME, you code the new attributes following the name of the data set, like this:
DCB=(REF.NAME,LRECL=200,BLKSIZE=4000)
This overrides REF.NAME's record length and block size with the ones specified in the list.
Question 26
Question 27
*What's a Model DSCB?
Referring to a cataloged non-VSAM data set is one way to code the DCB for a new generation data set. The other way involves using a model DSCB.
DSCB stands for Data Set Control Block. It contains information about the data set's attributes.
*Model DSCB Requirements
A model DSCB is just that — it's a model that describes data set attributes. Unlike a regular data set, a model DSCB is not used to store any data. It simply serves as a model that can be referenced when you create a generation data set.
A model DSCB must:
- Reside on the same catalog volume as the one that contains the GDG base entry
- Not be cataloged
//MDSCB JOB
//STEP1 EXEC PGM=IEFBR14
//MODEL DD DSN=ACCOUNT.MASTER,UNIT=DISK,
// VOL=SER=DISK01,SPACE=(TRK,0),
// DISP=(NEW,KEEP),
// DCB=(RECFM=FB,LRECL=200,BLKSIZE=4000)
*Using IEFBR14 to Create a DSCB
This job uses a utility called IEFBR14 to create a model DSCB. IEFBR14 does nothing other than perform data set allocation and deallocation.
In this example, the name of the model DSCB is ACCOUNT.MASTER. As you'll see later, the name does not need to be the same as the GDG base entry name.
//MDSCB JOB
//STEP1 EXEC PGM=IEFBR14
//MODEL DD DSN=ACCOUNT.MASTER,UNIT=DISK,
// VOL=SER=DISK01,SPACE=(TRK,0),
// DISP=(NEW,KEEP),
// DCB=(RECFM=FB,LRECL=200,BLKSIZE=4000)
*Where's the Model Stored?
The model is stored on volume DISK01, which is the same volume on which the base entry for this GDG is stored.
No space is allocated for the model DSCB because it is not used to store data.
The disposition of the model is KEEP so that it is retained at the end of the job. Remember that a model DSCB cannot be cataloged.
//MDSCB JOB
//STEP1 EXEC PGM=IEFBR14
//MODEL DD DSN=ACCOUNT.MASTER,UNIT=DISK,
// VOL=SER=DISK01,SPACE=(TRK,0),
// DISP=(NEW,KEEP),
// DCB=(RECFM=FB,LRECL=200,BLKSIZE=4000)
*The DCB Information
Finally, the DCB information is coded. As you'll see later, you do not need to specify DCB information in the model DSCB.
You can set up the model DSCB at any time, as long as it exists before you create any generation data sets that reference it.
Question 28
*Referring to Models
When you create a generation data set, you can refer to a model DSCB in the DCB parameter for the new data set. The reference can be either implicit or explicit:
An implicit reference occurs automatically if the name of the model DSCB is the same as the name of the GDG base entry.
For example, if ACCOUNT.MASTER is the name used for both the model DSCB and the GDG base entry, the system makes the connection for you.
*Understanding Implicit References
With an implicit reference, you do not need to specify the name of the model DSCB in the DCB parameter for the new generation data set. In fact, in some cases, you can omit the DCB parameter entirely when you create the generation data set. You'll learn more about implicit references in a few minutes.
*Understanding Explicit References
An explicit reference is required if the name of the model DSCB is not the same as the name of the GDG base entry. This type of reference must be coded in the DCB parameter of the new generation data set.
*Explicitly Referring to a Model DSCB
Below is the format of the DCB parameter to explicitly refer to a model DSCB:
DCB=(modelDSCB,list of attributes)
| model DSCB | specifies the name of the model DSCB whose attributes you want to use |
| list of attributes | specifies the DCB subparameters you want to either override or supply |
As you can see, this format is basically the same as the one used to refer to a cataloged non-VSAM data set. In fact, the only difference is the name you specify. Here, you use the model DSCB name instead of the name of a cataloged data set.
*Requirements/Options
The model DSCB is required for an explicit reference. The list of attributes is optional and is only needed if you want to:
- Override DCB information specified for the model DSCB
- or
- Supply DCB information not specified for the model DSCB
*Model DSCB Options
As you can see, there are various options available when you refer to a model DSCB to create a generation data set. Let's put these options into perspective using the chart above.
*No DCB Parameter is Required
This part of the chart indicates that you can omit the DCB parameter when you create a generation data set if:
- The model DSCB and the GDG base entry have the same name, and
- DCB information was specified in the model DSCB.
*Why You Can Omit the DCB Parameter
Because the names are the same, the system automatically relates the model DSCB and the GDG base entry. It then uses the DCB information specified in the model DSCB for the new generation data set.
You can code the DCB parameter if you want to override or add DCB information to what was specified in the model DSCB. To do this, you'd simply code:
DCB=(list of attributes)
In the list, you'd include only the changes to the model DCB information.
Question 29
list is Required
This part of the chart indicates that you must code the DCB parameter for the new generation data set if:
- The model DSCB and the GDG base entry have the same name, but
- DCB information was not specified in the model DSCB.
*Format of the Required DCB Parameter
The format of the DCB parameter in this case is:
DCB=(list of attributes)
It is just like the DCB parameter you'd code for any other new data set. Notice that you do not need to include the name of the model DSCB.
Question 30
list is Optional
This part of the chart indicates that you must code the DCB parameter for the new generation data set if:
- The model DSCB and the GDG base entry have different names, and
- DCB information was specified in the model DSCB.
*Format of the Required DCB Parameter
The format of the DCB parameter in this case is:
DCB=(modelDSCB,list of attributes)
The model DSCB name is required. The list of attributes is only needed if you want to override or add DCB information to what was specified in the model DSCB.
Question 31
list is Required
This part of the chart indicates that you must code the DCB parameter for the new generation data set if:
- The format of the DCB parameter in this case
is:
DCB=(modelDSCB,list of attributes) - Both the model DSCB name and the list of attributes are required.
Question 32
*Remember...
That's it for using a model DSCB when you create generation data sets!
Before you use model DSCBs, check your installation standards. Your installation has probably defined one or more model DSCBs for generation data sets. Find out if you should use one of the existing models. Also, find out if the models have DCB information.
Topic 3.2: Unit 3 Summary
The following points were covered in this unit:- When you create a generation data set, you refer to it using its base
entry name followed by a positive relative generation number.
- Relative generation numbers (+1), (+2), (+3)
and so on, used consecutively in a job, indicate the newest generation being
created.
- When you create a new generation data set, use
DISP=(NEW,CATLG,DELETE) on the DD statement.
- With SMS, you code the remaining DD statement parameters just as
you do for any other new permanent non-VSAM data set.
- If you're not using SMS, you code the remaining DD statement
parameters, except DCB, just as you do when you create any other new
permanent non-VSAM data set.
- The DCB must refer to a cataloged non-VSAM data set whose
attributes you want to copy or a model DSCB.
- The format of the DCB parameter to copy the attributes of a
cataloged non-VSAM data set is as follows: DCB=(dsname,list of
attributes)
- The format of the DCB parameter to explicitly refer to a model DSCB is as
follows:
DCB=(modelDSCB,list of attributes)
- There are special requirements regarding DCB coding for non-SMS generation data sets.
Unit 4. Using Generation Data Sets
In this unit, you will learn how to use generation data sets.
After completing this unit, you should be able to:
- Work with existing generation data sets
Topic 4.1: Working With Generation Data Sets
*Coding Relative Generation NumbersThe last unit explained how to code the relative generation numbers for new generation data sets:
- Code the DSN followed by a generation number, +1 to +255, in parentheses.
- If this is the first generation being created within a job, code (+1) for the generation number.
- If the job creates additional new generations, increase the relative generation number by one for each new generation.
//CREATE JOB
//STEP1 EXEC PGM=CREATE
//IN1 DD DSN=INFILE1.TST,DISP=OLD
//OUT1 DD DSN=ACCOUNT.MASTER(+1),
// DISP=(,CATLG,DELETE),
:
//STEP2 EXEC PGM=CREATE
//IN2 DD DSN=INFILE2.TST,DISP=OLD
//OUT2 DD DSN=ACCOUNT.MASTER(+2),
// DISP=(,CATLG,DELETE),
:
STEP1 and STEP2
In this example, STEP1 creates generation (+1) and STEP2 creates generation (+2).
Now let's see how you reference these generations in subsequent steps within this job.
STEP 3
Assume that STEP3 performs additional processing on both of the new generation data sets created in the first two steps of this job. STEP3 is shown below.
//STEP3 EXEC PGM=VERIFY
//IN3A DD DSN=ACCOUNT.MASTER(+1),DISP=OLD
//IN3B DD DSN=ACCOUNT.MASTER(+2),DISP=OLD
Notice that the generation numbers are the same as the ones used when the generations were created.
As a general rule use the same relative generation numbers throughout a job.
*Working with Relative Generation Numbers
If you create generation (+1), refer to that generation as (+1) in all subsequent steps of the job. If you create generation (+2), refer to that generation as (+2) in all subsequent steps of the job, and so on.
There are, of course, situations (for example, certain types of job restart) in which this rule does not apply. However, discussing the exceptions to the rule are beyond the scope of this course.
Question 33
Question 34
*Other DD Statement Parameters
As you can see, the rule for referring to generation data sets within a job is simple and straightforward: use the same relative generation numbers throughout the job.
Before we examine how to refer to generation data sets in subsequent jobs, let's take a few minutes to briefly discuss the other DD statement parameters needed to retrieve a generation data set.
DISP Subparameters
The DSN and DISP parameters are required to retrieve an existing generation data set. Other DD statement parameters are optional because a generation data set is cataloged when it is created.
For the DISP parameter, you can code OLD, SHR or MOD as the first subparameter. The examples shown in this objective specify DISP=OLD.
The remaining DISP subparameters for normal and abnormal termination disposition are optional. In most cases, you won't use them because you'll probably want to keep the data set regardless of how the step terminates -- normally or abnormally.
Now let's examine how you refer to generation data sets in subsequent jobs.
*Updating Relative Generation Numbers
Assume you have a job that creates a generation data set. In that job, the generation is referred to as (+1).
At the end of the job, the system updates the relative generation number of this generation. Generation (+1) becomes generation (0).
*If You Run the Same Job Again...
Now assume that you run this job again and create another generation. At the end of this job, here's what happens:
- The generation just created, which was generation (+1) during the job, becomes generation (0).
- The generation that was created the first time you ran the job becomes generation (-1).
In other words, generation (+1) causes all previous generations to be "pushed down" one level at the end of the job.
*What Happened to the Positive Generation Numbers?
Because the system updates relative generation numbers at the end of a job, positive (+) generation numbers no longer exist after a job is completed.
This is consistent with what you learned in the first objective in this unit:
- Generation (0) is always the latest generation.
- Generation (-1) is the previous generation, and so on.
As a result, when you refer to generation data sets in subsequent jobs, you use their updated generation numbers.
Question 35
*Creating Multiple Generations
Now let's examine what happens when a job creates more than one new generation.
Assume that JOB1 creates the following generations: ACCOUNT.MASTER(+1) ACCOUNT.MASTER(+2)
At the end of this job: ACCOUNT.MASTER(+1) becomes ACCOUNT.MASTER(-1). ACCOUNT.MASTER(+2) becomes ACCOUNT.MASTER(0).
This is still consistent with the way generation data sets are numbered.
*How Data Sets are Processed
In this example, generation (+2) becomes generation (0) because it is the latest generation. Generation (+1) becomes generation (-1) because it is the previous generation; it was created before generation (+2).
When subsequent jobs process these data sets, they use the updated generation numbers produced at the end of the job.
*Rules for Working with Relative Generation Numbers
The easiest way to remember all this is to keep these general rules in mind:
- Use the same relative generation numbers throughout a job. If you create
generation (+1), refer to that generation as (+1) in all
subsequent steps of the job. If you create generation (+2), refer to
that generation as (+2) in all subsequent steps of the job, and so
on.
- Remember that the system updates generation numbers at the end of each job. After a job is run, generation (0) is always the latest generation, generation (-1) is the previous generation, and so on.
*Absolute Generation Numbers
There's one more thing you need to know about generation data set names.
Internally, the system stores generation data set names using the GDG base entry name followed by an absolute generation number.
*The Format of Absolute Generation Numbers
The format of an absolute generation number is GxxxxVyy where:
- "xxxx" is a four-digit sequence number. It denotes the generation number in the sequence in which it was created (0001, 0002, 0003 and so on).
- "yy" is the version number. The version number used by the system is 00.
For example, the name ACCOUNT.MASTER.G0025V00 tells you that this is the 25th generation of the GDG. Generation data set names are shown in this format in JCL output.
*Generations and Retainment
Keep in mind that the system only retains the number of generations specified in the GDG base entry. So, while 25 generations may have been created, only the number specified in the GDG base entry are actually retained.
If you read the documentation on generation data sets, you'll see that the absolute generation number can be used to create or retrieve generation data sets. However, this technique is reserved for unusual job restart situations. As you work with generation data sets, you should always use relative generation numbers.
Topic 4.2: Unit 4 Summary
The following points were covered in this unit:- Use the same relative generation numbers throughout a job. If you create
generation (+1), refer to that generation as (+1) in all
subsequent steps of the job.
- The DSN and DISP parameters are required to retrieve an
existing generation data set. Other DD statement parameters are
optional because a generation data set is cataloged when it is
created.
- Assume you have a job that creates a generation data set. In that job, the
generation is referred to as (+1). At the end of the job, the system
updates the relative generation number of this generation. Generation
(+1) becomes generation (0).
- Internally, the system stores generation data set names using the GDG base entry name followed by an absolute generation number. The format of an absolute generation number is GxxxxVyy.
Unit 5. Space Allocation
In this unit, you will learn how to calculate the space requirements for both tapes and disks.
After completing this unit, you should be able to:
- Estimate tape requirements
- Estimate disk space
Topic 5.1: Estimating Tape Requirements
*Space RequirementsSpace requirements involve
- the length of tape needed to store a predetermined amount of data to tape
- the amount of disk space — number of tracks or cylinders — needed to store a disk data set
*Tape Storage
For tape storage, the only factors to consider are the block size density, the size of the tape and the number of tapes required. In order to show the effect that block size and density have on how much tape is used, you'll step through a formula that calculates the tape footage used.
In most cases, you would not calculate the feet of tape used. The formula is presented here to increase your awareness of the effect block size and density has on tape storage requirements.
In the next objective on disk space, you'll see that block size is even more important. A similar formula is used for disk space. The derivation of the formula is only presented in this objective.
*Determining the Length of Tape Needed
Suppose you want to store a given number of records with a specific block size (BLKSIZE) using a particular tape density (DEN). How do you determine the length of tape needed? Use the formula shown here.
Let's see how the formula is derived.
*Determining the Length of Tape Needed
Suppose you want to store a given number of records with a specific block size (BLKSIZE) using a particular tape density (DEN). How do you determine the length of tape needed? Use this formula.
*Formula Elements
Suppose you want to store a given number of records with a specific block size (BLKSIZE) using a particular tape density (DEN). How do you determine the length of tape needed? Use this formula.
DEN = number of bytes per inch (BPI)
Two densities are used: 1600 BPI and 6250 BPI
gap = interblock gap = .6 inches for 1600 BPI or .3 inches for 6250 BPI
Division by 12 gives the result in feet instead of inches.
Question 36
*Getting Started
Let's look at how to calculate the length of tape needed to store
- A given number of records
- With a specific block size
- Of a particular density.
*Example 1
How many feet of tape does it take to store 10,000 records at 6250 BPI? The record length is 80 bytes, and the block size is 400 bytes. The gap is .3 inches, and the blocking factor is 5.
Plug the values into the formula.
*Example 2
If you double the block size from 400 to 800, how many feet of tape will you save? This also changes the blocking factor to 10.
Therefore, by doubling the block size, you can save 60.67 - 35.67 = 25 feet of tape.
The maximum block size allowed for tape is 32,000 bytes.
*How Density Affects Tape Usage
Before doing another problem compare how density affected tape usage.
The data set you've been working with has a record length of 80 bytes, BLKSIZE of 400 and a blocking factor of 5.
In Example 1 it was stored at 6250 BPI using 60.67 feet of tape.
You just calculated the footage at 1600 BPI and found that 141.66 feet of tape was necessary.
-- That's more than twice as much.
BLKSIZE Versus DENSITY
In the example and problems presented you have seen how both the BLKSIZE and DENSITY affects tape usage.
Here is a comparison:
| LRECL | BLKSIZE | # RECORDS | BPI | FEET OF TAPE REQUIRED |
|---|---|---|---|---|
| 80 | 400 | 10,000 | 6250 | 60.67 |
| 80 | 800 | 10,000 | 6250 | 35.67 |
| 80 | 400 | 10,000 | 1600 | 141.67 |
| 80 | 800 | 10,000 | 1600 | 91.67 |
Notice the two extremes. The higher block size and higher density is almost a 300% savings over the lower block size and lower density. Typically, increasing the block size and density will reduce tape requirements.
Topic 5.2: Estimating Disk Space
*Disk Space CalculationNow let's turn our focus to disks.
Disk space calculation involves finding how many blocks of data can fit on a track. And, consequently, how many tracks or cylinders are required to hold the data.
Let's see what rules you have to keep in mind when allocating space on disk.
When working with SMS-managed data sets, you may not always have to worry about space calculations. You should check your installation guidelines on the attributes defined in the data classes.
*Estimating Disk Space: Rule 1
Here are some rules to consider when estimating disk space.
The smallest amount of disk space that can be allocated for a data set is one track (TRK). Even if your data set is one byte long, it will still take one track.
*Estimating Disk Space: Rule 2
Data is recorded in whole blocks. If the remaining space on a track isn't large enough for an entire block of data, the data is written to a new track. This wastes the space that could not accommodate the block.
An exception to this is spanned data sets. However, they are not included in this discussion.
*Estimating Disk Space: Rule 3
The gap for disk data sets is given in bytes, not in inches. The gap is the number of bytes that could be written in the space occupied by the gap.
*Wasting Space
You minimize the number of gaps by blocking many records in a block. But with disks, you may reach a point where, by making the block size bigger, you waste more space.
Whether you waste space and how much depends on the track size. Different types of devices have different track sizes. Therefore, each device has its own optimum block size.
You should refer to your installation guidelines and equipment manuals for further information on the devices used at your installation.
For illustration purposes, a hypothetical disk device will be used throughout this objective.
Question 37
Question 38
*Selecting the Wrong Block Size
To illustrate how disk space can be wasted by selecting the wrong block size, let's look at a sample disk.
Suppose the track size is 32,760 bytes.
If you choose, for example, a block size of 12,000 bytes, you can only write two blocks per track (2 x 12,000 = 24,000 bytes). This is because the remaining space on the track (8,760 bytes) is not big enough to accommodate another entire block.
That means you are wasting 8,760 bytes per track. Imagine if your files are ten tracks long, then you're wasting 87,600 bytes of storage!
*Best Block Size
The best block size for our disk is 32,760. The best block size for any disk is the track size. This is not easy to achieve for the following two reasons:
- The block size must be a multiple of the record length.
- A big block size requires equally big buffers to accommodate the data for I/O.
Question 39
*Estimating Blocks Per Track
Here's how you calculate the amount of disk space it takes to store a given amount of data.
You first have to calculate how many blocks of data can fit on one track.
From there you can calculate how many tracks are required for your data.
There are two ways to find how many blocks fit on a track.
- Use a given formula.
- Use the tables supplied with the reference card for a specific disk model. The tables give ranges of block sizes and the number of blocks that fit on a track.
*Tables Versus Formulas
It is always easier to use the tables than the formula. The formula can be used if you don't have access to the tables.
When you use the tables, you find the range within which your block size falls. Then you get the number of blocks that will fit per track.
Refer to your installation guidelines and equipment manuals for further information.
*Calculating Block Size
Let's look at an example. How many tracks will it take to store 10,000 80-byte records on a disk, assuming that the blocking factor is 10?
First, you calculate the block size:
record size x blocking factor = block size 80 x 10 = 800
Then you refer to the table supplied with the reference card for the disk model. The next screen shows a portion of a sample table.
*Using Tables
You calculated the block size as 800 bytes. This block size falls within the 789 - 820 range on this table.
Block Size in Bytes Track Capacity
| Min | Max | Blocks | Bytes |
|---|---|---|---|
| 821 | 852 | 35 | 29,820 |
| 789 | 820 | 36 | 29,520 |
| 757 | 788 | 37 | 29,156 |
From the table you see that 36 800-byte blocks can be stored on a track. With a blocking factor of 10, that means that 360 80-byte records can be stored on a track.
Therefore, the number of tracks required for 10,000 80-byte records on the disk is 10,000/360 = 27.7. Rounded up, the answer is 28 tracks.
*Your Turn!
On the next screen, it's your turn to do the calculations for how many tracks on a disk you'll need for your data.
You will do the problem in stages.
First, you'll determine the block size.
Next, you'll refer to the tables for the number of blocks per track.
Then, you'll determine how many records per track.
Last, you'll calculate the number of tracks you need.
Topic 5.3: Unit 5 Summary
The following points were covered in this unit:- The length of tape needed to store a given number of records with a
specific block size (BLKSIZE) and density (DEN) is
determined by the following formula: length in feet = ( (number of
records/blocking factor) x (BLKSIZE/DEN + GAP) ) / 12
- Here are some rules to consider when estimating disk space. The smallest
amount of disk space that can be allocated for a data set is one track. Data
is recorded in whole blocks. If the remaining space on a track cannot fit an
entire block of data, the data is written to a new track. This wastes the
space that could not accommodate the block. The gap for disk data sets is
given in bytes. The gap is the number of bytes that could be written in the
space occupied by the gap.
- You minimize the number of gaps by blocking many records in a block. But
with disks, by making the block size bigger, you may waste more space.
- The best block size for any disk is the track size. This is not easy to
achieve for the following two reasons: The block size must be a multiple of
the record length. A big block size requires equally big buffers to
accommodate the data for I/O.
- Here's how you calculate the amount of disk space it takes to store a
given amount of data. You first have to calculate how many blocks of data can
fit on one track. From there you can calculate how many tracks are required
for your data.
- There are two ways to find how many blocks fit on a track. Use a given formula. Use the tables supplied with the reference card for a specific disk model. The tables give ranges of block sizes and the number of blocks that fit on a track.
Unit 6. Considerations For Tapes
In this unit, you will learn about special considerations for magnetic tape.
After completing this unit, you should be able to:
- Work with labeled tapes
- Protect data sets
Topic 6.1: Working with Labeled Tapes
*Tape Data SetsThe operating system uses internal labels
- To identify volumes and the data sets on them
- To store data set characteristics
Tapes can be divided into two categories: labeled and unlabeled.
*Unlabeled Tapes
On an unlabeled (NL) tape, files are recorded one after the other in sequence. The files are separated by a special pattern known as a tapemark (TM). The logical end of the tape is indicated by two consecutive tapemarks.
An unlabeled tape containing three files is laid out as shown.
On an unlabeled tape, the name and physical characteristics of each file are not recorded on the tape. Therefore, the file characteristics must be supplied in the JCL in order to use the file.
Question 40
Question 41
Question 42
*Labeled Tapes
Turn your attention now to labeled tapes.
There are many categories of labeled tapes. This objective only focuses on standard labeled (SL) tapes.
On a labeled tape, the name of the tape volume is recorded on the tape when it is initialized.
Also recorded is the name, physical characteristics and other important information for each file on the tape.
To initialize a tape so that it is standard labeled, you run a utility such as IEHINITT.
*Types of Labels
The information about the volume and each file is recorded in 80-byte records referred to as labels. The first four characters of each label record are used to identify the label type.
There are three basic types of labels: volume, data set header and data set trailer.
A fourth type of label, user label, can be used with header or trailer labels to include user-specified data. User labels follow the standard header and trailer labels. Refer to your installation guidelines for more information on user labels.
*Volume Labels
The volume information is recorded in a volume label, called VOL1.
*Header and Trailer Labels
Each file on the tape is preceded by two data set header label records (HDR1 and HDR2) and followed by two data set trailer label records (EOF1 and EOF2).
The header and trailer labels contain information such as: data set name physical characteristics (record format, record length, block size) creation date expiration date
*A Standard Labeled Tape
A typical standard labeled tape layout is depicted here.
Notice where the tapemarks (TM) occur on a standard labeled tape. The logical end of a standard labeled tape is marked by two consecutive tapemarks.
Question 43
Question 44
Question 45
*The System's Perspective
You saw how unlabeled (NL) and standard labeled (SL) tapes differ in the information recorded on the tape and in the layout of the files on the tape.
Now look at how the system views this layout and then see the coding differences.
*What the System Sees
For a standard label tape the system sees these physical files:
File one contains the volume label and the two headers for the first dataset.
File two contains the first data file.
File three contains the two trailers.
*Label Parameters
You specify whether your tape is SL or NL with the LABEL parameter.
LABEL=(2,NL) indicates that the tape is unlabeled and specifies the second data file on the tape which is the second physical file.
LABEL=(2,SL) indicates that the tape is standard labeled and specifies the second data file on the tape which is the fifth physical file.
*The NL Parameter
The system uses the LABEL parameter (SL or NL) to determine how to read a tape to find a file. The system positions itself on a tape by counting tapemarks.
For LABEL=(2,NL), the system fast forwards until it encounters the first tapemark. Then it starts reading the file. The system reads until it finds another tapemark.
In this case each physical file is also a logical or data file.
*The SL Parameter
For LABEL=(2,SL), positioning occurs at the third tapemark. The two header labels for FILE2 are read and the fourth tapemark is encountered. Then the second data file (which is the fifth physical file on the tape) is processed until another tapemark is found.
*System Safeguards
When you use a standard labeled tape, the system provides the following safeguards:
1. It verifies that the volume serial number matches the one supplied in the JCL.
2. It verifies that the name of the file in the label matches the one specified in the JCL.
When comparing the data set name in the label to the one specified in the JCL, the system considers only the 17 least significant (rightmost) characters.
Because of this limitation, you may want to restrict your data set names for tape data sets to 17 characters. However, this is not always practical. Refer to your installation guidelines when naming tape data sets.
*More System Safeguards
When you use a standard labeled tape, the system provides the following safeguards:
3. It matches the physical characteristics with the ones supplied in the DCB parameter of the JCL. Any mismatch causes the job to cancel. If no DCB information is supplied, then the information from the labels is used.
4. If the file is being modified (opened for output), it checks the expiration date. It notifies the operator if the file hasn't expired (the current date is less than the expiration date).
The expiration date, supplied in the LABEL parameter, is a subject of the next objective.
Question 46
Question 47
Question 48
Question 49
*The BLP Parameter
The safeguards and services provided when using standard labeled tapes can be nullified by instructing the system to bypass label processing (BLP).
BLP is coded in the LABEL parameter:
LABEL=(data-set-sequence-number,BLP,...)
Certain tape utilities require that you specify BLP in the LABEL parameter. Two such utilities (non-IBM) are TAPEMAP and TAPECOPY.
TAPEMAP shows whether a tape is standard labeled. If it is, it prints a list of all the data sets on the tape along with their physical characteristics and size.
TAPECOPY is used to recover tape files which are inaccessible due to damage.
*How Labels Are Grouped
Remember how the system sees the layout of a standard labeled tape. Notice how the different labels are grouped into files.
File one contains the volume label and the two headers for the first data file.
File two contains the first data file.
File three contains the two trailers.
The next screen shows you what happens if a tape with SL is read with BLP.
*Using the BLP Parameter
To access the second data file on the tape with BLP you must code the LABEL parameter, LABEL=(5,BLP) ...
four tapemarks are counted before reading the data in the fifth file. Here it is shown graphically:
*Computing a BLP File Number
Use this formula for computing the BLP file number for an SL tape: BLP file number = (SL file number - 1) x 3 + 2.
The calculation for this example is (2 - 1) x 3 + 2 = 5.
BLP Versus NL
For both labeled and unlabeled tapes, BLP is equivalent to NL. For an unlabeled tape, specifying BLP has no effect.
If the BLP feature is disabled in your system, then BLP is treated as NL.
Do not use BLP when the DSN parameter specifies all members of a GDG.
You want to avoid doing this because the system references the catalog for the data set sequence number. Using BLP in this situation can result in incorrect tape positioning.
Question 50
Topic 6.2: Protecting Data Sets
*Writing a File to TapeWhen writing to a tape -- opening a file for output -- care should be taken to specify the file sequence number correctly.
Suppose you have a standard labeled tape with three data sets and you want to include a fourth. You must specify LABEL=(4,SL). If you forget LABEL altogether, the default is LABEL=(1,SL).
When you write a file to tape, the system marks it as the last file on the tape by recording two consecutive tapemarks behind it.
Therefore, if you code a sequence number less than four, you lose the files that follow.
Question 51
*Protecting Your Files
One way to protect your files, is to supply an expiration date (EXPDT) or retention period (RETPD) when they are first written. A data set with an unexpired EXPDT or RETPD cannot be modified or deleted.
If you use EXPDT, you tell the system the exact date after which the data set need not be kept.
If you use RETPD, you supply the number of days you want the data set to be retained.
EXPDT and RETPD can be used with both tape and disk data sets. For the sake of discussion, however, we'll be focusing on their use with tape data sets. You should refer to your installation guidelines when using EXPDT and RETPD.
*Expiration Dates and Retention Periods
The expiration date and the retention period are supplied either in the LABEL parameter or as separate keyword parameters on a DD statement.
For example:
//WK1 DD DSN=TEST,LABEL=(4,SL,EXPDT=yyddd),...
is equal to:
//WK1 DD DSN=TEST,LABEL=(4,SL),EXPDT=yyddd,...
//WK1 DD DSN=TEST,LABEL=(6,SL,RETPD=nnnn),...
is equal to:
//WK1 DD DSN=TEST,LABEL=(6,SL),RETPD=nnnn,...
Both formats are valid. If the LABEL parameter is not needed, you may prefer to use the EXPDT or RETPD parameter on the DD statement.
*Coding Expiration Dates
There are two ways to code EXPDT:
EXPDT=yyddd
EXPDT=yyyy/ddd
EXPDT=yyddd is used to supply the expiration date in Julian format. For example: EXPDT=95001 specifies an expiration date of January 1, 1995.
You can use the alternate form of EXPDT to specify a 4-digit year and 3-digit day. For example: EXPDT=1995/001 will also specify an expiration date of January 1, 1995.
*Using EXPDT
There are a few things to keep in mind when using EXPDT:
- To specify a date beyond 1999, you must use the second form (EXPDT=yyyy/ddd)
- If you specify the current date or a date in the past, EXPDT is ignored.
- A data set with an expiration date of 99365 or 99366 will never be deleted.
*Coding a Retention Period
When you use RETPD, the number you specify is added to the current date and converted to Julian date format. The format is: RETPD=nnnn
You may specify a retention period of 0-9999 days. For example: LABEL=(4,SL,RETPD=365) retains the data set for 365 days from the date written.
There is one exception to the use of RETPD. If you use RETPD that corresponds to December 31, 1999, the system will actually extend the retention period to January 1, 2000.
Question 52
Question 53
Question 54
*Working with Date Protected Data Sets
What happens if you try to open for output a date protected data set?
A message appears on the operator console asking the operator whether to allow the operation or to cancel the job.
*Deleting Date Protected Data Sets
The same thing happens if you attempt to delete a date protected data set by coding DISP=(OLD,DELETE) in the JCL.
There are ways to delete a data set that is date protected, but the methods are often restricted.
Refer to your installation guidelines and JCL manuals for more information.
*Coding the PASSWORD Subparameter
Another way to protect your data sets is by using the PASSWORD subparameter on the LABEL parameter.
The format of the subparameter is:
LABEL=(data-set-sequence number,label,PASSWORD,...)
PASSWORD is a positional subparameter which follows the label type.
*Key Points About the PASSWORD Subparameter
A full discussion of PASSWORD is beyond the scope of this course. However, here are some key points:
- To use password protection, a password must be assigned in the PASSWORD data set.
- When PASSWORD is used, the operator must supply the password in order to use (read, write or delete) the data set.
- When passwords are used for tape data sets, all data sets on a volume must be password protected and all must have the same password.
Question 55
Topic 6.3: Unit 6 Summary
The following points were covered in this unit:- Tapes can be divided into two categories: labeled and unlabeled.
- On an unlabeled (NL) tape, files are recorded one after the other
in sequence. The files are separated by a special pattern known as a tapemark
(TM). The logical end of the tape is indicated by two consecutive
tapemarks.
- On an unlabeled tape, the name and physical characteristics of each file
are not recorded on the tape. Therefore, the file characteristics must be
supplied in the JCL in order to use the file.
- On a labeled tape, the name of the tape volume is recorded on the tape
when it is initialized. Also recorded is the name, physical characteristics
and other important information for each file on the tape.
- The information about the volume and each file is recorded in 80-byte
records referred to as labels.
- The system uses the LABEL parameter (SL or NL)
to determine how to read a tape to find a file. The system positions itself on
a tape by counting tapemarks.
- When you use a standard labeled tape, the system provides the following
safeguards: Verifies the volume serial number to that in the JCL. Verifies the
name of the file to that in the JCL. Matches the physical characteristics to
the DCB in the JCL. Checks the expiration date, notifies the operator
if not expired
- The safeguards and services provided when using standard labeled tapes can
be nullified by instructing the system to bypass label processing
(BLP).
- Use this formula for computing the BLP file number for an
SL tape: BLP file number = (SL file number - 1) x 3
+ 2.
- One way to protect your files is to supply an expiration date
(EXPDT) or retention period (RETPD) when they are first
written.
- If you use EXPDT, you tell the system the exact date after which
the data set need not be kept. If you use RETPD, you supply the
number of days you want the data set to be retained.
- There are two ways to code EXPDT: EXPDT=yyddd or
EXPDT=yyyy/ddd
- When you use RETPD, the number you specify is added to the
current date and converted to Julian date format. The format is:
RETPD=nnnn
- Another way to protect your data sets is by using the PASSWORD
subparameter on the LABEL parameter. The format of the subparameter
is:
LABEL=(data-set-sequence number,label,PASSWORD,...)
Unit 7. Mounting Tapes
In this unit, you will learn about deferring the mounting of tapes, retaining tapes between files, and premounting tapes.
After completing this unit, you should be able to:
- Defer the mounting of a tape until the data set is opened
- Retain a tape (not dismounting) between files
- Premount tapes under JES2
Topic 7.1: Deferring Mounting
*Deferred MountingLet's begin with deferred mounting. Should a tape be mounted when the job step begins execution or when the data set is opened?
To answer this question, examine how the operating system prepares a job step for execution.
*The Allocation of Resources
When the operating system prepares a job step for execution, all the resources specified in the JCL are allocated.
The files used in the job steps are a resource that is allocated.
For tape data sets, allocating includes
- Finding an available tape drive and
- Issuing a message to the operator console to mount the tape on the drive.
*Working with Multiple Tapes
If the job step uses more than one tape, the tapes must be mounted when the job step begins execution. Having tapes mounted takes a tape drive away from other jobs that may need to mount tapes.
However, a program executed in a job step may not require all the tape files at the same time.
For example, a program may use several tape files in sequence. That is, it processes a file entirely before it gets to the next one. In this case, it is not necessary to mount all the tapes at once.
This is where DEFER comes into use.
*Coding DEFER
The rule for using DEFER is as follows:
If the program closes the current file before it opens the next one, then you can defer mounting the next tape until the program opens the next file.
You defer mounting by specifying DEFER in the UNIT parameter of the DD statement. DEFER is the third positional subparameter in the UNIT parameter. It looks like this: UNIT=(device-type,,DEFER).
When DEFER is used, the system assigns a device, but does not issue a mount message.
Answer a few questions and then look at a few examples where you can and cannot use DEFER.
Question 56
Question 57
// EXEC PGM=LISTER
//INPUT1 DD DSN=FILE.ONE,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
//INPUT2 DD DSN=FILE.TWO,UNIT=TAPE,VOL=SER=TAPE2,DISP=OLD
//INPUT3 DD DSN=FILE.THREE,UNIT=TAPE,VOL=SER=TAPE3,DISP=OLD
//LISTOUT DD SYSOUT=A
*An Example: LISTER
Suppose you have a program LISTER. It accepts any number of input files with ddnames INPUT1, INPUT2, ... INPUTn and lists their contents on paper with the name LISTOUT.
Above is the JCL to run LISTER to print the contents of three files (FILE.ONE, FILE.TWO, FILE.THREE) located on three different tapes (TAPE1, TAPE2, TAPE3).
// EXEC PGM=LISTER
//INPUT1 DD DSN=FILE.ONE,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
//INPUT2 DD DSN=FILE.TWO,UNIT=TAPE,VOL=SER=TAPE2,DISP=OLD
//INPUT3 DD DSN=FILE.THREE,UNIT=TAPE,VOL=SER=TAPE3,DISP=OLD
//LISTOUT DD SYSOUT=A
*What Happens Next?
When this JCL is submitted, the system tries to mount the three tapes before the program can be executed. This requires three tape drives.
If three are not available, the system allocates as many as it can and suspends your job until all tape drives become available.
// EXEC PGM=LISTER
//INPUT1 DD DSN=FILE.ONE,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
//INPUT2 DD DSN=FILE.TWO,UNIT=TAPE,VOL=SER=TAPE2,DISP=OLD
//INPUT3 DD DSN=FILE.THREE,UNIT=TAPE,VOL=SER=TAPE3,DISP=OLD
//LISTOUT DD SYSOUT=A
*Using DEFER
In this example, suppose the input files are processed one after the other. LISTER is written so that each input file is opened, processed, and closed before proceeding with the next one. In this case, you can use DEFER.
// EXEC PGM=LISTER
//INPUT1 DD DSN=FILE.ONE,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
//INPUT2 DD DSN=FILE.TWO,UNIT=TAPE,VOL=SER=TAPE2,DISP=OLD
//INPUT3 DD DSN=FILE.THREE,UNIT=TAPE,VOL=SER=TAPE3,DISP=OLD
//LISTOUT DD SYSOUT=A
*When DEFER Won't Help
If the program is written so that all files are opened at execution, you have no choice but to mount all three tapes at once. Using DEFER will not help, since DEFER will issue the mount request when the files are opened.
The next screen shows you the same example using DEFER.
// EXEC PGM=LISTER
//INPUT1 DD DSN=FILE.ONE,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
//INPUT2 DD DSN=FILE.TWO,UNIT=(TAPE,,DEFER),VOL=SER=TAPE2,DISP=OLD
//INPUT3 DD DSN=FILE.THREE,UNIT=(TAPE,,DEFER),VOL=SER=TAPE3,DISP=OLD
//LISTOUT DD SYSOUT=A
*How Tapes Are Mounted
The first file does not need DEFER because it is used right away. This JCL mounts the tapes in sequence. The system randomly mounts each tape to a different tape drive. That's because the system tries to distribute the work evenly to all drives.
A note on coding DEFER: Remember, DEFER is coded as the third positional subparameter in the UNIT parameter.
Question 58
Question 59
Question 60
*Working with Multiple Data Sets
Now that you've seen DEFER, let's move on to see how to ensure that the same tape drive is used for multiple data sets.
// EXEC PGM=LISTER
//INPUT1 DD DSN=FILE.ONE,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
//INPUT2 DD DSN=FILE.TWO,UNIT=(TAPE,,DEFER),VOL=SER=TAPE2,DISP=OLD
//INPUT3 DD DSN=FILE.THREE,UNIT=(TAPE,,DEFER),VOL=SER=TAPE3,DISP=OLD
//LISTOUT DD SYSOUT=A
*Specifying Unit Affinity
Look again at the JCL example using DEFER. Each tape is most likely mounted to a different tape drive.
If you want to ensure that the same tape drive is used, specify unit affinity with the AFF subparameter of the UNIT parameter: UNIT=AFF=ddname.
Let's see what the same JCL looks like with AFF.
// EXEC PGM=LISTER
//INPUT1 DD DSN=FILE.ONE,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
//LISTOUT DD SYSOUT=A
*Using AFF
Here is the same JCL with AFF.
UNIT=AFF=ddname tells the system to use the same tape drive for INPUT2 and INPUT3 that was used by INPUT1. Specifying AFF also implies DEFER.
INPUT1 DD, the first DD, doesn't need to specify AFF. DD statements INPUT2 and INPUT3 specify AFF by pointing to INPUT1.
Topic 7.2: Retaining Tapes
*Retaining a TapeAFF can also be used to retain a tape between file access.
Specify unit affinity when you use several files on the same tape. You want to leave the tape on the same drive and go on with the next file on the tape.
Suppose in the previous JCL example with program LISTER, all three files were on TAPE1 in the following order:
FILE.ONE first file on TAPE1 FILE.TWO second file on TAPE1 FILE.THREE third file on TAPE1
The following screen shows you what the JCL looks like.
// EXEC PGM=LISTER
//INPUT1 DD DSN=FILE.ONE,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
//INPUT2 DD DSN=FILE.TWO,UNIT=AFF=INPUT1,VOL=SER=TAPE1,
// DISP=OLD,LABEL=2
//INPUT3 DD DSN=FILE.THREE,UNIT=AFF=INPUT1,VOL=SER=TAPE1,
// DISP=OLD,LABEL=3
//LISTOUT DD SYSOUT=A
*Examine the Code
In this example, all three files are on TAPE1. All three DD statements specify the same tape.
The file's position on the tape is specified using the LABEL parameter.
LABEL=2 indicates that FILE.TWO is the second file. LABEL=3 indicates that FILE.THREE is the third file.
Because the default is LABEL=1, LABEL=1 is omitted on the first DD statement.
Question 61
Question 62
Question 63
// EXEC PGM=LISTER
//INPUT1 DD DSN=FILE.ONE,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
//INPUT2 DD DSN=FILE.TWO,UNIT=AFF=INPUT1,VOL=SER=TAPE1,
// DISP=OLD,LABEL=2
//INPUT3 DD DSN=FILE.THREE,UNIT=AFF=INPUT1,VOL=SER=TAPE1,
// DISP=OLD,LABEL=3
//LISTOUT DD SYSOUT=A
*Combining AFF and RETAIN
You saw the JCL above earlier. It shows how AFF is used to retain a tape (not dismounting) between files.
On the next screen, you'll see how AFF and RETAIN are combined in the same job step. RETAIN is a subparameter of VOL.
// EXEC PGM=LISTER
//INPUT3 DD DSN=FILE.THREE,UNIT=AFF=INPUT1,VOL=SER=TAPE1,
// DISP=OLD,LABEL=3
//LISTOUT DD SYSOUT=A
*Using RETAIN
This example illustrates how you can combine AFF and RETAIN in the same job step. RETAIN is used to avoid issuing mount requests for the same tape.
With AFF alone, the same tape drive is used but a mount request is still issued for the same tape. The operator has to go and push a button on the tape drive. This can be avoided by retaining the volume since all three data sets reside on the same tape.
//STEP1 EXEC PGM=PROG1
//IN1 DD DSN=FILE.ONE,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
//STEP2 EXEC PGM=PROG2
//IN2 DD DSN=FILE.TWO,UNIT=TAPE,VOL=SER=TAPE1,
// DISP=OLD,LABEL=2
//STEP3 EXEC PGM=PROG3
//IN3 DD DSN=FILE.THREE,UNIT=TAPE,VOL=SER=TAPE1,
// DISP=OLD,LABEL=3
*Keeping a Tape Mounted
The VOL subparameter RETAIN can also be used to keep a tape mounted between steps.
Suppose you want to run a job with three steps: the first step reads FILE.ONE, the second step reads FILE.TWO and the third step reads FILE.THREE.
All three files are on the same tape. This is the JCL to run the job.
//STEP1 EXEC PGM=PROG1
//IN1 DD DSN=FILE.ONE,UNIT=TAPE,VOL=SER=TAPE1,DISP=OLD
//STEP2 EXEC PGM=PROG2
//IN2 DD DSN=FILE.TWO,UNIT=TAPE,VOL=SER=TAPE1,
// DISP=OLD,LABEL=2
//STEP3 EXEC PGM=PROG3
//IN3 DD DSN=FILE.THREE,UNIT=TAPE,VOL=SER=TAPE1,
// DISP=OLD,LABEL=3
*Issuing a Mount Request for the Same Tape
With this JCL, each step issues a mount request for the same tape.
As you learned, you can avoid the need to remount the tape at each step by using RETAIN. On the next screen, you'll see the same JCL with RETAIN coded in the VOL parameter.
//STEP1 EXEC PGM=PROG1
//STEP2 EXEC PGM=PROG2
//STEP3 EXEC PGM=PROG3
//IN3 DD DSN=FILE.THREE,UNIT=TAPE,VOL=SER=TAPE1,
// DISP=OLD,LABEL=3
*Why RETAIN Isn't Included in STEP3
In STEP1 and STEP2, VOL=SER=TAPE1 becomes VOL=(,RETAIN,SER=TAPE1)
The tape remains mounted at the end of STEP1 to be used in STEP2. It remains mounted at the end of STEP2 for use in STEP3. Since STEP3 is the last step that uses the tape, RETAIN is not needed.
Question 64
Question 65
Topic 7.3: Premounting Tapes
*Moving OnYou've seen how JCL parameters affect the mounting of tapes, for example, using DEFER or AFF in the UNIT parameter or RETAIN in the VOL parameter.
Let's move on.
*Mounting Volumes in Advance
In JES2 installations, you can identify any tape volumes to be mounted before a job executes by using the /*SETUP statement.
The format of the /*SETUP statement is:
/*SETUP serial-number1,serial-number2,...
For example: /*SETUP 123 specifies volume 123 should be premounted.
/*SETUP 123,456 specifies volumes 123 and 456 should be premounted.
*Coding the /*SETUP Statement
When /*SETUP is used in a job, JES2 issues a message to the operator when the job enters the system, requesting that the specified volume(s) be mounted. The job is put on hold status.
The job is kept on hold until the volume is mounted and the operator releases the job for execution.
The /*SETUP statement should be coded:
- After the JOB statement and any /*ROUTE XEQ or /*XEQ statements AND
- Before the first EXEC statement.
The /*SETUP statement cannot be continued. Additional /*SETUP statements can be coded as needed.
Topic 7.4: Unit 7 Summary
The following points were covered in this unit:- If the program closes the current file before it opens the next one, then
you can defer mounting the next tape until the program opens the next file.
You defer mounting by specifying DEFER in the UNIT parameter
of the DD statement. DEFER is the third positional
subparameter in the UNIT parameter. It looks like this:
UNIT=(device type,,DEFER).
- If you want to ensure that the same tape drive is used, specify unit
affinity with the AFF subparameter of the UNIT parameter:
UNIT=AFF=ddname.
- AFF can also be used to retain a tape between file access.
Specify unit affinity when you use several files on the same tape. You want to
leave the tape on the same drive and go on with the next file on the
tape.
- You can combine AFF and RETAIN in the same job step.
RETAIN is used to avoid issuing mount requests for the same tape.
With AFF alone, the same tape drive is used but a mount request is
still issued for the same tape.
- The VOL subparameter RETAIN can also be used to keep a tape
mounted between steps.
- In JES2 installations, you can identify any tape volumes to be mounted
before a job executes by using the /*SETUP statement. The format of
the /*SETUP statement is:
/*SETUP serial-number1,serial-number2,...
No comments:
Post a Comment