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 - provided the data (including the BDWs and RDWs, if
necessary [all hypothetical, this]) was actually read in using the
program's changed LRECL etc., ... instead of hitting I/O errors during
the read (because the physical dataset's actual LRECL, not the changed
one in the program's DCB, defines how its data on DASD should be read).
The 'raw' data could be retrieved from DASD via CCWs, irrespective of
LRECL etc. (because data on DASD is I/O'd via CCW EXCPs anyway). So I
would expect a program's changed DCB attributes to override those on
DASD in the same way, as if processing 'raw' data. That would be *my*
interpretation of the program's DCB attributes having successfully
overridden those of the dataset on DASD when opened for input. But as
this does not happen, the program's DCB attributes 'overriding' those on
DASD is at best theoretical/academic. In practice, it is the attributes
on DASD which take precedence over those specified in the program's DCB
during input - and it is up to the program's DCB to comply with the
'attributes-on-DASD-first' order of priority for input, or hit I/O
errors. I do not consider a program's DCB having to *comply* with a
dataset's attributes on DASD, in order to function correctly, as
indicating that this program's DCB successfully *overrides* that
dataset's attributes on DASD.
If the DCB had 'FB,80' and the actual data had 'FB,90' - then I would
expect the first 80 bytes to be read in, then the next 81st to 160th
bytes etc. until all the data had been read in using 'FB,80' (and with
the last record in a block being appended with X'00's, if necessary, to
complete the 80 bytes).
Binyamin Dissen wrote:
On Mon, 1 Aug 2011 16:19:26 +0100 CM Poncelet <[email protected]> wrote:
:>Probably ... because my definition includes that the overriding DCB must
:>then also be able to read successfully the dataset whose DCB attributes
:>have been overridden - regardless of BDW, RDWs and data. Otherwise the
:>'standard' definition of "DCB override" is purely academic and of no
:>practical use. This 'standard' definition appears to mean that,
:>regardless of its attributes being consistent or not with those of the
:>dataset being read, the DCB which is opened first overrides the physical
:>dataset's DCB attributes (and if the dataset cannot then be read, that
:>is irrelevant). As I said earlier, 'DCB' includes 'DSCB' within the
:>context of my argument: I refer to them all as DCBs for the sake of
:>expediency.
Then what you want is to write a subsystem which will map the specified DCB to
the physical file.
That if the DCB shows VB,255 and the data is FB,80 the subsystem will convert
the data for you. Not sure what you would expect if the DCB show FB,80 and the
actual data is FB,90 - return partial records?
But the basic point - you have your own private definition of these terms. It
is if you are speaking a different language.
--
Binyamin Dissen <[email protected]>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
