To quote Mark Twain: "It ain’t what you don’t know that gets you into
trouble. It’s what you know for sure that just ain’t so."
After dealing with computers for 40+ years, I can tell you that some of
the most important concepts are (1)to know when you don't know the right
answer, (2)know where to find the right answers, and (3)have enough
curiosity to look up the right answer, especially if multiple people
tell you that of which you are certain is wrong. You seemed to have
unfortunately managed to remember some false things that in your words
were "not worth remembering".
No one expects one to remember all the fields in all the system control
blocks, much less values from specific dumps, but you do have to
remember enough of the basics in order to make sense out of what the
manuals tell you. The arguments in this thread over the last several
weeks have basically boiled down to a failure to make a proper
distinction between DCB attribute values stored in a program DCB versus
similar values maintained in a DSCB in a DASD VTOC, and the related
refusal to understand that when talking about overrides to DCB
parameters that this is an explicit reference to
overriding/changing/altering field values in a DCB control block and has
nothing to do with altering data content of existing datasets or
existing DSCB values in the VTOC.
One should also remember enough of the basics to understand that it is
the merged DCB values in the in-memory DCB that control how the access
methods manipulate data associated with physical data blocks, not the
DASD DSCB, which only contributes during the OPEN processing.
Understanding that the physical DASD representation of VB sequential
files contains embedded record/block control information and variable
block sizes, versus FB files with no control information but physical
block sizes constrained by both LRECL and BLKSIZE is also pretty basic
stuff - and if you understand that, you would never expect any merge of
DCB parameters that attempted to read existing physical data with the
wrong V versus F RECFM protocol to do anything useful. That the attempt
fails doesn't mean the DCB merge didn't work as documented, it means you
have managed to construct a dataset, JCL, program combination that
violates the semantic rules of MVS. It doesn't take much experience
with MVS macros or JCL parameters to learn that syntactic correctness
doesn't prevent semantic nonsense.
To almost take pride in not having the time to consult appropriate
references, and yet at the same time be adamant that you are right and
others wrong when they have, is not exactly a way to win admiration
among this group. Working with computers is not like belonging to the
Tea Party. When it comes down to what works, only facts matter,
opinions don't.
Joel C. Ewing
On 08/02/2011 02:11 PM, CM Poncelet wrote:
Gerhard Postpischil wrote:
On 8/1/2011 9:53 PM, CM Poncelet wrote:
Quite possibly; but it's a contrived case where the 2nd LRECL is
a fixed length multiple of the first (so there is one BDW and
one RDW, and the records follow each other consecutively in the
buffer).
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, probably confusing
controlintervals (which always have a CIDF and at least one RDF) with
blocks. I would have to dump a non-VSAM dataset to verify this. But in
any case the BDW and RDW would not be loaded into the buffer. So, if
SORT is doing GLs to read the records from the buffer, it will have no
problem reading 2*80 instead of 80 bytes at a time - because the BLKSIZE
is a multiple of 160, the buffer size is the same as the BLKSIZE and the
records are fixed length.
to avoid I/O errors. Hence, the assertion that DCB attribute
override priority is 'program -> JCL -> DASD' is true if the DCB
is opened for output; but it is false (or at least 'it does not
work', for the benefit of those who can stomach only a
politically correct version of the truth) if it is opened for
input, because it then hits I/O errors.
DCB is short for Data Control Block. These exist only in memory, and
are specific to the zOS operating systems (and earlier MVS and
OS/360). I can read DASD written on MVS on VSE, and vice versa. VSE
has no DCBs, but it manages to read data anyway.
... and DSCB is short for Data Set Control Block, SIOT is short for Step
I/O Table, JFCB is short for Job File Control Block, etc. - but thanks
for reminding me.
On DASD, each block of data is preceded by a count field containing a
logical (alternate track) or physical address (CCHHR), a key length,
and a data length. There is no RECFM, no LRECL, and the physical block
may have a length other than that specified by BLKSIZE. Regardless of
how often you repeat yourself, there is no DCB on DASD.
Furthermore, your discussion of I/O seems to indicate that either you
do not understand English, or that you are unaware of the differences
between BSAM and QSAM. I would suggest that you read up on system
control blocks, notable the IOB and ICB, look at some in a dump, and
get a better understanding of how I/O functions. 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. 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? When I *need* to remember them, I dump them and
look at them - or I look at the "Data Areas" manuals or at the DSECTs -
and then I forget about them again, unless I am still using them that
is. I have been reading system dumps for more than 25 years, but don't
expect me to *remember* them afterwards. This topic is about the order
of priority of DCB attributes when opening a dataset for input v.
output, and not about system control blocks. If it were about the
latter, I would check and re-remember them beforehand: but as it isn't,
I don't bother (I have other things to get on with).
'DCB' is shorter than the 'RECFM=,LRECL=,BLKSIZE=' I am actually
referring to when I say 'DCB'; so I say 'DCB' for short.
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
