On Sun, 31 Jul 2011 17:35:25 +0100, CM Poncelet wrote: >Before the DCB on DASD can be accessed, 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.
The DCB is completed during the open process >This might >suggest that the program's DCB, within the above context, overrides the >one on DASD. There is no DCB on DASD >But the DASD DCB attributes override the program's DCB >attributes when the data is actually read - 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. That's an interesting and unusual definition of "override". Now I see why you seem confused. When we talk about DCB parameters being overridden, we are talking about how the fields in the DCB are filled in. If, for example, the program has a blocksize specified in the DCB, the value in the DD statement or in the DSCB do not override that value. It stays the way it was coded in the program. That an I/O error might occur when reading the data set is not relevant to the way the DCB is filled in. >It is not the program's DCB >attributes (including any 'supplied' by exits etc.) but those on DASD >which take priority and 'decide' what the DCB attributes should be on >INPUT. If the program's DCB attributes could override those on DASD for >INPUT, the program's 1st read after opening the DCB for INPUT would not >fail with an I/O error if its DCB attributes were different from those >on DASD No. When we say that the DCB attributes in the program override those in the DCB, we are not saying that those attributes in the DSCB are modified. Indeed, if you have an existing data set with some RECFM, LRECL and BLKSIZE and you zap the DSCB to have different, incompatible values, when you try to open the you will get the same I/O errors as you would have if the DSCB was not altered but the program specified the incorrect DCB attributes. In fact, if the program specifies the correct attributes, there will be no errors. >On INPUT, the programs' DCB does not even change the RECFM, LRECL and >BLKSIZE on DASD - never mind the physical data. Of course not. That is not what it means when we say that the DCB attributes in the program override those in the DSCB. It means that the value in the DCB is the value specified in the program. If the program does not specify an attribute that attribute comes from the JCL. If it is not in the JCL either, it comes from the DSCB. >On OUTPUT, the program's DCB does change the RECFM, LRECL and BLKSIZE as >well as the physical data on DASD The data on the DASD are overwritten if the disposition is OLD for a PS data set. If the disposition is MOD or a member is written to a PO data set, the new data are written with the characteristics in the program. I don't know whether this will cause an error in the case of a MOD PS data set, or whether the attributes are modified in the DSCB. -- Tom Marchant ---------------------------------------------------------------------- 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
