In <4e356a03.4060...@bcs.org.uk>, on 07/31/2011
at 03:43 PM, CM Poncelet <ponce...@bcs.org.uk> said:
>they 'count' as program DCBs is short-speak for 'they are executable
>code' (as opposed to JCL and DASD)
A DCB is not executable code; it is a data area.
>I know that; but on input they do not override the DCB from DASD
Changes made by the DCB exit do override; nobody claimed that the DSCV
or JFCV override the DCB. That's the same processing as for output.
>'short-speak' for they 'they are part of program code execution' in
>the 'program -> JCL -> DASD' sequence
"Part of" is not the same as "first", and there is no "'program -> JCL
-> DASD' sequence".
>I am speaking within the context of the priority order of DCBs in
>the 'program -> JCL -> DASD' sequence
Incorrectly.
>I don't need to check "Using Data Sets"
Then why do you keep getting it wrong.
>Galileo did not need to check "the Bible"
You are not Galileo
>was that his first mistake?
No; perhaps his first mistake was claiming that comets were
atmospheric phenomena.
>in that case it was one of OS/VS1 to MVS/SP
No.
>(I don't spend time remembering these things, except vaguely)
Obviously.
>I think you are splitting hairs for the sake of arguing ...
No, just trying to explain things to the willfully ignorant.
In <4e35844d.8030...@bcs.org.uk>, on 07/31/2011
at 05:35 PM, CM Poncelet <ponce...@bcs.org.uk> said:
>Before the DCB on DASD can be accessed,
I hope that you mean "data set attributes in the DSCB1".
>the program's own 'completed' DCB (including any missing DCB
>parms filled-in from a RDJFCB of the JCL's DD and/or from an exit,
>if present) must be opened.
Here's one place where you're going wrong. A JFCB entry in the DCB
exit list is distinct from a DCB exit entry, and points to a data area
rather than to an exit. The DCB exit specified in the DCB exit list is
not called at the beginning of the merge, but after the end of it.
>But the DASD DCB attributes
Here's another place where you are going wrong; you are confusing
dataset attributes with the physical records in the dataset.
>in the sense that the data on DASD will be INPUT without I/O
>error only if the opened program DCB's attributes are the same as
>those on DASD.
No. As others have explained, BSAM/QSAM will read the data without I/O
error only if the physical records in the data set are small enough to
fit in the buffer, which is sized[1] as the resolved BLKSIZE. The
sizes of the physical records are not dataset attributes as the term
is used by OPEN et al.
>The program's DCB attributes take priority over (i.e. 'override')
>the DCB attributes on DASD for OUTPUT, and the DCB attributes on
>DASD take priority over (i.e. 'override') the program's DCB for
>INPUT.
Repeating it won't make it true.
>If a program 'disagrees' with that and tries to override the DCB
>attributes on DASD anyway, with its own DCB attributes and for an
>INPUT, it crashes with an I/O error.
Only if it does so improperly.
>Crashing with an I/O error indicates that the program's DCB was
>unable - not able - to override the DCB attributes
>on DASD.
No, as Binyamin has explained to you multiple times.
>On INPUT, the programs' DCB does not even change the RECFM, LRECL
>and BLKSIZE on DASD
Demonstrably false.
>- never mind the physical data.
Nobody claimed that it altered the physical data in the dataset.
[1] Discussion omits concatenation for simplicity.
--
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
