In <4e395e34.1070...@bcs.org.uk>, on 08/03/2011
   at 03:41 PM, CM Poncelet <ponce...@bcs.org.uk> said:

>But I should get *no* I/O error at all on read if the DCB precedence 
>rules for output apply also to input,

False.


In <4e396dcd.60...@bcs.org.uk>, on 08/03/2011
   at 04:48 PM, CM Poncelet <ponce...@bcs.org.uk> said:

>But I do not dispute that the DCB is filled in exactly the same way
>for  output and for input (bar the flags being set for write or/and
>for read  etc.). I dispute that the program's DCB attributes for
>input prevail  over the attributes of the dataset (i.e. that they now
>temporarily  become the dataset's new attributes whether the dataset
>'likes' it or  not) in the way that its DCB attributes for output
>prevail over them  (ditto, but permanently).

The values in the DCB *are* the dataset attributes.

>It all comes down to what is meant by 'override'. To me, 'override' 
>implies 'with successful completion and CC=00':

Then by *your* definition there is an override; the OPEN completes
with RC 0.

>if the job then hits I/O errors

What if the job gets an 0C7 because of invalid decimal data? Does that
mean that there was no override?

>because the important thing to understand about 'override' is  that
>it has nothing to do with whether the job can complete afterwards,

Are you incapable of accurately citing what others have written? The
important thing to understand about override is how it works.

>How about applying this 'override' concept to JCL procedures, and 
>override say the PROC's STEPLIB with a VSAM file or DD DUMMY, then 
>submit the JCL. Does this mean the PROC's STEPLIB was successfully 
>overriden because the JCL could be submitted,

Yes. What if the user submits a STEPLIB override with a load library,
but not the correct one. Would you claim that there was no override? 

>that does not matter, because the important thing was 
>to override STEPLIB and *that* was successful?

Do you consider lying about the positions of your oponents to be a
valid debating tactic?
  
-- 
     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

Reply via email to