In <4e37505a.7090...@bcs.org.uk>, on 08/02/2011
at 02:18 AM, CM Poncelet <ponce...@bcs.org.uk> said:
>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
That is an unreasonable expectation. It is the responsibility of the
user to determine whether an override is appropriate and to determine
whether an input dataset matches the requirements of the application.
If the data length on DASD exceeds the block size, why would you
expect anything other than an I/O error. If your specify RECFM=FB and
the data length is not a multiple of LRECL, why would you expect
anything but a logical error?
>The 'raw' data could be retrieved from DASD via CCWs, irrespective
>of LRECL etc.
At which point it is the programmer's responsible to figure out how to
handle them.
>So I would expect a program's changed DCB attributes to override
>those on DASD in the same way, as if processing 'raw' data.
It does. What it doesn't do is to magically figure out that you didn't
really mean it when you provided the wrong attributes.
>That would be *my* interpretation of the program's DCB attributes
>having successfully overridden those of the dataset on DASD when
>opened for input.
Your interpretation is irrelevant; what matters is the documentation
that you refuse to consult.
>But as this does not happen, the program's DCB attributes
>'overriding' those on DASD is at best theoretical/academic.
No, just unrelated to anything that IBM claims to do. Again, you are
confusing the dataset with the DSCB1 describing the dataset.
In <4e3758a4.8070...@bcs.org.uk>, on 08/02/2011
at 02:53 AM, CM Poncelet <ponce...@bcs.org.uk> said:
>Quite possibly; but it's a contrived case
The fact that you don't understand it doesn't make it contrived. The
fact is that what Binyamin describes is relatively common among those
that understand the software, and quite useful.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
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
