I've never used it, but this seems to be a basic function of IEBGENER(and
therefore SYNC/ICE GENER)
.8.2.5 RECORD Statement
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" in topic C.2. The syntax of the RECORD statement is:
___________ ___________ ________________________________________________
| [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.
Dave Gibney
Information Technology Services
Washington State University
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]]
> On Behalf Of Paul Gilmartin
> Sent: Tuesday, December 11, 2012 12:38 PM
> To: [email protected]
> Subject: Re: Using SyncSort to deblock records in a file
>
> On Tue, 11 Dec 2012 12:27:01 -0600, Mike Schwab wrote:
>
> >Override the attributes on input?
> >
> >RECFM=FB,LRECL=82,BLKSIZE=1804.
> >
> You could probably do it with IEBGENER or IDCAMS REPRO with
> suitable overrides on SYSUT1 and SYSUT2.
>
> -- gil
>
> >On Tue, Dec 11, 2012 at 11:15 AM, Gary Jacek wrote:
> >>
> >> I am trying to use SyncSort for zOS V1.4.0.1R to deblock a file.
> >>
> >> For each input record, I want to write the first 82 bytes as output record
> >> 1,
> >> followed by the next 82 bytes as output record 2,
> >> followed by the next 82 bytes as output record 3,
> >> and so on until all 22 output records (22x82=1804) have been written.
>
> -- gil
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
