Tom Marchant wrote:
On Tue, 2 Aug 2011 20:11:27 +0100, CM Poncelet <ponce...@bcs.org.uk> wrote:
Gerhard Postpischil wrote:
His example used RECFM=FB, so there are no BDWs and no RDWs (if there
were, then the first four bytes of the second record would be the RDW,
not data).
Yes ... and I am writing from memory,
Obviously, and your memory is in error. It would help if you would check
a reference manual rather than continuing to post incorrect information,
even after having been corrected multiple times.
But in
any case the BDW and RDW would not be loaded into the buffer.
Wrong again. The BDW and RDW of a variable length data set are
part of the data in the buffer.
Requisite manuals are
available online. While "Using Data Sets" is a bit daunting, it
contains most of the information.
I have no time for that.
Then why do you have time to post so much incorrect information?
If something is true it can remember itself;
Oh, really?
Do you expect me to *remember*
system control blocks?
Actually, no, I don't. But I do expect you to check what you post. We
all occasionally post incorrectly from memory, some of us more often than
others. Most of us will at least look it up after someone points out that
what we posted was wrong. You, on the other hand, repeatedly post the
same erroneous information and steadfastly refuse to look it up. Because
of that, I don't expect you to *know* what you are talking about.
I have been reading system dumps for more than 25 years
Well, good for you. I've been doing it for 40. I think Gerhard has been
doing it for considerably longer and I know that Shmuel has.
This topic is about the order
of priority of DCB attributes when opening a dataset for input v.
output,
And your insistence that there is a difference in the priority of filling in
the DCB between input and output is demonstrably wrong. There is no
difference. The DCB is filled in exactly the same way. If you don't believe
me, take dump after opening a data set for input and see what the
values are. Let me guess. you don't have time for that either.
But I do not dispute that the DCB is filled in exactly the same way for
output and for input (bar the flags being set for write or/and for read
etc.). I dispute that the program's DCB attributes for input prevail
over the attributes of the dataset (i.e. that they now temporarily
become the dataset's new attributes whether the dataset 'likes' it or
not) in the way that its DCB attributes for output prevail over them
(ditto, but permanently).
It all comes down to what is meant by 'override'. To me, 'override'
implies 'with successful completion and CC=00': otherwise an 'override'
was attempted but it failed. To others, it seems that 'override' means
nothing more than that the DCB was successfully assembled/link-edited
and opened at run time, and if the job then hits I/O errors well ... who
cares, because the important thing to understand about 'override' is
that it has nothing to do with whether the job can complete afterwards,
but has only to do with whether the DCB can be assembled cleanly etc.
and then opened. Is that some kind of joke?
How about applying this 'override' concept to JCL procedures, and
override say the PROC's STEPLIB with a VSAM file or DD DUMMY, then
submit the JCL. Does this mean the PROC's STEPLIB was successfully
overriden because the JCL could be submitted, and if the job then
abended well ... that does not matter, because the important thing was
to override STEPLIB and *that* was successful? That would open up an
interesting new perspective on software engineering ...
----------------------------------------------------------------------
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
