-------------------------------------------------<snip>--------------------------------------
What I would expect, if the program's DCB attributes 'overrode'/'took
precedence over'/etc. those of the physical dataset on DASD, is that the
attributes in the dataset's DSCB on DASD would be overriden by the
program DCB's attributes during the *read* (without changing the DSCB on
DASD), and whatever garbage was then read in, as a consequence of the
changed RECFM, LRECL and BLKSIZE in the program's DCB, would then be
acceptable - provided the data (including the BDWs and RDWs, if
necessary [all hypothetical, this]) was actually read in using the
program's changed LRECL etc., ... instead of hitting I/O errors during
the read (because the physical dataset's actual LRECL, not the changed
one in the program's DCB, defines how its data on DASD should be read).
---------------------------------------------<unsnip>--------------------------------------
The "Incorrect Length" error is usually generated by a CCW that
specifies a length smaller than the actual length of the block on the
DASD device. The CCW length, in turn, is set by the BLKSIZE value
supplied that is ultimately applied to the dataset, whether the value
comes from a program-coded value, a JCL value or the value specified in
the FORMAT-1 DSCB of the dataset. How the LRECL is used depends on the
RECFM value and the access method in use. For example, BSAM does NO
deblocking or blocking, expecting the program to take care of these
types of details. On the other hand, QSAM does all the blocking and
deblocking "under the covers", returning a logical record instead of a
complete block.
------------------------------------------------<snip>--------------------------------------
The 'raw' data could be retrieved from DASD via CCWs, irrespective of
LRECL etc. (because data on DASD is I/O'd via CCW EXCPs anyway). So I
would expect a program's changed DCB attributes to override those on
DASD in the same way, as if processing 'raw' data. That would be *my*
interpretation of the program's DCB attributes having successfully
overridden those of the dataset on DASD when opened for input. But as
this does not happen, the program's DCB attributes 'overriding' those on
DASD is at best theoretical/academic. In practice, it is the attributes
on DASD which take precedence over those specified in the program's DCB
during input - and it is up to the program's DCB to comply with the
'attributes-on-DASD-first' order of priority for input, or hit I/O
errors. I do not consider a program's DCB having to *comply* with a
dataset's attributes on DASD, in order to function correctly, as
indicating that this program's DCB successfully *overrides* that
dataset's attributes on DASD.
------------------------------------------------<unsnip>-----------------------------------
NO NO NO. The attributes in the FORMAT-1 DSCB can be over-ridden by JCL
OR DCB attributes in the program. They can also be altered to invalid
values by injudicious use of DCB attributes in a program or JCL when
adding/replacing a PDS member. Would you define a card reader with a
logical record length of 50 bytes, expecting that the next logical
record would be the last 30 bytes of the current image and 20 bytes of
the next image? On a card reader, the blksize is 80 bytes and record
format is either F or FB. Period. On DASD, the blocksize is that which
is written in the count field of the actual block, as written on the
disk. As far as the channel program is concerned, the only significant
length field is the one written in the block's count field.
Padding records with x'00' values when a block is "short", can lead to
all kinds of errors. Which values are valid for the program and which
ones are trash and should be ignored?
We won't even get into keyed records, which are still prominent in DASD
data management.
When half a dozen people, all with 30+ years of detailed experience,
tell you you're wrong, I strongly suggest you start cracking open some
manuals.
Rick
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
