Format of ISO/ANSI data set label 1 (HDR1/EOV1/EOF1)

Figure 1 shows the format of HDR1, EOV1, and EOF1. The shaded areas represent fields that the operating system writes in the label, but are not used or verified during processing. The contents and processing of each field of the label are described, as are differences between the ISO/ANSI labels and the IBM labels.

Figure 1. Format of ISO/ANSI header 1 and trailer 1 labels

1—Label Identifier (3 bytes)

Contents: Three characters that identify the label are as follows:
- HDR
  
  Header label (at the beginning of a data set)
  
  EOV
  
  Trailer label (at the end of a tape volume, when the data set continues on another volume)
  
  EOF
  
  Trailer label (at the end of a data set).
Processing: The system checks this field to verify that the record is an ISO/ANSI data set label.
For input data sets, the system checks the label identifier to determine whether data set processing should continue. When the system finds an EOV label, it performs volume switching. When the system finds an EOF label, it passes control to the user's end-of-data routine or continues processing with a concatenated data set.

If the DD statement specifies OPTCD=B for an input data set, the trailer label identifier (EOV or EOF) is not used to determine whether a volume switch is necessary. If more volumes are available, the system performs the switching. If no volumes are available, the system passes control to the user's end-of-data routine or continues processing with a concatenated data set.

When creating trailer labels, the EOV routine writes EOV in this field, and the close routine writes EOF.

2—Label Number (1 byte)

Contents: The relative position of this label within a set of labels of the same type; it is always 1 for data set label 1.
Processing: Verified and written in conjunction with Field 1 to identify this label as HDR1, EOV1, or EOF1.

3—File Identifier (17 bytes)

Contents: The rightmost 17 bytes of the data set name, not including the suffix .GxxxxVyy for generation data sets. Version 1 tapes will continue to be accepted for input with the suffix included as part of the file identifier. If the data set name is fewer than 17 bytes, it is left-justified and the remainder of this field is padded with ASCII space characters.
If the name contains embedded spaces or other special characters, you must enclose the name in apostrophes on the DD statement that requests this data set. z/OS MVS JCL User's Guide lists the restrictions that apply to enclosing a data set name in apostrophes. The apostrophes do not appear in the data set identifier field.
Processing: For input, this name is compared to the user-specified data set name found in the JFCB. This comparison ensures that the correct data set is being processed. For Version 3 only, the file identifier is also compared to the names of other data sets on the volume during open positioning to ensure against duplicate names. See Processing the HDR1 label for more information.
For output, the data set name in the existing label is verified in conjunction with password protection to determine whether the existing data set can be overwritten. If password protection is not specified, then the data set name is checked for valid Version 3 or Version 4 characters.

For input and output the first file data set identifier is compared with the last 17 characters of the first file data set name recorded in the DFSMSrmm control data set. If there is no match, the volume is rejected. This check ensures that the correct volume is mounted.

When creating labels for a new data set, the user-specified data set name is obtained from the JFCB and recorded in this field.
Difference from IBM Field: The corresponding field in an IBM standard label is called the Data Set Identifier.

4—File Set Identifier (6 bytes)

Contents: The volume serial number of the tape volume containing the data set. For multivolume data sets, this field contains the serial number of the first volume of the aggregate created at the same time.
The content requirements are the same as for the volume serial number field in the volume label.
Processing: If this field has inconsistent values in the volumes in a volume set as described in Figure 1 and Figure 2, the system writes a warning message . The warning indicates that one of the volumes might be the wrong volume. The message number is IEC709I. When creating labels, the serial number is obtained from the UCB and recorded in this field.
Difference from IBM field: The corresponding field on an IBM standard label is called the Data Set Serial Number.

5—File Section Number (4 bytes)

Contents: A number (0001 to 9999) that indicates the order of the volume within the multivolume aggregate. This number is always 0001 for a single volume data set.
Processing: If this field does not have a value one greater than the previous volume in a volume set as described in Figure 1 and Figure 2, the system writes a warning message IEC709I. This message warns you that the volumes might be out of order. When creating labels, the open routine writes 0001 in this field if the data set sequence number is 1; otherwise the open routine copies the corresponding value from an earlier label on the volume. The EOV and close routines write a number one higher than on the previous volume.
Difference from IBM Field: The corresponding field on an IBM standard label is called "Volume Sequence Number".

6—File Sequence Number (4 bytes)

Contents: A number (0001 to 65535) that indicates the relative position of the data set within a multiple data set group (aggregate). This number is always 0001 for a single data set organization.
Processing: This number in the first HDR1 label on the tape is referred to when the open routine positions the tape. If this number in the first HDR1 label and the requested data set sequence number in the JFCB are both greater than 1, then the logical data set sequence number in the UCB is set to the number in the label. Otherwise, the logical data set sequence number in the UCB is set to 1.
When creating labels, the open and close routines obtain the user-specified data set sequence number from the JFCB (0 is changed to 1). The EOV routine propagates the number.

7—Generation Number (4 bytes)

Contents: If the data set is part of a generation data group, this field contains a number from 0001 to 9999 indicating the absolute generation number (the first generation is recorded as 0001). If the data set is not part of a generation data group, this field contains 0001.
Processing: A nonnumeric or all zero value is not valid, and can cause the label validation exit to be entered unless validation has been suppressed.
When creating labels, the system checks the JFCB to determine whether the data set is part of a generation data group. If so, the generation number is obtained from the last part of the data set name in the JFCB. Otherwise, this field is recorded as 0001.

8—Version Number (2 bytes)

Contents: If the data set is part of a generation data group, this field contains a number from 00 to 99 indicating the version number of the generation (the first version is recorded as 00). If the data set is not part of a generation data group, this field contains ASCII zeros.
Processing: The system always records this field as zeros. For a version level other than zero, you must specify the absolute generation and version numbers as part of the data set name when creating or retrieving a data set.

9—Creation Date (6 bytes)

Contents: Date when allocation begins for creating the data set. The date is format cyyddd, where:
```
  c = century (blank=19; 0=20; 1=21; etc.)
 yy = year (00-99)
ddd = day (001-366)
```
Note: The century code gives the first two digits of the year, not the actual century. For example, a blank that translates into 19 indicates a year in the 1900s, not in the nineteenth century.
Processing: Not used or verified, except to check for proper format. When the system creates labels, the date is obtained from the JFCB. If a data set is allocated via JCL, then the creation date is the date when allocation begins for the job step responsible for creating the data set. If a data set is allocated dynamically, then the creation date is the date when allocation begins for the data set.

10—Expiration Date (6 bytes)

Contents: Year and day of the year when the data set may be scratched or overwritten. The data is shown in the format cyyddd, where:
```
  c = century (blank=19; 0=20; 1=21; etc.)
 yy = year (00-99)
ddd = day (001-366)
```
Note: The century code gives the first two digits of the year, not the actual century. For example, a blank that translates into 19 indicates a year in the 1900s, not in the nineteenth century.
Processing: For input, not used or verified, except to check for proper format. For output, the expiration date in the existing label is compared to the current date. If the date in the label is later than the current date, then the operator receives a message and has the option of using the tape or mounting another. If other data sets are on the same volume, then the system checks the expiration date of the immediately preceding data set. If the previous data set's expiration date is earlier than that of the output data set, then the label validation exit is entered (unless label validation has been suppressed). If any other data sets follow on the same volume, then they are considered expired on the same day. The expiration dates of scratch SMS-managed tape volumes, both automatic and manual tape libraries, are ignored. DFSMSrmm can override the expiration date or reject the volume without operator intervention.
If you enter 99365 or 99366, the system retains your data sets permanently. Do not use those dates as expiration dates. Use them as no-scratch dates only.

When creating labels, the system obtains the expiration date from the JFCB. If you did not specify a retention period or expiration date, then the expiration date is recorded as zeros, and the data set expires. DFSMSrmm uses the expiration date to update information its control data set. For data sets without an expiration date, DFSMSrmm assigns one using the DFSMSrmm default retention period, but the label field is left as zeros.

11—Accessibility (1 byte)

Contents: A code indicating the security status of the data set, as follows:
Valid Version 3 or Version 4 characters:

If the volume is not RACF protected, the file access exit is entered.

Space

No data set access protection.

1

Password protection. Additional identification of the data set is required before it can be read, written, or deleted. (Ignored if volume is RACF defined.) Password protection can be specified in the PASSWORD subparameter of the LABEL keyword of JCL.

3

Password protection. Additional identification of the data set is required before it can be written or deleted. (Ignored if volume is RACF defined.) This can be specified in the NOPWREAD subparameter of the LABEL keyword of JCL.

Other character

Protected volume. No access is possible under the operating system, unless the volume has been defined to RACF and is authorized for use by RACF.
Processing: For input, the system inspects this field on a single volume data set, on each concatenated data set, and on each volume of a multivolume data set. If password protection is specified in this field, the system verifies the password furnished by the operator or TSO terminal user and sets a security indicator in the JFCB. If a valid Version 3 or Version 4 character is specified and the volume is not defined to RACF, the file access exit is entered (the IBM-supplied exit routine will reject the volume). If a character other than an ASCII character is encountered, the DCB will not be opened and no further processing will take place.
For output, the system inspects this field in the existing HDR1 label. If 1 or 3 is specified with the system code "IBMZLA", the existing data set cannot be overwritten until the system verifies the password and the data set name in Field 3 of this label. Password checking is bypassed if the volume is defined to RACF. If you specify a data set name different from the one in Field 3, and the data set is the first one on the first or only volume, the operator must remove the tape and mount a scratch tape, even though you requested a specific volume. If the data set is not the first one on the volume or this is not the first volume of a multivolume data set, the job is abnormally terminated. If a valid Version 3 or Version 4 character is specified and the volume is not defined to RACF, the file access exit will be entered (the IBM-supplied exit routine will reject the volume).

When the system creates labels, the user's request for security is determined from the indicator in the JFCB for password processing or from a JCL ACCODE value. Password codes override ACCODE values if they are both specified.

12—Block Count (6 bytes)

Contents: This field in the trailer label shows the number of data blocks in the data set on the current volume. This field in the header label is always 000000.
Processing: The DCB block count (in the device-dependent area of the DCB) is increased as the data set is read. The final DCB count is compared with the count in the trailer label at end of data or end of volume. If the counts do not agree, a user exit entry in the DCB exit list determines whether processing continues or abnormally terminates. A block count discrepancy causes processing to abnormally terminate if the appropriate user exit entry is not provided.
For read backward, the verification process is reversed. The trailer label count is recorded in the DCB and decreased as the data set is read. The final DCB count should be 0, which is equal to the count in the header label.

When the system creates labels, the block count in the header label is set to 000000. The block count in the trailer label is obtained from the DCB during close and EOV label creation.

If the data set was created with an EXCP DCB that had no device-dependent area, and the volume was not rejected, the block count is written as zero and is not verified. For tapes with Version 3 labels, a data set opened without at least a 4-word device-dependent area in the DCB will cause the label validation exit to be entered with a symmetry error, unless validation has been suppressed. The default of the exit is to reject the volume.

13—System Code (13 bytes)

Contents: A unique code, IBMZLA, that identifies the system.
Note: Version 1 tapes produced by MVS contain OS/360 or OS/370 as a system code.
Processing: On input, the field is checked to determine how succeeding labels are to be processed (the field determines whether Field 3,"Record Format", and Field 6,"Reserved for Operating System", in the second header label will be processed). On output, the operating system supplies the IBMZLA code.

14—Reserved for Future Standardization (7 bytes)

Contents: Reserved for possible future use; contains blanks.
Processing: Not used or verified, except to check for blanks. When creating labels, the system writes blanks in this field. Blanks are translated to ASCII space characters on output.