CM, Wrong again (but should we be surprised)! The RDW is indeed part of
the logical record and is returned by the access method as part of the
logical record on input and expected as part of the record on output.
Some higher level languages (for example,COBOL) hide this from the
programmer because the high-level language semantics require it; but if
you had any experience with VB I/O on the assembler level this would be
obvious, or if you had ever used SORT on a VB file you would know the
field offsets must include the RDW bytes as they are part of the logical
record. Once again you are the blind man, trying to understand the
concept of an elephant by feeling one part of its body rather than
listening to those with sight.
CM, Why do you insist on continuing to embarrass yourself by pretending
to speak with authority on things you obviously do not or no longer
understand and are unwilling to take the time to learn or re-learn? If
you now spend too little of your time with MVS to remember correctly how
things work, you should just recognize that and cease pretending to be
an authority and showing your ignorance. Your supposed 'reductio ad
absurdum' argument is itself absurd because it is totally dependent on
your redefining "override" to mean "override with valid results", or on
mis-applying the word to the physical dataset blocks or the dataset VTOC
entry rather than the in-memory program DCB fields to which it clearly
is intended to apply. "Override" simply does not have any implied
secondary meaning of "validity" or "success" in the English language,
and no one but yourself has chosen to make that invalid assumption.
Your arguments also make no sense when you fail to properly distinguish
between physical dataset content, fields in the DSCB VTOC entry,
parameters in the DD, and fields in the program DCB, as the whole
argument in this thread centers around understanding how all these
separate and distinct pieces all interact -- and they interact only in
the ways they are documented to interact, not the ways you think might
be nice for them to interact. I get the feeling you are very fuzzy
about the physical representation of datasets on DASD or you wouldn't
even make some of the assertions you make. King George and a majority
of Parliament "overrode" the advice of wiser men and lost the American
Revolution. You have attempted to override the meaning of "override",
and have totally lost the argument.
Seymour, good comments in your 8/2 0750 post. I guess the logical
corollary of CM expecting it to be reasonable to raise an IBM PMR to
eliminate errors caused by user misuse of JCL DD or program DCB
parameters would be to expect IBM to also fix all compilers to take any
program that was sytactically correct but semantically inappropriate for
the incoming data fields, to magically determine what the programmer
really intended, and change the program to modify the incoming data so
the program would run without errors. To use your tools in this
business you have to understand them well enough to know what they are
designed to do, what they are not capable of doing, and that to keep
implementation practical, the effect of some usage errors are just
deliberately left undefined or unpredictable. CM just doesn't seem to
get it. Maybe he's really an undercover MS agent and is just trying to
distract the group from moving workloads to the z platform.
Joel C. Ewing
On 08/03/2011 07:38 AM, CM Poncelet wrote:
Gerhard Postpischil wrote:
On 8/2/2011 3:11 PM, CM Poncelet wrote:
this. But in any case the BDW and RDW would not be loaded into
the buffer.
The BDW and RDW are always included in the buffer. They may not be
seen at the application level (e.g., on a ForTran read or write, or in
CoBOL).
Well yes, they have to be loaded into VS to be processed. In the case of
block read/writes they precede the data records in the buffer. But
whatever was being discussed at the time I wrote that had to do with
record read/writes, in which case the BDW and RDW would not be
accessible from the buffer: so perhaps I should have said 'not
accessible' instead of 'not loaded'.
I have no time for that. If something is true it can remember
itself; if it is false it is not worth remembering. Hence I
remember what I am dealing with and forget it afterwards. Do you
expect me to *remember* system control blocks?
But as is obvious from this thread, you are making assertions based on
(mis)information where you should have refreshed your memory. I still
don't know what you meant by "CCW EXCPs", for example.
If I dealt only with MVS, I would have the time to refresh my memory:
but I don't; I work with subsystems. By CCW EXCPs I am simply
emphasising the fact that the channel programs (CPs) are issuing CCWs
(which have direct access to DASD devices).
'DCB' is shorter than the 'RECFM=,LRECL=,BLKSIZE=' I am actually
referring to when I say 'DCB'; so I say 'DCB' for short.
'Data format' is also shorter than those, and a lot less ambiguous.
True. I translate my thoughts into words and for this I use whatever
suitable word - not necessarily the most appropriate one - first comes
to mind.
Gerhard Postpischil
Bradford, VT
...
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
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
