z/OS DFSMSdfp Utilities
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


RECORD Statement

z/OS DFSMSdfp Utilities
SC23-6864-00

The RECORD statement is used to define a record group and to supply editing information. A record group consists of records that are to be processed identically.

The RECORD statement is used when: the output is to be partitioned; editing is to be performed; or user labels for the output data set are to be created from records in the data portion of the SYSIN data set. The RECORD statement defines a record group by identifying the last record of the group with a literal name.

If no RECORD statement is used, the entire input data set or member is processed without editing. More than one RECORD statement may appear in the control statement stream for IEBGENER.

Within a RECORD statement, one IDENT or IDENTG parameter can be used to define the record group; one or more FIELD parameters can be used to supply the editing information applicable to the record group; and one LABELS parameter can be used to indicate that this statement is followed immediately by output label records.

If both output header labels and output trailer labels are to be contained in the SYSIN data set, you must include one RECORD statement (including the LABELS parameter), indicating the number of input records to be treated as user header labels and another RECORD statement (also including the LABELS parameter) for user trailer labels. The first such RECORD statement indicates the number of user header labels; the second indicates the number of user trailer labels. If only output trailer labels are included in the SYSIN data set, a RECORD statement must be included to indicate that there are no output header labels in the SYSIN data set (LABELS=0). This statement must precede the RECORD LABELS=n statement which signals the start of trailer label input records.

For a further discussion of the LABELS option, refer to Processing User Labels.

The syntax of the RECORD statement is:

Label Statement Parameters

[label]

RECORD

[{IDENT|IDENTG}=(length,
'
name',input-location)]
[,FIELD=([
length],
[{
input-location|
'
literal'}],
     [
conversion],
[
output-location])]
[,FIELD=...]
[,LABELS=
n]

where:
{IDENT|IDENTG}= (length,'name',input-location)
identifies the last record of a collection of records in the input data set. You use this parameter to identify the last record to be edited according to the FIELD parameters on the same RECORD statement. If you are creating a partitioned data set or PDSE, this parameter will identify the last record to be included in the partitioned data set or PDSE member named in the previous MEMBER statement. If the RECORD statement is not followed by additional RECORD or MEMBER statements, IDENT or IDENTG also defines the last record to be processed.

IDENT is used to identify a standard, single-byte character string. IDENTG is used to identify a double-byte character string.

The values for IDENT or IDENTG can be coded:
length
specifies the length (in bytes) of the identifying name. The length of your identifier cannot be greater than eight.

For IDENTG, the length must be an even number.

'name'
specifies the literal that identifies the last input record of a group of records. 'Name' must be coded within single apostrophes.

If you are using IDENTG, 'name' must be a double-byte character string. The DBCS string must be enclosed in shift-out/shift-in (SO/SI) characters. The SO/SI characters will not be considered part of the literal specified by 'name', and they should not be included in the count for length. IEBGENER will disregard the SO/SI characters when it looks for a match for 'name'.

'Name' can be specified in hexadecimal. To do so, code 'name' as name . Thus, if you do not have a keyboard that can produce certain characters, you can specify them in their hexadecimal versions. The values of the SO/SI characters are X'0E' and X'0F', respectively.

If no match for 'name' is found, the remainder of the input data is considered to be in one record group; subsequent RECORD and MEMBER statements will be ignored.

input-location
specifies the starting position of the field that contains the identifying name in the input records. Input-location should be coded as a whole decimal number.

If you do not specify IDENT or IDENTG, all of the input data is considered to be in one record group. Only the first RECORD and MEMBER statements will be used by IEBGENER.

FIELD=([length], [{input-location| 'literal'}], [conversion],[output-location])
specifies field-processing and editing information. Only the contents of specified fields in the input record are copied to the output record; that is, any field in the output record that is not specified will contain meaningless data.

Note that the variables on the FIELD parameter are positional; if any of the options are not coded, the associated comma preceding that variable must be coded.

The values that can be coded are:
length
specifies the length (in bytes) of the input field or literal to be processed. If length is not specified, a length of 80 is assumed. If a literal is to be processed, a length of 40 or less must be specified.
input-location
specifies the starting position of the field to be processed. Input-location should be coded as a whole decimal number. If input-location is not specified, it defaults to 1.
'literal'
specifies a literal (maximum length of 40 bytes) to be placed in the specified output location. If a literal contains apostrophes, each apostrophe must be written as two consecutive apostrophes.

You can specify a literal in hexadecimal by coding X'literal' You can also specify a double-byte character set string as the literal.

conversion
specifies a code that indicates the type of conversion to be performed on this field. If no conversion is specified, the field is moved to the output area without change. The values that can be coded are:
CG
specifies that shift-out/shift-in characters are to be removed, but that DBCS data is not to be validated. DBCS=YES must be specified on the GENERATE statement.
CV
specifies that DBCS data is to be validated, and that the input records contain single-byte character set data as well as double-byte. DBCS=YES must be specified on the GENERATE statement.
GC
specifies that shift-out/shift-in characters are to be inserted to enclose the DBCS data. DBCS=YES must be specified on the GENERATE statement.
GV
specifies that DBCS data is to be validated, and that the DBCS data is not enclosed by shift-out/shift-in characters. DBCS=YES must be specified on the GENERATE statement.
HE
specifies that H-set BCDIC data is to be converted to EBCDIC.
PZ
specifies that packed decimal data is to be converted to unpacked decimal data. Unpacking of the low-order digit and sign may result in an alphabetic character. This maximum length of an input packed decimal field is 16380 bytes.
VC
specifies that DBCS data is to be validated, and that shift-out/shift-in characters are to be inserted to enclose the DBCS data. DBCS=YES must be specified on the GENERATE statement.
VG
specifies that DBCS data is to be validated, and that shift-out/shift-in characters are to be eliminated from the records. DBCS=YES must be specified on the GENERATE statement.
ZP
specifies that unpacked decimal data is to be converted to packed decimal data.

When the ZP parameter is specified, the conversion is performed in place. The original unpacked field is replaced by the new packed field; therefore, the ZP parameter must be omitted from subsequent references to that field. If the field is needed in its original unpacked form, it must be referenced before the use of the ZP parameter.

If conversion is specified in the FIELD parameter, the length of the output record can be calculated for each conversion specification. When L is equal to the length of the input record, the calculation is made as follows:
  • For a PZ (packed-to-unpacked) specification, 2L-1.
  • For a ZP (unpacked-to-packed) specification, (L/2) + C. If L is an odd number, C is 1/2; if L is an even number, C is 1.
  • For an HE (H-set BCDIC to EBCDIC) specification, L.
  • For the DBCS conversion codes, the shift-out/shift-in characters account for one byte each. If you add or delete them, you will have to account for the additional bytes.
output-location
specifies the starting location of this field in the output records. Output-location should be coded as a whole decimal number.

If output-location is not specified, the location defaults to 1.

LABELS=n
is an optional parameter that indicates the number of records in the SYSIN data set to be treated as user labels. The number n, which is a number from 0 to 8, must specify the exact number of label records that follow the RECORD statement. If this parameter is included, DATA=INPUT must be coded on a LABELS statement before it in the input stream.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014