On Tue, 2 Nov 2021 11:39:17 -0500, Tom Wasik wrote:
>How the internal reader handles instream data sets is documented here:
>https://www.ibm.com/docs/en/zos/2.4.0?topic=reader-record-length-sysin-data-sets
>https://www.ibm.com/docs/en/zos/2.4.0?topic=reader-sysin-record-formats
>Also note that JES2 and JES3 work differently.
>
Thanks. I had neglected to check the JES hooks, But the JCL Ref. for "DD *"
amd
"DD DATA" ought to include citations of that JES passage.
An omission I discovered by experiment which should be documented:
If no record exceeds 80 bytes (even if lengths differ),
attributes will be RECFM=FB,LRECL=80.
>But bottom line, for JES2, everything is based on the actual length of each
>record written. This gets a little tricky with TSO SUBMIT (or ISPF SUBMIT)
>commands. SUBMIT always writes records with a record length of 80. So all
>instream data sets are RECFM F and LRECL 80 when SUBMIT is involved. For
>other uses of the internal reader, as already stated, the RECFM is F if all
>records are the same length (including if there are 0 or 1 records). If the
>lengths of the record vary, the RECFM is V. CC is supported if the JCL
>(records) are written with CC (eg using IEBGENER from a RECFM VBM data set)
>and the RECFM is adjusted accordingly (fun rules for if there are both ASA and
>machine CC).
>
That "fun rule" ought to be documented. Your second citation says,
" ... If both ASA and Machine carriage control are detected, the record format
will be set in the RECFM."
It ought to show RECFM=what?
>Instream data set LRECL for RECFM F data sets is the length of the records.
>If there are 0 records (null data set), it is the length of the DD * or DD
>DATA card (very old rule). For RECFM V data sets, the LRECL is set to the
>length of the longest record in the instream data.
>
ITYM 4 + the length of the longest record.
Very terrible "very old rule" Is it documented?
>Note for all of this, each instream data set is processed separately. So each
>data set can have a different LRECL/RECFM.
>
Is that documented?
>As for LRECL on the DD * or DD DATA card, JES2 ignored this until APAR
>OA60172. Starting with that APAR, if an instream data set is RECFM F and
>LRECL is specified, JES2 will pad records for the data set up to the LRECL
>specified. This helps when using instream data concatenated to other RECFM F
>data sets.
>
>This is not to say that LRECL was totally ignored on a DD * or DD DATA card.
>When the DCB access method is used to read an instream data set (vs ACB/RPLs),
>the size of the buffer the access method passes to JES is determined by the
>LRECL specified on the DD. Also note that in a concatenation, the RECFM is
>determined by the first DD in the concatenation. A customer trying to
>concatenate a RECFM V data set to a RECFM F instream data set with LRECL
>specified led to APAR OA62088. You see the fix for APAR OA60172 added too
>much padding to an instream data set. Basically, LRECL on the instream DD
>statement in that case included the 4 byte RDW prefix but the ACB/RPL
>interface passes the actual length so padding to LRECL made the record 4 bytes
>too long.
>
>Hopefully this enlightens a bit on how all this works.
I submitted an RCF yesterday.
>Tom
>JES2 Development
Thanks,
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
