I am proving by 'reductio ad absurdum' that if the assertion is true,
then its consequences are absurd: and hence that the assertion is false.
You are discussing the absurd consequences which would follow from the
assertion being true. The point I am illustrating is that you cannot
impose a common rule both for output and input, yet have one 'logic set'
of consequences for output and a different one for input.
Shmuel Metz (Seymour J.) wrote:
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.
----------------------------------------------------------------------
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
