Re: CORRUPT PDS - I/O ERROR
In 4e40ab82.3020...@bcs.org.uk, on 08/09/2011 at 04:37 AM, CM Poncelet ponce...@bcs.org.uk said: Gimme a break. I am not mathematically 'naïve' and my proof was in fact correct. ROTF,LMAO! End of discussion. You say I go, I go, but you don't go. -- 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
Re: CORRUPT PDS - I/O ERROR
In 00fc01cc5541$5889c1c0$099d4540$@us, on 08/07/2011
at 03:34 PM, Jim Thomas j...@thethomasresidence.us said:
That said, yes, I do not remember much from my Univ. days (as I've
said before .. I don't remember what I ate for dinner last night ...
:-) ), but .. mathematically written (and since I do not know how to
write scientific terms using outlook), '0.(9)' depicts a 'real'
number, which 'is' '1'.
Indeed, Sigma n=1 to oo 9*10^{-n} is 1, but the issue is his purported
proof.
--
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
Re: CORRUPT PDS - I/O ERROR
In 4e3ee8fa.6080...@bcs.org.uk, on 08/07/2011 at 08:35 PM, CM Poncelet ponce...@bcs.org.uk said: But you seem to be saying that, unless I can cite from your book the chapter and verse that supports my argument, my argument is false. No, neither I nor the others have said that. What we said was that you were wrong, period, and that in the case of software it is the documentation that determines how things are supposed to work. The fact that you were also wrong about how it actually works was gravy. As far as credibility is concerned, do you remember saying that my proof that 0.999...recurring ad infinitum is equal to 1 was false - and that, when I pointed out that this was not my proof but that taught by my university, you said my university was wrong (or words to that effect)? No, but it's common for the mathematically naíve to make errors when attempting to construct a proof. The University of Liverpool is renowned worldwide as a leading authority in mathematics. Sturgeon's law. -- 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
Re: CORRUPT PDS - I/O ERROR
Shmuel Metz (Seymour J.) wrote: In 4e3ee8fa.6080...@bcs.org.uk, on 08/07/2011 at 08:35 PM, CM Poncelet ponce...@bcs.org.uk said: But you seem to be saying that, unless I can cite from your book the chapter and verse that supports my argument, my argument is false. No, neither I nor the others have said that. What we said was that you were wrong, period, and that in the case of software it is the documentation that determines how things are supposed to work. The fact that you were also wrong about how it actually works was gravy. As far as credibility is concerned, do you remember saying that my proof that 0.999...recurring ad infinitum is equal to 1 was false - and that, when I pointed out that this was not my proof but that taught by my university, you said my university was wrong (or words to that effect)? No, but it's common for the mathematically naíve to make errors when attempting to construct a proof. Gimme a break. I am not mathematically 'naïve' and my proof was in fact correct. End of discussion. The University of Liverpool is renowned worldwide as a leading authority in mathematics. Sturgeon's law. -- 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
Re: CORRUPT PDS - I/O ERROR
In 4e3ca3f5.1060...@bcs.org.uk, on 08/06/2011 at 03:16 AM, CM Poncelet ponce...@bcs.org.uk said: Is it perhaps because you forget that Fortran I was around in 1955 and the Lyons Electronic Office (LEO) was around in 1952? No, it's because you've made enough erroneous statements that you have no credibility. -- 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
Re: CORRUPT PDS - I/O ERROR
Shmuel Metz (Seymour J.) wrote: In 4e3ca3f5.1060...@bcs.org.uk, on 08/06/2011 at 03:16 AM, CM Poncelet ponce...@bcs.org.uk said: Is it perhaps because you forget that Fortran I was around in 1955 and the Lyons Electronic Office (LEO) was around in 1952? No, it's because you've made enough erroneous statements that you have no credibility. But you seem to be saying that, unless I can cite from your book the chapter and verse that supports my argument, my argument is false. Was that not also pope Urban's (and his cardinals' and bishops') argument for rejecting Galileo Galilei's assertion that the earth was *not* at the centre of the universe, because Galileo could quote no passage in the pontiff's book which supported his assertion? And did the earth's being at the centre of the universe being 'useful' really matter in determining whether Galileo was right or wrong? To paraphrase it, saying John and Jeremy instead of Jonah and Jeremiah does not constitute 'erroneous statements' if Jonah and Jeremiah are irrelevant to the argument. As far as credibility is concerned, do you remember saying that my proof that 0.999...recurring ad infinitum is equal to 1 was false - and that, when I pointed out that this was not my proof but that taught by my university, you said my university was wrong (or words to that effect)? Would you like me to find your email in which you said that? The University of Liverpool is renowned worldwide as a leading authority in mathematics. So perhaps it is your credibility about my proofs being wrong/false etc. (or words to that effect) that should be brought into question. -- 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
Re: CORRUPT PDS - I/O ERROR
Sir/s, Forgive me for intruding .. The University of Liverpool is good ... I went to the engineering and science affiliates at the University of London. That said, yes, I do not remember much from my Univ. days (as I've said before .. I don't remember what I ate for dinner last night ... :-) ), but .. mathematically written (and since I do not know how to write scientific terms using outlook), '0.(9)' depicts a 'real' number, which 'is' '1'. IIRC, this has to do with integer vs. non-integer, equalities and infinities .. but I forget the terms that were taught. I too didn't quite agree and it took me a bit to grasp what was being presented. Consider, what is '1' divided by '1' .. how about '1' divided by '0', how about '1' divided by .5 or .1 or .01 or .001 or or or or. Again, my apologies for intruding ... just my '.2.(0)' cents .. Kind Regards Jim Thomas 617-233-4130 (mobile) 636-294-1014(res) j...@thethomasresidence.us (Email) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of CM Poncelet Sent: Sunday, August 07, 2011 2:35 PM To: IBM-MAIN@bama.ua.edu Subject: Re: CORRUPT PDS - I/O ERROR Shmuel Metz (Seymour J.) wrote: In 4e3ca3f5.1060...@bcs.org.uk, on 08/06/2011 at 03:16 AM, CM Poncelet ponce...@bcs.org.uk said: Is it perhaps because you forget that Fortran I was around in 1955 and the Lyons Electronic Office (LEO) was around in 1952? No, it's because you've made enough erroneous statements that you have no credibility. But you seem to be saying that, unless I can cite from your book the chapter and verse that supports my argument, my argument is false. Was that not also pope Urban's (and his cardinals' and bishops') argument for rejecting Galileo Galilei's assertion that the earth was *not* at the centre of the universe, because Galileo could quote no passage in the pontiff's book which supported his assertion? And did the earth's being at the centre of the universe being 'useful' really matter in determining whether Galileo was right or wrong? To paraphrase it, saying John and Jeremy instead of Jonah and Jeremiah does not constitute 'erroneous statements' if Jonah and Jeremiah are irrelevant to the argument. As far as credibility is concerned, do you remember saying that my proof that 0.999...recurring ad infinitum is equal to 1 was false - and that, when I pointed out that this was not my proof but that taught by my university, you said my university was wrong (or words to that effect)? Would you like me to find your email in which you said that? The University of Liverpool is renowned worldwide as a leading authority in mathematics. So perhaps it is your credibility about my proofs being wrong/false etc. (or words to that effect) that should be brought into question. -- 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1391 / Virus Database: 1520/3819 - Release Date: 08/07/11 -- 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
Re: CORRUPT PDS - I/O ERROR
Give it a rest! I'm just short of kill-filing you! You're wrong and digging a deeper hole attempting to defend the indefensible! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: CM Poncelet ponce...@bcs.org.uk Sender: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Date: Sun, 7 Aug 2011 20:35:22 To: IBM-MAIN@bama.ua.edu Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Subject: Re: CORRUPT PDS - I/O ERROR Shmuel Metz (Seymour J.) wrote: In 4e3ca3f5.1060...@bcs.org.uk, on 08/06/2011 at 03:16 AM, CM Poncelet ponce...@bcs.org.uk said: Is it perhaps because you forget that Fortran I was around in 1955 and the Lyons Electronic Office (LEO) was around in 1952? No, it's because you've made enough erroneous statements that you have no credibility. But you seem to be saying that, unless I can cite from your book the chapter and verse that supports my argument, my argument is false. Was that not also pope Urban's (and his cardinals' and bishops') argument for rejecting Galileo Galilei's assertion that the earth was *not* at the centre of the universe, because Galileo could quote no passage in the pontiff's book which supported his assertion? And did the earth's being at the centre of the universe being 'useful' really matter in determining whether Galileo was right or wrong? To paraphrase it, saying John and Jeremy instead of Jonah and Jeremiah does not constitute 'erroneous statements' if Jonah and Jeremiah are irrelevant to the argument. As far as credibility is concerned, do you remember saying that my proof that 0.999...recurring ad infinitum is equal to 1 was false - and that, when I pointed out that this was not my proof but that taught by my university, you said my university was wrong (or words to that effect)? Would you like me to find your email in which you said that? The University of Liverpool is renowned worldwide as a leading authority in mathematics. So perhaps it is your credibility about my proofs being wrong/false etc. (or words to that effect) that should be brought into question. -- 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 -- 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
Re: CORRUPT PDS - I/O ERROR
On Thu, 4 Aug 2011 19:35:47 -0400, Shmuel Metz (Seymour J.)wrote: I believe that he wants the DWIWHMHIUWIWTA macro. Is that something like do what I would have meant had I understood what I wanted to accomplish? -- 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
Re: CORRUPT PDS - I/O ERROR
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant On Thu, 4 Aug 2011 19:35:47 -0400, Shmuel Metz (Seymour J.)wrote: I believe that he wants the DWIWHMHIUWIWTA macro. Is that something like do what I would have meant had I understood what I wanted to accomplish? Precisely. :-) -jc- -- 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
Re: CORRUPT PDS - I/O ERROR
In 2058724295111982.wa.m42tomibmmainyahoo@bama.ua.edu, on 08/05/2011 at 09:07 AM, Tom Marchant m42tom-ibmm...@yahoo.com said: Is that something like do what I would have meant had I understood what I wanted to accomplish? Exactly. -- 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
Re: CORRUPT PDS - I/O ERROR
Shmuel Metz (Seymour J.) wrote: In 4e3a4e7e.5090...@bcs.org.uk, on 08/04/2011 at 08:47 AM, CM Poncelet ponce...@bcs.org.uk said: I proved that, if On input, the order of override priority is program DCB - JCL DCB - dataset attributes, then the consequence is an I/O error Not only did you not prove that, but others gave examples of such overrides having practical value. the hypothesis that the priority order both on output and on input is the same Not an hypothesis - an observed fact. because there is no I/O error on output, False. It is not 'my' prejudice, but what one of the greatest MVS sysprogs I've ever known (he too had 30+ years experience, then) taught me when I started as a sysprog on IBM mainframes in '85 I wonder why I don't believe you? Is it perhaps because you forget that Fortran I was around in 1955 and the Lyons Electronic Office (LEO) was around in 1952? In fact, I still have the green plastic covers (with gold labelling) from the original LEO manuals: I wonder why? The documentation does not necessarily match the facts The code does. and the I/O error is a fact.. An irrelevant fact, and not what you seem to believe at that. An inappropriate override can cause an I/O error for *both* input and output, and an appropriate override will not cause an I/O error for either. -- 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
Re: CORRUPT PDS - I/O ERROR
Shmuel Metz (Seymour J.) wrote: In 4e392bb7.7080...@bcs.org.uk, on 08/03/2011 at 12:06 PM, CM Poncelet ponce...@bcs.org.uk said: NO NO NO again. What I did was prove by 'reductio ad absurdum' that if the premiss/assertion On input, the order of override priority is program DCB - JCL DCB - dataset attributes is true then its consequences are absurd: You proved no auch thing. I proved that, if On input, the order of override priority is program DCB - JCL DCB - dataset attributes, then the consequence is an I/O error - which contradicts the hypothesis that the priority order both on output and on input is the same (because there is no I/O error on output, but there is an I/O error on input - yet both should complete without I/O error if the hypothesis is true), and contradicting it completes the proof: the hypothesis is false.. To finish this off. It is *not* valid to argue that 'this' overrides 'that', if 'this' having overridden 'that' results in 'this' not working unless it happens to be equal to 'that' Nobody was arguing that. What they were arguing was that: 1. The documentation doesn't match your prejudice It is not 'my' prejudice, but what one of the greatest MVS sysprogs I've ever known (he too had 30+ years experience, then) taught me when I started as a sysprog on IBM mainframes in '85 - and I have found that which he said then to be true ever since. The documentation does not necessarily match the facts - and the I/O error is a fact.. 2. The code doesn't match your prejudice Forget 'my' prejudice. You mean the program's DCB code? I'm not disputing that. I'm rejecting the hypothesis that it overrides, in the sense of 'prevails over', the attributes of the dataset on DASD. 3. The way that overrides actually work is useful 'Useful' is subjective: what is its objective equivalent? -- 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
Re: CORRUPT PDS - I/O ERROR
Is there any chance that those of you who still have an interest in arguing this matter could take it offline and email each other directly. That way those of us who have long lost interest in this can stop being bombarded with the constant attacks you all seem to be throwing around indiscriminately. I know that I, for one, would really appreciate it. Please stop. Respectfully, Steve -- 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
Re: CORRUPT PDS - I/O ERROR
Agreed. This has devolved into a flame war. Boring and bothersome. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Steve Dover Sent: Thursday, August 04, 2011 7:21 AM To: IBM-MAIN@bama.ua.edu Subject: Re: CORRUPT PDS - I/O ERROR Is there any chance that those of you who still have an interest in arguing this matter could take it offline and email each other directly. That way those of us who have long lost interest in this can stop being bombarded with the constant attacks you all seem to be throwing around indiscriminately. I know that I, for one, would really appreciate it. Please stop. Respectfully, Steve -- 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 -- 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
Re: CORRUPT PDS - I/O ERROR
In f255efe0ecf08c4a9c1db6aff423541715f32...@ch2wpmail1.na.ds.ussco.com, on 08/03/2011 at 12:16 PM, Chase, John jch...@ussco.com said: IOW, to perfect the DWIM macro? :-) I believe that he wants the DWIWHMHIUWIWTA macro. -- 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
Re: CORRUPT PDS - I/O ERROR
In 4e394150.1070...@bcs.org.uk, on 08/03/2011 at 01:38 PM, CM Poncelet ponce...@bcs.org.uk said: Well yes, they have to be loaded into VS to be processed. In the case of block read/writes they precede the data records in the buffer. But whatever was being discussed at the time I wrote that had to do with record read/writes, in which case the BDW and RDW would not be accessible from the buffer: so perhaps I should have said 'not accessible' instead of 'not loaded'. You would still have been wrong. If I dealt only with MVS, I would have the time to refresh my memory: but I don't; I work with subsystems. Would you mind identifying your employer? the fact that the channel programs (CPs) are issuing CCWs It's not a fact. True. I translate my thoughts into words and for this I use whatever suitable word Or, as in this case, unsuitable word. In 4e395926.7040...@bcs.org.uk, on 08/03/2011 at 03:20 PM, CM Poncelet ponce...@bcs.org.uk said: I am proving by 'reductio ad absurdum' that if the assertion is true, then its consequences are absurd: No; you are confusing an assertion with a proof. In 4e395cad.9020...@bcs.org.uk, on 08/03/2011 at 03:35 PM, CM Poncelet ponce...@bcs.org.uk said: I have read the manuals and I reference them when *necessary*, FSVO necessary. and I am 'adamant' that I am right in pointing out that an assertion made by others is logically absurd when it is logically absurd. You are also adamant that you are right in claiming as logically absurd things that are not logically absurd and in rebutting claims that nobody made. -- 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
Re: CORRUPT PDS - I/O ERROR
In 4e3a4e7e.5090...@bcs.org.uk, on 08/04/2011 at 08:47 AM, CM Poncelet ponce...@bcs.org.uk said: I proved that, if On input, the order of override priority is program DCB - JCL DCB - dataset attributes, then the consequence is an I/O error Not only did you not prove that, but others gave examples of such overrides having practical value. the hypothesis that the priority order both on output and on input is the same Not an hypothesis - an observed fact. because there is no I/O error on output, False. It is not 'my' prejudice, but what one of the greatest MVS sysprogs I've ever known (he too had 30+ years experience, then) taught me when I started as a sysprog on IBM mainframes in '85 I wonder why I don't believe you? The documentation does not necessarily match the facts The code does. and the I/O error is a fact.. An irrelevant fact, and not what you seem to believe at that. An inappropriate override can cause an I/O error for *both* input and output, and an appropriate override will not cause an I/O error for either. -- 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
Re: CORRUPT PDS - I/O ERROR
In 4e397247.7070...@bcs.org.uk, on 08/03/2011 at 05:07 PM, CM Poncelet ponce...@bcs.org.uk said: The absurd consequences are that 'FB,90' records would have to be read as 'FB,80' records and the last record in the block padded with X'00's That is not a consequence, absurd or otherwise. In 4e3975b7.4030...@bcs.org.uk, on 08/03/2011 at 05:22 PM, CM Poncelet ponce...@bcs.org.uk said: You cannot have two 'logic sets' - one for output and another for input. WTF is a logic set? If output hits no I/O error then input hits no I/O error. Non sequitor. Otherwise your single assertion, applicable both to output and input, is flawed - because it has two possible outcomes. It is 'along the lines of' asserting that: if apples then 2 + 2 = 4, if oranges then 2 + 2 = 6. Only in your imagination. In 4e3a19f7.8070...@bcs.org.uk, on 08/04/2011 at 05:03 AM, CM Poncelet ponce...@bcs.org.uk said: My Collins English dictionary Has generic definitions, not terms of art. (2) to supersede or annul; Which is exactly what the override (forward merge) in OPEN does. As your interpretation seems to be the only one that matters Liar. But I maintain that my assertion is correct within the context of my interpretation of the word override. Perhaps in your world dogs have 5 legs. The difficulty in arguing a point here is that the English language is itself ambiguous and imprecise, No, the difficulty is that although IBM has provided precise definitions for various terms of art in its software, you insist on inventing your own. I 'misunderstood' only that assembling etc. a DCB, or substituting one JCL parm for another, are examples of the correct meaning of override: ROTF,LMAO! You misujderstood a lot more. -- 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
Re: CORRUPT PDS - I/O ERROR
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
Re: CORRUPT PDS - I/O ERROR
NO NO NO again. What I did was prove by 'reductio ad absurdum' that if the premiss/assertion On input, the order of override priority is program DCB - JCL DCB - dataset attributes is true then its consequences are absurd: therefore the premiss/assertion is false. Please note that, at the beginning, I did say What I *would* expect ... and not What I expect ... To finish this off. It is *not* valid to argue that 'this' overrides 'that', if 'this' having overridden 'that' results in 'this' not working unless it happens to be equal to 'that' - where 'this' and 'that' can be any permissible values, with no imposed conditions or constraints. Thanks, Chris Poncelet Rick Fochtman wrote: -snip-- 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). -unsnip-- The Incorrect Length error is usually generated by a CCW that specifies a length smaller than the actual length of the block on the DASD device. The CCW length, in turn, is set by the BLKSIZE value supplied that is ultimately applied to the dataset, whether the value comes from a program-coded value, a JCL value or the value specified in the FORMAT-1 DSCB of the dataset. How the LRECL is used depends on the RECFM value and the access method in use. For example, BSAM does NO deblocking or blocking, expecting the program to take care of these types of details. On the other hand, QSAM does all the blocking and deblocking under the covers, returning a logical record instead of a complete block. snip-- 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. unsnip--- NO NO NO. The attributes in the FORMAT-1 DSCB can be over-ridden by JCL OR DCB attributes in the program. They can also be altered to invalid values by injudicious use of DCB attributes in a program or JCL when adding/replacing a PDS member. Would you define a card reader with a logical record length of 50 bytes, expecting that the next logical record would be the last 30 bytes of the current image and 20 bytes of the next image? On a card reader, the blksize is 80 bytes and record format is either F or FB. Period. On DASD, the blocksize is that which is written in the count field of the actual block, as written on the disk. As far as the channel program is concerned, the only significant length field is the one written in the block's count field. Padding records with x'00' values when a block is short, can lead to all kinds of errors. Which values are valid for the program and which ones are trash and should be ignored? We won't even get into keyed records, which are still prominent in DASD data management. When half a dozen people, all with 30+ years of detailed experience, tell you you're wrong, I strongly suggest you start cracking open some manuals. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
Re: CORRUPT PDS - I/O ERROR
In 4e386bfb.7030...@acm.org, on 08/02/2011 at 04:28 PM, Joel C. Ewing jcew...@acm.org said: 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, Some of us[1] have read not only the manuals but also the code. [1] I'd guess half a dozen; possibly much more but definitely not much less. -- 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
Re: CORRUPT PDS - I/O ERROR
In 4e37505a.7090...@bcs.org.uk, on 08/02/2011 at 02:18 AM, CM Poncelet ponce...@bcs.org.uk said: 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 That is an unreasonable expectation. It is the responsibility of the user to determine whether an override is appropriate and to determine whether an input dataset matches the requirements of the application. If the data length on DASD exceeds the block size, why would you expect anything other than an I/O error. If your specify RECFM=FB and the data length is not a multiple of LRECL, why would you expect anything but a logical error? The 'raw' data could be retrieved from DASD via CCWs, irrespective of LRECL etc. At which point it is the programmer's responsible to figure out how to handle them. So I would expect a program's changed DCB attributes to override those on DASD in the same way, as if processing 'raw' data. It does. What it doesn't do is to magically figure out that you didn't really mean it when you provided the wrong attributes. That would be *my* interpretation of the program's DCB attributes having successfully overridden those of the dataset on DASD when opened for input. Your interpretation is irrelevant; what matters is the documentation that you refuse to consult. But as this does not happen, the program's DCB attributes 'overriding' those on DASD is at best theoretical/academic. No, just unrelated to anything that IBM claims to do. Again, you are confusing the dataset with the DSCB1 describing the dataset. In 4e3758a4.8070...@bcs.org.uk, on 08/02/2011 at 02:53 AM, CM Poncelet ponce...@bcs.org.uk said: Quite possibly; but it's a contrived case The fact that you don't understand it doesn't make it contrived. The fact is that what Binyamin describes is relatively common among those that understand the software, and quite useful. -- 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
Re: CORRUPT PDS - I/O ERROR
In 4e38932c.2030...@bcs.org.uk, on 08/03/2011 at 01:15 AM, CM Poncelet ponce...@bcs.org.uk said: ... but open for output, followed by write, works - whereas open for input, followed by read, doesn't (it fails with an I/O ERR): that is a fact, not an opinion. No, it is not a fact. It is a fact that you can cause an I/O error with an incorrect BLKSIZE. It is false that you always get an I/O error when you override dataset attributes on input. So unless the I/O ERR is actually the desired outcome, it is an error. A user error. If the dataset is thought to be in error, raise a PMR with IBM. Don't create a PMR for a user error. Otherwise it is the program's merged DCB that is in error - which is what I am saying. That isn't what you have been saying. You have been confusing open with read and confusing the DSCB1 with the dataset itself. -- 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
Re: CORRUPT PDS - I/O ERROR
Gerhard Postpischil wrote: On 8/2/2011 3:11 PM, CM Poncelet wrote: this. But in any case the BDW and RDW would not be loaded into the buffer. The BDW and RDW are always included in the buffer. They may not be seen at the application level (e.g., on a ForTran read or write, or in CoBOL). Well yes, they have to be loaded into VS to be processed. In the case of block read/writes they precede the data records in the buffer. But whatever was being discussed at the time I wrote that had to do with record read/writes, in which case the BDW and RDW would not be accessible from the buffer: so perhaps I should have said 'not accessible' instead of 'not loaded'. 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? But as is obvious from this thread, you are making assertions based on (mis)information where you should have refreshed your memory. I still don't know what you meant by CCW EXCPs, for example. If I dealt only with MVS, I would have the time to refresh my memory: but I don't; I work with subsystems. By CCW EXCPs I am simply emphasising the fact that the channel programs (CPs) are issuing CCWs (which have direct access to DASD devices). 'DCB' is shorter than the 'RECFM=,LRECL=,BLKSIZE=' I am actually referring to when I say 'DCB'; so I say 'DCB' for short. 'Data format' is also shorter than those, and a lot less ambiguous. True. I translate my thoughts into words and for this I use whatever suitable word - not necessarily the most appropriate one - first comes to mind. Gerhard Postpischil Bradford, VT -- 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 -- 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
Re: CORRUPT PDS - I/O ERROR
On Wed, 3 Aug 2011 13:38:40 +0100, CM Poncelet wrote: Gerhard Postpischil wrote: The BDW and RDW are always included in the buffer. They may not be seen at the application level (e.g., on a ForTran read or write, or in CoBOL). Well yes, they have to be loaded into VS to be processed. In the case of block read/writes they precede the data records in the buffer. But whatever was being discussed at the time I wrote that had to do with record read/writes, in which case the BDW and RDW would not be accessible from the buffer: so perhaps I should have said 'not accessible' instead of 'not loaded'. And you would again be wrong. I suggest you RTFM and stop relying on your faulty memory and/or flawed understanding. 'Data format' is also shorter than those, and a lot less ambiguous. True. I translate my thoughts into words and for this I use whatever suitable word - not necessarily the most appropriate one - first comes to mind. And in doing so, you fail to communicate effectively because you do not use words as they are generally understood. -- 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
Re: CORRUPT PDS - I/O ERROR
On Wed, 3 Aug 2011 12:06:31 +0100, CM Poncelet wrote: NO NO NO again. What I did was prove by 'reductio ad absurdum' that if the premiss/assertion On input, the order of override priority is program DCB - JCL DCB - dataset attributes is true then its consequences are absurd: therefore the premiss/assertion is false. Please note that, at the beginning, I did say What I *would* expect ... and not What I expect ... To finish this off. It is *not* valid to argue that 'this' overrides 'that', if 'this' having overridden 'that' results in 'this' not working unless it happens to be equal to 'that' - where 'this' and 'that' can be any permissible values, with no imposed conditions or constraints. If I understand what you are trying to say, consider this. Suppose you have some JCL like this: //TESTPROC PROC UNIT=SYSDA //SETP1 EXEC PGM=IEFBR14 //DD1 DD DISP=(NEW,DELETE),UNIT=UNIT,SPACE=(TRK,1) // PEND By your logic, if you code //EXEC PROC=TESTPROC,UNIT=BANANA BANANA does not override SYSDA for the unit because it causes a JCL error. -- 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
Re: CORRUPT PDS - I/O ERROR
I am proving by 'reductio ad absurdum' that if the assertion is true, then its consequences are absurd: and hence that the assertion is false. You are discussing the absurd consequences which would follow from the assertion being true. The point I am illustrating is that you cannot impose a common rule both for output and input, yet have one 'logic set' of consequences for output and a different one for input. Shmuel Metz (Seymour J.) wrote: In 4e37505a.7090...@bcs.org.uk, on 08/02/2011 at 02:18 AM, CM Poncelet ponce...@bcs.org.uk said: 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 That is an unreasonable expectation. It is the responsibility of the user to determine whether an override is appropriate and to determine whether an input dataset matches the requirements of the application. If the data length on DASD exceeds the block size, why would you expect anything other than an I/O error. If your specify RECFM=FB and the data length is not a multiple of LRECL, why would you expect anything but a logical error? The 'raw' data could be retrieved from DASD via CCWs, irrespective of LRECL etc. At which point it is the programmer's responsible to figure out how to handle them. So I would expect a program's changed DCB attributes to override those on DASD in the same way, as if processing 'raw' data. It does. What it doesn't do is to magically figure out that you didn't really mean it when you provided the wrong attributes. That would be *my* interpretation of the program's DCB attributes having successfully overridden those of the dataset on DASD when opened for input. Your interpretation is irrelevant; what matters is the documentation that you refuse to consult. But as this does not happen, the program's DCB attributes 'overriding' those on DASD is at best theoretical/academic. No, just unrelated to anything that IBM claims to do. Again, you are confusing the dataset with the DSCB1 describing the dataset. In 4e3758a4.8070...@bcs.org.uk, on 08/02/2011 at 02:53 AM, CM Poncelet ponce...@bcs.org.uk said: Quite possibly; but it's a contrived case The fact that you don't understand it doesn't make it contrived. The fact is that what Binyamin describes is relatively common among those that understand the software, and quite useful. -- 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
Re: CORRUPT PDS - I/O ERROR
I have read the manuals and I reference them when *necessary*, I have also read *some* of the code (howbeit by disassembling it), I do not 'take pride' in not having the time etc. (because I actually do *not* have the time to consult references which have no relevancy to the work I am currently dealing with), and I am 'adamant' that I am right in pointing out that an assertion made by others is logically absurd when it is logically absurd. Shmuel Metz (Seymour J.) wrote: In 4e386bfb.7030...@acm.org, on 08/02/2011 at 04:28 PM, Joel C. Ewing jcew...@acm.org said: 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, Some of us[1] have read not only the manuals but also the code. [1] I'd guess half a dozen; possibly much more but definitely not much less. -- 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
Re: CORRUPT PDS - I/O ERROR
Shmuel Metz (Seymour J.) wrote: In 4e38932c.2030...@bcs.org.uk, on 08/03/2011 at 01:15 AM, CM Poncelet ponce...@bcs.org.uk said: ... but open for output, followed by write, works - whereas open for input, followed by read, doesn't (it fails with an I/O ERR): that is a fact, not an opinion. No, it is not a fact. It is a fact that you can cause an I/O error with an incorrect BLKSIZE. It is false that you always get an I/O error when you override dataset attributes on input. But I should get *no* I/O error at all on read if the DCB precedence rules for output apply also to input, as is asserted (... not by me). So unless the I/O ERR is actually the desired outcome, it is an error. A user error. If the dataset is thought to be in error, raise a PMR with IBM. Don't create a PMR for a user error. Otherwise it is the program's merged DCB that is in error - which is what I am saying. That isn't what you have been saying. You have been confusing open with read and confusing the DSCB1 with the dataset itself. -- 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
Re: CORRUPT PDS - I/O ERROR
On Wed, 3 Aug 2011 15:20:22 +0100, CM Poncelet wrote: I am proving by 'reductio ad absurdum' that if the assertion is true, then its consequences are absurd: and hence that the assertion is false. What consequences? In what way are they absurd? Hint: To show that something is absurd, it is not sufficient to explain why you don't like it or how you think that it should work. In logic, absurd has a specific meaning. An example of an absurd statement is 0 = 1. -- 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
Re: CORRUPT PDS - I/O ERROR
On Wed, 3 Aug 2011 15:41:56 +0100, CM Poncelet wrote: But I should get *no* I/O error at all on read if the DCB precedence rules for output apply also to input, as is asserted (... not by me). Of course you should get an I/O error on read if you specify a blocksize that is inconsistent with the data on DASD. The same as you would get if it was inconsistent with the data on tape or any other medium. I notice that you totally ignored my question about what happens if the blocksize in the DCB is incompatible with the data on an unlabeled tape. Here is another one. What if your program wants to read 70 byte blocks from a card reader by specifying BLKSIZE=70 in the DCB in the program? You would get an I/O error. Do you assert that the blocksize on the card reader overrides the blocksize in your DCB? -- 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
Re: CORRUPT PDS - I/O ERROR
Years ago a man named Mark Thomen (I miss him and his wisdom) probably would have Relson-ed this thread days ago. all snipped -- 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 -- 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
Re: CORRUPT PDS - I/O ERROR
CM, Wrong again (but should we be surprised)! The RDW is indeed part of the logical record and is returned by the access method as part of the logical record on input and expected as part of the record on output. Some higher level languages (for example,COBOL) hide this from the programmer because the high-level language semantics require it; but if you had any experience with VB I/O on the assembler level this would be obvious, or if you had ever used SORT on a VB file you would know the field offsets must include the RDW bytes as they are part of the logical record. Once again you are the blind man, trying to understand the concept of an elephant by feeling one part of its body rather than listening to those with sight. CM, Why do you insist on continuing to embarrass yourself by pretending to speak with authority on things you obviously do not or no longer understand and are unwilling to take the time to learn or re-learn? If you now spend too little of your time with MVS to remember correctly how things work, you should just recognize that and cease pretending to be an authority and showing your ignorance. Your supposed 'reductio ad absurdum' argument is itself absurd because it is totally dependent on your redefining override to mean override with valid results, or on mis-applying the word to the physical dataset blocks or the dataset VTOC entry rather than the in-memory program DCB fields to which it clearly is intended to apply. Override simply does not have any implied secondary meaning of validity or success in the English language, and no one but yourself has chosen to make that invalid assumption. Your arguments also make no sense when you fail to properly distinguish between physical dataset content, fields in the DSCB VTOC entry, parameters in the DD, and fields in the program DCB, as the whole argument in this thread centers around understanding how all these separate and distinct pieces all interact -- and they interact only in the ways they are documented to interact, not the ways you think might be nice for them to interact. I get the feeling you are very fuzzy about the physical representation of datasets on DASD or you wouldn't even make some of the assertions you make. King George and a majority of Parliament overrode the advice of wiser men and lost the American Revolution. You have attempted to override the meaning of override, and have totally lost the argument. Seymour, good comments in your 8/2 0750 post. I guess the logical corollary of CM expecting it to be reasonable to raise an IBM PMR to eliminate errors caused by user misuse of JCL DD or program DCB parameters would be to expect IBM to also fix all compilers to take any program that was sytactically correct but semantically inappropriate for the incoming data fields, to magically determine what the programmer really intended, and change the program to modify the incoming data so the program would run without errors. To use your tools in this business you have to understand them well enough to know what they are designed to do, what they are not capable of doing, and that to keep implementation practical, the effect of some usage errors are just deliberately left undefined or unpredictable. CM just doesn't seem to get it. Maybe he's really an undercover MS agent and is just trying to distract the group from moving workloads to the z platform. Joel C. Ewing On 08/03/2011 07:38 AM, CM Poncelet wrote: Gerhard Postpischil wrote: On 8/2/2011 3:11 PM, CM Poncelet wrote: this. But in any case the BDW and RDW would not be loaded into the buffer. The BDW and RDW are always included in the buffer. They may not be seen at the application level (e.g., on a ForTran read or write, or in CoBOL). Well yes, they have to be loaded into VS to be processed. In the case of block read/writes they precede the data records in the buffer. But whatever was being discussed at the time I wrote that had to do with record read/writes, in which case the BDW and RDW would not be accessible from the buffer: so perhaps I should have said 'not accessible' instead of 'not loaded'. 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? But as is obvious from this thread, you are making assertions based on (mis)information where you should have refreshed your memory. I still don't know what you meant by CCW EXCPs, for example. If I dealt only with MVS, I would have the time to refresh my memory: but I don't; I work with subsystems. By CCW EXCPs I am simply emphasising the fact that the channel programs (CPs) are issuing CCWs (which have direct access to DASD devices). 'DCB' is shorter than the 'RECFM=,LRECL=,BLKSIZE=' I am actually referring to when I say 'DCB'; so I say 'DCB' for short. 'Data
Re: CORRUPT PDS - I/O ERROR
Tom Marchant wrote: On Tue, 2 Aug 2011 20:11:27 +0100, CM Poncelet ponce...@bcs.org.uk wrote: Gerhard Postpischil wrote: 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, Obviously, and your memory is in error. It would help if you would check a reference manual rather than continuing to post incorrect information, even after having been corrected multiple times. But in any case the BDW and RDW would not be loaded into the buffer. Wrong again. The BDW and RDW of a variable length data set are part of the data in the buffer. 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. Then why do you have time to post so much incorrect information? If something is true it can remember itself; Oh, really? Do you expect me to *remember* system control blocks? Actually, no, I don't. But I do expect you to check what you post. We all occasionally post incorrectly from memory, some of us more often than others. Most of us will at least look it up after someone points out that what we posted was wrong. You, on the other hand, repeatedly post the same erroneous information and steadfastly refuse to look it up. Because of that, I don't expect you to *know* what you are talking about. I have been reading system dumps for more than 25 years Well, good for you. I've been doing it for 40. I think Gerhard has been doing it for considerably longer and I know that Shmuel has. This topic is about the order of priority of DCB attributes when opening a dataset for input v. output, And your insistence that there is a difference in the priority of filling in the DCB between input and output is demonstrably wrong. There is no difference. The DCB is filled in exactly the same way. If you don't believe me, take dump after opening a data set for input and see what the values are. Let me guess. you don't have time for that either. 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). It all comes down to what is meant by 'override'. To me, 'override' implies 'with successful completion and CC=00': otherwise an 'override' was attempted but it failed. To others, it seems that 'override' means nothing more than that the DCB was successfully assembled/link-edited and opened at run time, and if the job then hits I/O errors well ... who cares, because the important thing to understand about 'override' is that it has nothing to do with whether the job can complete afterwards, but has only to do with whether the DCB can be assembled cleanly etc. and then opened. Is that some kind of joke? 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, and if the job then abended well ... that does not matter, because the important thing was to override STEPLIB and *that* was successful? That would open up an interesting new perspective on software engineering ... -- 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
Re: CORRUPT PDS - I/O ERROR
If expressed that way, I have no choice but to accept that BANANA overrides SYSDA - although that is not the interpretation of 'override' I am referring to. If expressed as BANANA prevails over SYSDA, then I disagree - because BANANA would fail with a JCL error and would therefore not prevail. Tom Marchant wrote: On Wed, 3 Aug 2011 12:06:31 +0100, CM Poncelet wrote: NO NO NO again. What I did was prove by 'reductio ad absurdum' that if the premiss/assertion On input, the order of override priority is program DCB - JCL DCB - dataset attributes is true then its consequences are absurd: therefore the premiss/assertion is false. Please note that, at the beginning, I did say What I *would* expect ... and not What I expect ... To finish this off. It is *not* valid to argue that 'this' overrides 'that', if 'this' having overridden 'that' results in 'this' not working unless it happens to be equal to 'that' - where 'this' and 'that' can be any permissible values, with no imposed conditions or constraints. If I understand what you are trying to say, consider this. Suppose you have some JCL like this: //TESTPROC PROC UNIT=SYSDA //SETP1 EXEC PGM=IEFBR14 //DD1 DD DISP=(NEW,DELETE),UNIT=UNIT,SPACE=(TRK,1) // PEND By your logic, if you code //EXEC PROC=TESTPROC,UNIT=BANANA BANANA does not override SYSDA for the unit because it causes a JCL error. -- 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
Re: CORRUPT PDS - I/O ERROR
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of CM Poncelet Sent: Wednesday, August 03, 2011 7:39 AM To: IBM-MAIN@bama.ua.edu Subject: Re: CORRUPT PDS - I/O ERROR ... I translate my thoughts into words and for this I use whatever suitable word - not necessarily the most appropriate one - first comes to mind. Is this how glossolalia begins? Sometimes, when giving a public technical presentation, I have found myself stumped for the most precise word. Rather than utter whatever comes to mind, I stop speaking, think for several seconds while saying nothing into the microphone (such as you know, uh, like), and then speak the appropriate word. It is also permissible to write in this same fashion. IBM-MAIN is, and my technical audiences have been, populated with many perfectionists with a half century of experience in the behavior of z/OS software and its predecessor operating systems. As I have found out from some of my earliest posts on this list server, I am best served by taking extra time to compose my thoughts and choose my words carefully. Bill Fairchild -- 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
Re: CORRUPT PDS - I/O ERROR
Tom Marchant wrote: On Wed, 3 Aug 2011 15:20:22 +0100, CM Poncelet wrote: I am proving by 'reductio ad absurdum' that if the assertion is true, then its consequences are absurd: and hence that the assertion is false. What consequences? In what way are they absurd? The absurd consequences are that 'FB,90' records would have to be read as 'FB,80' records and the last record in the block padded with X'00's - and that is without even considering VB records. Hint: To show that something is absurd, it is not sufficient to explain why you don't like it or how you think that it should work. In logic, absurd has a specific meaning. An example of an absurd statement is 0 = 1. -- 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
Re: CORRUPT PDS - I/O ERROR
On Wed, 3 Aug 2011 17:03:21 +0100, CM Poncelet wrote: If expressed that way, I have no choice but to accept that BANANA overrides SYSDA - although that is not the interpretation of 'override' I am referring to. Feeding this troll is a waste of time. He insists upon providing his own meanings to words, so rational communication is impossible. It is pointless to argue with someone who suspends reason. -- 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
Re: CORRUPT PDS - I/O ERROR
You cannot have two 'logic sets' - one for output and another for input. If output hits no I/O error then input hits no I/O error. Otherwise your single assertion, applicable both to output and input, is flawed - because it has two possible outcomes. It is 'along the lines of' asserting that: if apples then 2 + 2 = 4, if oranges then 2 + 2 = 6. Tom Marchant wrote: On Wed, 3 Aug 2011 15:41:56 +0100, CM Poncelet wrote: But I should get *no* I/O error at all on read if the DCB precedence rules for output apply also to input, as is asserted (... not by me). Of course you should get an I/O error on read if you specify a blocksize that is inconsistent with the data on DASD. The same as you would get if it was inconsistent with the data on tape or any other medium. I notice that you totally ignored my question about what happens if the blocksize in the DCB is incompatible with the data on an unlabeled tape. Here is another one. What if your program wants to read 70 byte blocks from a card reader by specifying BLKSIZE=70 in the DCB in the program? You would get an I/O error. Do you assert that the blocksize on the card reader overrides the blocksize in your DCB? -- 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
Re: CORRUPT PDS - I/O ERROR
'override' includes 'over' and 'ride' - and 'ride' is ambiguous. Tom Marchant wrote: On Wed, 3 Aug 2011 17:03:21 +0100, CM Poncelet wrote: If expressed that way, I have no choice but to accept that BANANA overrides SYSDA - although that is not the interpretation of 'override' I am referring to. Feeding this troll is a waste of time. He insists upon providing his own meanings to words, so rational communication is impossible. It is pointless to argue with someone who suspends reason. -- 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
Re: CORRUPT PDS - I/O ERROR
Google me this. While processing a job step that has duplicate DDNAMES coded and at least one of the DDNAMES points to a JES data set (SYSIN, SYSOUT, etc.) an extend failure can occur. This error occurs when the non-JES data set is attempting to extend to a second volume and this candidate volume was not resolved to a specific volser prior to the step beginning. The error recieved is: IEC032I E37-08,IFG0554P Dataset will not extend On 11-08-03 12:12 PM, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Wed, 3 Aug 2011 17:03:21 +0100, CM Poncelet wrote: If expressed that way, I have no choice but to accept that BANANA overrides SYSDA - although that is not the interpretation of 'override' I am referring to. Feeding this troll is a waste of time. He insists upon providing his own meanings to words, so rational communication is impossible. It is pointless to argue with someone who suspends reason. -- 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 -- 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
Re: CORRUPT PDS - I/O ERROR
On 8/3/2011 8:38 AM, CM Poncelet wrote: Well yes, they have to be loaded into VS to be processed. In the case of block read/writes they precede the data records in the buffer. But whatever was being discussed at the time I wrote that had to do with record read/writes, in which case the BDW and RDW would not be accessible from the buffer: so perhaps I should have said 'not accessible' instead of 'not loaded'. And you keep digging a bigger hole. While I have written production programs in many languages, most of my career was spent on assembler, on multiple platforms. If you had bothered to look at BSAM and QSAM, you would not be making these absurd statements. While QSAM has a DATA mode, normal use of variable format always includes the RDWs. In the original context, other than references to IEBGENER, there was no mention of the program's language, so you're on shaky ground; and IEBGENER definitely uses QSAM, or BSAM, as appropriate, with full access to the control data. If I dealt only with MVS, I would have the time to refresh my memory: but I don't; I work with subsystems. By CCW EXCPs I am simply emphasising the fact that the channel programs (CPs) are issuing CCWs (which have direct access to DASD devices). And more of the same. EXCP is a specific reference to an MVS service, and the macro used to invoke it. EXCP uses CCWs, CCWs don't use EXCP. And channel program do not issue CCWs, they are CCWs. True. I translate my thoughts into words and for this I use whatever suitable word - not necessarily the most appropriate one - first comes to mind. This group is about sharing information about mainframes, and providing help to people who are stuck. That entails effective communication, which is not achieved by using well-understood concepts in inappropriate ways, or creating your own arbitrary definitions for common words. I get the impression that you misunderstood something in the original thread, made an inappropriate post, something all of us have had happen at some stage of our careers, and rather than own up to the misapprehension, you are trying to argue your way out of it. That not only wastes everyone's time, but has already made you appear incredibly foolish. Gerhard Postpischil Bradford, VT -- 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
Re: CORRUPT PDS - I/O ERROR
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Joel C. Ewing [ snip ] I guess the logical corollary of CM expecting it to be reasonable to raise an IBM PMR to eliminate errors caused by user misuse of JCL DD or program DCB parameters would be to expect IBM to also fix all compilers to take any program that was sytactically correct but semantically inappropriate for the incoming data fields, to magically determine what the programmer really intended, and change the program to modify the incoming data so the program would run without errors. . . . IOW, to perfect the DWIM macro? :-) -jc- -- 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
Re: CORRUPT PDS - I/O ERROR
Either that or he thinks he is executing IEHPROPHET. On Wed, Aug 3, 2011 at 1:16 PM, Chase, John jch...@ussco.com wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joel C. Ewing [ snip ] I guess the logical corollary of CM expecting it to be reasonable to raise an IBM PMR to eliminate errors caused by user misuse of JCL DD or program DCB parameters would be to expect IBM to also fix all compilers to take any program that was sytactically correct but semantically inappropriate for the incoming data fields, to magically determine what the programmer really intended, and change the program to modify the incoming data so the program would run without errors. . . . IOW, to perfect the DWIM macro? :-) -jc- -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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
Re: CORRUPT PDS - I/O ERROR
... I translate my thoughts into words and for this I use whatever suitable word - not necessarily the most appropriate one - first comes to mind. Humpty Dumpty to Alice: A word means exactly what I intend it to mean! In a field that requires precision and accuracy, communication in that field does as well. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- 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
Re: CORRUPT PDS - I/O ERROR
snip- 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, Some of us[1] have read not only the manuals but also the code. [1] I'd guess half a dozen; possibly much more but definitely not much less. -unsnip- A nearly complete OS/360 source can be found on the CBTTAPE web site, The only part that I'm aware of being missing is about half of SMP, and some parts of the ALGOL compiler are garbaged up. The various access method and Open/Close/EOV routines are (mostly) unchanged, other than support for various newer devices. Help yourselves, dear listers; it's all public domain code. Rick (With a big bouquet of roses to Jim Marshall, who provided most of the material) -- 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
Re: CORRUPT PDS - I/O ERROR
In 4e392bb7.7080...@bcs.org.uk, on 08/03/2011 at 12:06 PM, CM Poncelet ponce...@bcs.org.uk said: NO NO NO again. What I did was prove by 'reductio ad absurdum' that if the premiss/assertion On input, the order of override priority is program DCB - JCL DCB - dataset attributes is true then its consequences are absurd: You proved no auch thing. To finish this off. It is *not* valid to argue that 'this' overrides 'that', if 'this' having overridden 'that' results in 'this' not working unless it happens to be equal to 'that' Nobody was arguing that. What they were arguing was that: 1. The documentation doesn't match your prejudice 2. The code doesn't match your prejudice 3. The way that overrides actually work is useful -- 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
Re: CORRUPT PDS - I/O ERROR
Thanks for your comments. It seems to me that there are two areas of dispute. (a) My recollection of MVS control blocks etc. As I have not worked as an MVS sysprog for nearly 12 years, my memory of them is somewhat fuzzy - just as my knowledge of French (my original academic language), Dutch and Italian has become over the years. (b) My interpretation of override versus yours. My Collins English dictionary gives the following definitions of override: (1) to set aside or disregard with superior authority or power; (2) to supersede or annul; (3) to dominate or vanquish by or as if by trampling down; (4) to take manual control of (a system that is usually under automatic control); (5) to extend or pass over, esp. to overlap; (6) to ride (a horse) too hard; (7) to ride over or across; (8) a device or system that can override an automatic control. In the case of (a), I cannot know which parts of my recollection of MVS ctlblks are 'blurred' and I have no time to check every one. Their details can be remembered easily when regularly used. In the case of (b), your interpretation of override seems to match most closely definition (5); my interpretation matches more closely definitions (1), (2), (3). As your interpretation seems to be the only one that matters (in previous years, it was only the Vatican's interpretation that mattered), I have dropped out of this discussion. But I maintain that my assertion is correct within the context of my interpretation of the word override. The difficulty in arguing a point here is that the English language is itself ambiguous and imprecise, and is therefore prone to misinterpretation. I 'misunderstood' only that assembling etc. a DCB, or substituting one JCL parm for another, are examples of the correct meaning of override: I thought it could have other interpretations, as I tried to explain on several occasions. Thanks again for your comments. Chris Poncelet CEng MBCS CITP Gerhard Postpischil wrote: On 8/3/2011 8:38 AM, CM Poncelet wrote: Well yes, they have to be loaded into VS to be processed. In the case of block read/writes they precede the data records in the buffer. But whatever was being discussed at the time I wrote that had to do with record read/writes, in which case the BDW and RDW would not be accessible from the buffer: so perhaps I should have said 'not accessible' instead of 'not loaded'. And you keep digging a bigger hole. While I have written production programs in many languages, most of my career was spent on assembler, on multiple platforms. If you had bothered to look at BSAM and QSAM, you would not be making these absurd statements. While QSAM has a DATA mode, normal use of variable format always includes the RDWs. In the original context, other than references to IEBGENER, there was no mention of the program's language, so you're on shaky ground; and IEBGENER definitely uses QSAM, or BSAM, as appropriate, with full access to the control data. If I dealt only with MVS, I would have the time to refresh my memory: but I don't; I work with subsystems. By CCW EXCPs I am simply emphasising the fact that the channel programs (CPs) are issuing CCWs (which have direct access to DASD devices). And more of the same. EXCP is a specific reference to an MVS service, and the macro used to invoke it. EXCP uses CCWs, CCWs don't use EXCP. And channel program do not issue CCWs, they are CCWs. True. I translate my thoughts into words and for this I use whatever suitable word - not necessarily the most appropriate one - first comes to mind. This group is about sharing information about mainframes, and providing help to people who are stuck. That entails effective communication, which is not achieved by using well-understood concepts in inappropriate ways, or creating your own arbitrary definitions for common words. I get the impression that you misunderstood something in the original thread, made an inappropriate post, something all of us have had happen at some stage of our careers, and rather than own up to the misapprehension, you are trying to argue your way out of it. That not only wastes everyone's time, but has already made you appear incredibly foolish. Gerhard Postpischil Bradford, VT -- 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 -- 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
Re: Corrupt PDS - I/O ERROR
I'll look into it when I have the time. Dale Miller wrote: Mr. Poncelet said We are arguing semantics. Yes, computer language statements have syntax requirements and properly-written statements have semantics associated with them. The language in the JCL Reference Manual specifically refers to the relative priority of information provided in the program DCB vs the DD/JFCB vs the DSCB, as is attested by the section title in the manual. The actual semantics of the OPEN statement are more complex. Mr. Poncelet argues that his meaning of override is the correct one. I would go with the meaning of override in the documentation, and as I used it. If my manager sends me an message telling me to do something, I may (with risks) override his wishes by doing something different, but that does not mean that I rewrote his message. The actual semantics of OPEN are that the DCB attributes in the DSCB are NOT rewritten on an OPEN for input. Mr. Poncelet demanded a verifiable example. I provided one. Read a member of a PDS with IDCAMS PRINT with a DD specifying RECFM=U,BLKSIZE=32760 This works, and does NOT update the DSCB. Dale Miller -- 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 -- 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
Re: CORRUPT PDS - I/O ERROR
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 -- 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 -- 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
Re: CORRUPT PDS - I/O ERROR
I really wish you folks would get your semantics clear. The original problem and solution proves the facts without need for further discussion. 1. Take a perfectly good, LRECL=80 PDS. Maybe to be really clear, find a PDS with LERECL 133. 2. trash it by pointing any SYSOUT DD to a NEW member. The original problem is now there and: 3. confirm that the DSCB in the VTOC for the PDS now claims LRECL=133 (or maybe 121). 4. Fail to browse using ISPF or read any older member using IEBGENER 5. Run IEBGENER specifying (overriding) LRECL=correctlrecl,BLKSIZE=correct(old)blksize) on the input DD and it works. 6. Run IEBGENER to a new member or even the bad member specifying (overriding) LRECL=80 (old lrecl) 7. PDS is now fixed. Dave Gibney Information Technology Services Washington State University -- 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
Re: CORRUPT PDS - I/O ERROR
On 8/2/2011 3:11 PM, CM Poncelet wrote: this. But in any case the BDW and RDW would not be loaded into the buffer. The BDW and RDW are always included in the buffer. They may not be seen at the application level (e.g., on a ForTran read or write, or in CoBOL). 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? But as is obvious from this thread, you are making assertions based on (mis)information where you should have refreshed your memory. I still don't know what you meant by CCW EXCPs, for example. 'DCB' is shorter than the 'RECFM=,LRECL=,BLKSIZE=' I am actually referring to when I say 'DCB'; so I say 'DCB' for short. 'Data format' is also shorter than those, and a lot less ambiguous. Gerhard Postpischil Bradford, VT -- 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
Re: CORRUPT PDS - I/O ERROR
-snip-- 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). -unsnip-- The Incorrect Length error is usually generated by a CCW that specifies a length smaller than the actual length of the block on the DASD device. The CCW length, in turn, is set by the BLKSIZE value supplied that is ultimately applied to the dataset, whether the value comes from a program-coded value, a JCL value or the value specified in the FORMAT-1 DSCB of the dataset. How the LRECL is used depends on the RECFM value and the access method in use. For example, BSAM does NO deblocking or blocking, expecting the program to take care of these types of details. On the other hand, QSAM does all the blocking and deblocking under the covers, returning a logical record instead of a complete block. snip-- 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. unsnip--- NO NO NO. The attributes in the FORMAT-1 DSCB can be over-ridden by JCL OR DCB attributes in the program. They can also be altered to invalid values by injudicious use of DCB attributes in a program or JCL when adding/replacing a PDS member. Would you define a card reader with a logical record length of 50 bytes, expecting that the next logical record would be the last 30 bytes of the current image and 20 bytes of the next image? On a card reader, the blksize is 80 bytes and record format is either F or FB. Period. On DASD, the blocksize is that which is written in the count field of the actual block, as written on the disk. As far as the channel program is concerned, the only significant length field is the one written in the block's count field. Padding records with x'00' values when a block is short, can lead to all kinds of errors. Which values are valid for the program and which ones are trash and should be ignored? We won't even get into keyed records, which are still prominent in DASD data management. When half a dozen people, all with 30+ years of detailed experience, tell you you're wrong, I strongly suggest you start cracking open some manuals. Rick -- 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
Re: CORRUPT PDS - I/O ERROR
snip--- 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). ---unsnip--- Wrong. There are no BDW's or RDW's in RECFM=F. Or in FB. The access method code (for QSAM) or program code (for BSAM) are responsible for breaking a block into logical records. This is why, with this format, the BLKSIZE MUST be an integral multiple of the LRECL value. Similarly, there are no BDW's or RDW's for RECFM=U and the blocks may be any random length, up to and including the BLKSIZE defined for the dataset. snip By 'general purpose' example I meant one where the LRECLs, RECFMs and BLKSIZEs in the input source dataset are different, and independently so, from those in the program's DCB - i.e. where they can be completely random and yet still work. If the DCB is opened for output, the I/O will complete successfully if the dataset and program DCB attributes are chosen completely at random, without having to be multiples or divisors of each other (excluding BLKSIZE if FB etc.); but if the DCB is opened for input this is not the case, because the program's DCB attributes must now be compatible with those of the source dataset on DASD 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. --unsnip- If you have DCB values coded in the program, they will rule and you have no right to expect them to work every time. Different formats of records have their uses, assets and drawbacks. If you code the program to accept anything, you'll have a serious amount of code dedicated to handling the different types of RECFM and you'd better NOT have any values coded in the DCB in the program. You can always interrogate those values after the dataset has been successfuly OPEN'ed. You don't have to like it; just live with it. Cuz' them's the conditions that prevail. Rick -- 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
Re: CORRUPT PDS - I/O ERROR
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
Re: CORRUPT PDS - I/O ERROR
In 4e35f6d3.9090...@bcs.org.uk, on 08/01/2011 at 01:44 AM, CM Poncelet ponce...@bcs.org.uk said: The 'acid test' is whether the same program DCB (ignoring the MACRF= and EODAD=) can be used *both* for OUTPUT and for INPUT (with a change in MACFR= and adding EODAD= when opening for INPUT), when the dataset's physical DCB attributes on DASD are *different* from those specified in the program. No. The acid test is whether the system behaves in accordance with the published documentation. It does. when the dataset's physical DCB attributes on DASD There is no such thing. If this DCB is opened for OUTPUT (MACRF=PM|L), then the program's DCB attributes override those on DASD - and the program's DCB attributes then also become those stored on DASD, all without causing I/O errors. No. An incorrect BLKSIZE on output could also cause an I/O error, back when there where DASD with tracks smaller than 32 KiB. If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=etc.), then the program's DCB attributes do *not* override those on DASD Were that true then there wouldn't be an I/O error. and, as the program's DCB attributes are inconsistent They wouldn't be inconsistent if they didn't override. more nonsense clipped high-falluting semantics Like the NCO's in Basic Training who argued high-falluting semantics for no better reason than a prejudice against our killing each other with unloaded rifles. The word semantics doesn't mean what you believe it means. In 4e35f8cb.7090...@bcs.org.uk, on 08/01/2011 at 01:52 AM, CM Poncelet ponce...@bcs.org.uk said: We are arguing semantics ... Indeed, but semantics doesn't mean what you believe. Essentially all arguments are about semantics. In 4e360d24.4010...@bcs.org.uk, on 08/01/2011 at 03:19 AM, CM Poncelet ponce...@bcs.org.uk said: No, what I am saying is correct. ROTF,LMAO! What matters is not whether a program can open a DCB for input (trivial), but whether that DCB then actually works. No, what matters is whether the results are in accordance with the published documentation or in accordance with your beliefs. argumentum ad hominem? No. Ridicule of a an inference with false premises. In 4e3618ba.8050...@bcs.org.uk, on 08/01/2011 at 04:08 AM, CM Poncelet ponce...@bcs.org.uk said: when I can think for myself. Obviously not. Otherwise you wouldn't keep insisting that you don't need to read the manuals. -- 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
Re: CORRUPT PDS - I/O ERROR
In 4e36c3fe.30...@bcs.org.uk, on 08/01/2011 at 04:19 PM, CM Poncelet ponce...@bcs.org.uk said: Probably ... because my definition Your definition is irrelevant. The documentation of how OPEN behaves uses IBM's definitions. Otherwise the 'standard' definition of DCB override is purely academic and of no practical use. The fact that you don't understand it doesn't make it useless. -- 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
Re: CORRUPT PDS - I/O ERROR
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
Re: CORRUPT PDS - I/O ERROR
... but open for output, followed by write, works - whereas open for input, followed by read, doesn't (it fails with an I/O ERR): that is a fact, not an opinion. So unless the I/O ERR is actually the desired outcome, it is an error. If it needs to be fixed, then either the program's merged DCB or the dataset on DASD is in error. If the dataset is thought to be in error, raise a PMR with IBM. Otherwise it is the program's merged DCB that is in error - which is what I am saying. As this defines the scope and boundaries of the topic - i.e. who prevails over what (which is what I mean by 'this overrides that'), during input and output - there is no need to examine all the entrails in-between. I do not disagree with the details of the points you make about RECFMs etc., but they are not relevant to the topic under discussion (i.e. that 'output' works and that 'input' doesn't, and why). Joel C. Ewing wrote: 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
Re: CORRUPT PDS - I/O ERROR
Open for output merges all the attributes and then REPLACES the DSCB values with the result of the merge. On Tue, Aug 2, 2011 at 8:15 PM, CM Poncelet ponce...@bcs.org.uk wrote: ... but open for output, followed by write, works - whereas open for input, followed by read, doesn't (it fails with an I/O ERR): that is a fact, not an opinion. So unless the I/O ERR is actually the desired outcome, it is an error. If it needs to be fixed, then either the program's merged DCB or the dataset on DASD is in error. If the dataset is thought to be in error, raise a PMR with IBM. Otherwise it is the program's merged DCB that is in error - which is what I am saying. As this defines the scope and boundaries of the topic - i.e. who prevails over what (which is what I mean by 'this overrides that'), during input and output - there is no need to examine all the entrails in-between. I do not disagree with the details of the points you make about RECFMs etc., but they are not relevant to the topic under discussion (i.e. that 'output' works and that 'input' doesn't, and why). Joel C. Ewing wrote: 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
Re: CORRUPT PDS - I/O ERROR
On Tue, 2 Aug 2011 20:11:27 +0100, CM Poncelet ponce...@bcs.org.uk wrote: Gerhard Postpischil wrote: 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, Obviously, and your memory is in error. It would help if you would check a reference manual rather than continuing to post incorrect information, even after having been corrected multiple times. But in any case the BDW and RDW would not be loaded into the buffer. Wrong again. The BDW and RDW of a variable length data set are part of the data in the buffer. 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. Then why do you have time to post so much incorrect information? If something is true it can remember itself; Oh, really? Do you expect me to *remember* system control blocks? Actually, no, I don't. But I do expect you to check what you post. We all occasionally post incorrectly from memory, some of us more often than others. Most of us will at least look it up after someone points out that what we posted was wrong. You, on the other hand, repeatedly post the same erroneous information and steadfastly refuse to look it up. Because of that, I don't expect you to *know* what you are talking about. I have been reading system dumps for more than 25 years Well, good for you. I've been doing it for 40. I think Gerhard has been doing it for considerably longer and I know that Shmuel has. This topic is about the order of priority of DCB attributes when opening a dataset for input v. output, And your insistence that there is a difference in the priority of filling in the DCB between input and output is demonstrably wrong. There is no difference. The DCB is filled in exactly the same way. If you don't believe me, take dump after opening a data set for input and see what the values are. Let me guess. you don't have time for that either. -- 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
Re: CORRUPT PDS - I/O ERROR
I must admit most of this thread has made its way into the bin without more than a perfunctory glance. Toms latest contribution does however display admirable patience in the face of intransigence. Kudos to Tom. Shane ... -- 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
Re: CORRUPT PDS - I/O ERROR
I did not look at all the other responses so please forgive me if someone already gave you the answer. Most the time I have seen this error the lrecl/blocksize was reset by creating a member with a different lrecl. All you have to do is create a member with the right lrecl/blksize and all but the bad member will be right again. -- 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
Re: CORRUPT PDS - I/O ERROR
Tom Marchant wrote: On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet wrote: If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=etc.), then the program's DCB attributes do *not* override those on DASD Right. No one said that they do. and, as the program's DCB attributes are inconsistent with those of the dataset on DASD, they cause I/O errors ... because the dataset's DCB attributes on DASD take priority over those of the program's DCB. No. Because the attributes specified in the completed DCB are inconsistent with the DATA on disk or tape. Consider an unlabeled tape. A data set that was written previously to tape is read by a program that specifies DCB attributes. If it specifies incorrect attributes, the program may get I/O errors. This is not because the DCB attributes on the tape override those coded in the DCB because there are no DCB attributes on an unlabeled tape. But if opened for INPUT, the priority order is DASD DCB - JCL DCB - program DCB. If the program's DCB attributes are then inconsistent with the ones on DASD, on INPUT, the program hits I/O errors It might very well because the DCB attributes on DASD override those hard-coded in the program on INPUT No, because the data on DASD are not consistent with the DCB parameters in the program. This would happen even of the DCB attributes in the DSCB were zapped to be the same as those in the program. If the program's DCB attributes, for INPUT, are inconsistent with those of the physical dataset stored on DASD, they do not override those stored on DASD The attributes in the DCB of an input data set are not written to the DSCB. That is correct. But for filling in the DCB, if a particular attribute is specified in the program, that attribute from the DSCB is not used. If I am wrong, please prove it by submitting verifiable 'general purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable example' is one in which all the program's DCB attributes are different from those of the dataset's physical DCB attributes on DASD - yet override the dataset's DCB attributes stored on DASD *both* when the dataset is opened and written for OUTPUT and also when it is opened and read for INPUT No one has claimed that the DCB attributes from the program are written to the DSCB when the data set is opened for input. If you cannot prove it by a 'verifiable example', then you are arguing high-falluting semantics where the interpretation of DCB override depends entirely upon what *you* mean by that, and is not subject to what DCB override is actually understood to mean in practice. I think that you are the one who is using a non-standard definition of what it means for a DCB attribute to be overridden. 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. -- 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
Re: CORRUPT PDS - I/O ERROR
On Mon, 1 Aug 2011 16:19:26 +0100 CM Poncelet ponce...@bcs.org.uk 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 bdis...@dissensoftware.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
On Mon, 1 Aug 2011 00:45:05 -0500, Tom Marchant wrote: On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet wrote: If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=etc.), then the program's DCB attributes do *not* override those on DASD Right. No one said that they do. I should have written, I think you mean by that, that the DCB attributes on DASD (in the DSCB) do not get replaced by those in the DCB. If that is what you mean, then you are correct. No one said that they do. If you mean that the DCB attributes that were specified by the program are not used when completing the DCB in preference to those in the DSCB, you are mistaken. -- 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
Re: CORRUPT PDS - I/O ERROR
On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet ponce...@bcs.org.uk wrote: If I am wrong, please prove it by submitting verifiable 'general purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable example' is one in which all the program's DCB attributes are different from those of the dataset's physical DCB attributes on DASD - yet override the dataset's DCB attributes stored on DASD *both* when the dataset is opened and written for OUTPUT and also when it is opened and read for INPUT (subject to the appropriate MACRF= etc. being specified on the DCB in each case). If you cannot prove it by a 'verifiable example', then you are arguing high-falluting semantics where the interpretation of DCB override depends entirely upon what *you* mean by that, and is not subject to what DCB override is actually understood to mean in practice. Thanks, Chris Poncelet OK, explain how this JCL works. I used JCL similar to the following for many years to copy VM/CMS files to MVS that were longer than 80 but a multiple of 80 in length. In this example, the records are 160 in length. They are split into two 80 byte records, then joined into 160 byte records by overriding the LRECL of the disk file via JCL. //COPYEXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=A //SYSINDD DUMMY //SYSUT2 DD DSN=amp;TEMP,DISP=(,PASS,DELETE), // UNIT=SYSDA,SPACE=(1600,(10,10),RLSE), // RECFM=FB,LRECL=80,BLKSIZE=1600 //SYSUT1 DD DATA,DLM='++' PART1 PART2 PART1 PART2 ++ //SORTEXEC PGM=SORT //SYSOUT DD SYSOUT=A //SORTIN DD DSN=amp;TEMP,DISP=(OLD,DELETE), // RECFM=FB,LRECL=160,BLKSIZE=1600 //SORTOUT DD DSN=MY.DATA.SET,DISP=(,CATLG,DELETE), // UNIT=SYSDA,SPACE=(1600,(10,10),RLSE), // RECFM=FB,LRECL=160,BLKSIZE=1600 //SYSINDD * SORT FIELDS=COPY END /* The key for this to work is that the BLKSIZE has to be a multiple of 80 and 160. This will work for any records that are a multiple of 80, (160, 240, etc.). I needed to put the VM/CMS file inline so it had to be a multiple of 80 bytes to work. This example clearly shows that the JCL LRECL overrides the file setting and no error occurs. -- Dale R. Smith -- 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
Re: CORRUPT PDS - I/O ERROR
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 ponce...@bcs.org.uk 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 bdis...@dissensoftware.com 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
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). By 'general purpose' example I meant one where the LRECLs, RECFMs and BLKSIZEs in the input source dataset are different, and independently so, from those in the program's DCB - i.e. where they can be completely random and yet still work. If the DCB is opened for output, the I/O will complete successfully if the dataset and program DCB attributes are chosen completely at random, without having to be multiples or divisors of each other (excluding BLKSIZE if FB etc.); but if the DCB is opened for input this is not the case, because the program's DCB attributes must now be compatible with those of the source dataset on DASD 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. Dale R. Smith wrote: On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet ponce...@bcs.org.uk wrote: If I am wrong, please prove it by submitting verifiable 'general purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable example' is one in which all the program's DCB attributes are different from those of the dataset's physical DCB attributes on DASD - yet override the dataset's DCB attributes stored on DASD *both* when the dataset is opened and written for OUTPUT and also when it is opened and read for INPUT (subject to the appropriate MACRF= etc. being specified on the DCB in each case). If you cannot prove it by a 'verifiable example', then you are arguing high-falluting semantics where the interpretation of DCB override depends entirely upon what *you* mean by that, and is not subject to what DCB override is actually understood to mean in practice. Thanks, Chris Poncelet OK, explain how this JCL works. I used JCL similar to the following for many years to copy VM/CMS files to MVS that were longer than 80 but a multiple of 80 in length. In this example, the records are 160 in length. They are split into two 80 byte records, then joined into 160 byte records by overriding the LRECL of the disk file via JCL. //COPYEXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=A //SYSINDD DUMMY //SYSUT2 DD DSN=amp;TEMP,DISP=(,PASS,DELETE), // UNIT=SYSDA,SPACE=(1600,(10,10),RLSE), // RECFM=FB,LRECL=80,BLKSIZE=1600 //SYSUT1 DD DATA,DLM='++' PART1 PART2 PART1 PART2 ++ //SORTEXEC PGM=SORT //SYSOUT DD SYSOUT=A //SORTIN DD DSN=amp;TEMP,DISP=(OLD,DELETE), // RECFM=FB,LRECL=160,BLKSIZE=1600 //SORTOUT DD DSN=MY.DATA.SET,DISP=(,CATLG,DELETE), // UNIT=SYSDA,SPACE=(1600,(10,10),RLSE), // RECFM=FB,LRECL=160,BLKSIZE=1600 //SYSINDD * SORT FIELDS=COPY END /* The key for this to work is that the BLKSIZE has to be a multiple of 80 and 160. This will work for any records that are a multiple of 80, (160, 240, etc.). I needed to put the VM/CMS file inline so it had to be a multiple of 80 bytes to work. This example clearly shows that the JCL LRECL overrides the file setting and no error occurs. -- 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
Re: CORRUPT PDS - I/O ERROR
On 8/1/2011 9:18 PM, CM Poncelet wrote: 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). Your expectation runs afoul of reality. If the block is not a multiple of 80 (as well as 90), then the I/O fails (incorrect length), and your program would get a system 001 abend. Your scenario can be produced using EXCP (or EXCPVR or STARTIO) or BSAM, provided the CCWs had the SLI bit on, and you had code to zero the buffer prior to the read, and your deblock code went past the block end. Gerhard Postpischil Bradford, VT -- 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
Re: CORRUPT PDS - I/O ERROR
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). 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. 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. Gerhard Postpischil Bradford, VT -- 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
Re: Corrupt PDS - I/O ERROR
Mr. Poncelet said We are arguing semantics. Yes, computer language statements have syntax requirements and properly-written statements have semantics associated with them. The language in the JCL Reference Manual specifically refers to the relative priority of information provided in the program DCB vs the DD/JFCB vs the DSCB, as is attested by the section title in the manual. The actual semantics of the OPEN statement are more complex. Mr. Poncelet argues that his meaning of override is the correct one. I would go with the meaning of override in the documentation, and as I used it. If my manager sends me an message telling me to do something, I may (with risks) override his wishes by doing something different, but that does not mean that I rewrote his message. The actual semantics of OPEN are that the DCB attributes in the DSCB are NOT rewritten on an OPEN for input. Mr. Poncelet demanded a verifiable example. I provided one. Read a member of a PDS with IDCAMS PRINT with a DD specifying RECFM=U,BLKSIZE=32760 This works, and does NOT update the DSCB. Dale Miller -- 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
Re: CORRUPT PDS - I/O ERROR
Shmuel Metz (Seymour J.) wrote: In 4e2f48fa.8010...@bcs.org.uk, on 07/27/2011 at 12:08 AM, CM Poncelet ponce...@bcs.org.uk said: But the exit points 'count' as program DCBs they 'count' as program DCBs is short-speak for 'they are executable code' (as opposed to JCL and DASD) NFW; they count as exits. The actual priority order is: DSCB1 JFCB[1] DCB Changes made by DCB Exit regardless of whether it is input or output. I know that; but on input they do not override the DCB from DASD - and that is regardless of their order as they execute first No. 'short-speak' for they 'they are part of program code execution' in the 'program - JCL - DASD' sequence (... and before you tell me that exits do not have to be part of a program, I know that too) and override what is in the JCL. Some do, some don't. I am speaking within the context of the priority order of DCBs in the 'program - JCL - DASD' sequence I don't check Using Data Sets; That was your first mistake. I don't need to check Using Data Sets (I did that more than 25 years ago or the 'equivalent of ditto' before you say Using Data Sets was not being published more than 25 years ago). Galileo did not need to check the Bible either before he said the earth was not at the center of the universe: was that his first mistake? but that is how things were in the days of MVS OS/VS SP1 (1985): There was no such animal. That wasn't the way that OS/360, OS/VS1, OS/VS2 R1, OS/VS2 MVS, MVS/SP or any subsequent version of MVS behaved. in that case it was one of OS/VS1 to MVS/SP (I don't spend time remembering these things, except vaguely) [1] Initially from JCL. I know that.. I think you are splitting hairs for the sake of arguing ... -- 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
Re: CORRUPT PDS - I/O ERROR
On Sun, 31 Jul 2011 15:43:15 +0100 CM Poncelet ponce...@bcs.org.uk wrote: :I know that; but on input they do not override the DCB from DASD - and :that is regardless of their order What do you mean by that statement? Do you mean that they do not change the physical data already recorded? Nobody would disagree. And that would equally apply to output. Do you mean that the program will have its non-zero DCB overlaid with the data from the DSCB? You are wrong. -- Binyamin Dissen bdis...@dissensoftware.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
Binyamin Dissen wrote: On Sun, 31 Jul 2011 15:43:15 +0100 CM Poncelet ponce...@bcs.org.uk wrote: :I know that; but on input they do not override the DCB from DASD - and :that is regardless of their order What do you mean by that statement? 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. This might suggest that the program's DCB, within the above context, overrides the one 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. 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 - just as there is no I/O error when the program opens a DCB for OUTPUT and then writes to DASD (regardless of what the DCB attributes are on DASD). 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. 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. Crashing with an I/O error indicates that the program's DCB was unable - not able - to override the DCB attributes on DASD. Do you mean that they do not change the physical data already recorded? Nobody would disagree. And that would equally apply to output. On INPUT, the programs' DCB does not even change the RECFM, LRECL and BLKSIZE on DASD - never mind the physical data. On OUTPUT, the program's DCB does change the RECFM, LRECL and BLKSIZE as well as the physical data on DASD - although a program would normally leave the RECFM, LRECL and BLKSIZE on DASD 'changed' to what they already are; otherwise we could get the sort of I/O errors which started this discussion thread. Do you mean that the program will have its non-zero DCB overlaid with the data from the DSCB? You are wrong. No, only its zero DCB attributes are overlaid - i.e. those which need to be filled in to 'complete' the DCB. -- Binyamin Dissen bdis...@dissensoftware.com 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
If you use IDCAMS to print a VB dataset in dump format with no DD overrides, you will get a dump of the data portion of the records and never see the BDW or RDW. If you run the same commands but specify RECFM=U and BLKSIZE=32760, your dump will be organized by blocks, not records, and you will see both the BDWs and RDWs. While the data in the DSCB will not be changed, it seems fairly obvious that the DCB data from the DSCB was (temporarily) overridden by the DCB data in the DD statement. And if you used a program that had DCB data hardcoded in the DCB macro, that data would override both the DSCB data and the DD statement data. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of CM Poncelet Sent: Sunday, July 31, 2011 9:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: CORRUPT PDS - I/O ERROR 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. This might suggest that the program's DCB, within the above context, overrides the one 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. 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 - just as there is no I/O error when the program opens a DCB for OUTPUT and then writes to DASD (regardless of what the DCB attributes are on DASD). 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. 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. Crashing with an I/O error indicates that the program's DCB was unable - not able - to override the DCB attributes on DASD. -- 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
Re: CORRUPT PDS - I/O ERROR
On 7/31/2011 12:35 PM, CM Poncelet wrote: 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. 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. Crashing with an I/O error indicates that the program's DCB was unable - not able - to override the DCB attributes on DASD. What we have here is a failure to communicate. Your statement above makes it evident that you are using DCB attributes on DASD as applying to the format of the data, whereas the other participants in this merry-go-round are referring to the DCB parameters in the format 1 DSCB (DS1RECFM, DS1LRECL, DS1BLKL). Gerhard Postpischil Bradford, VT -- 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
Re: CORRUPT PDS - I/O ERROR
On Sun, 31 Jul 2011 18:19:11 -0400 Gerhard Postpischil gerh...@valley.net wrote: :On 7/31/2011 12:35 PM, CM Poncelet wrote: : 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. 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. Crashing with an I/O error indicates that the program's : DCB was unable - not able - to override the DCB attributes on DASD. :What we have here is a failure to communicate. Your statement :above makes it evident that you are using DCB attributes on :DASD as applying to the format of the data, whereas the other :participants in this merry-go-round are referring to the DCB :parameters in the format 1 DSCB (DS1RECFM, DS1LRECL, DS1BLKL). Yes, that was what I was trying to point out to him. -- Binyamin Dissen bdis...@dissensoftware.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
In 4e34784d.2020...@bcs.org.uk, on 07/30/2011 at 10:31 PM, CM Poncelet ponce...@bcs.org.uk said: What I am saying is that, on INPUT, a dataset's physical DCB attributes from its DSCB on DASD cannot be overriden by a JCL or program DCB. Yes, and what you are saying is wrong. According to you, the DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) on SYSUT1 (opened for input) should override the dataset's DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) on DASD. Correct. But that is not the case. Yes it is. If you set up and run the jobsteps above, both IEBGENER and IDCAMS report IEB351I I/O ERROR etc. SYSUT1, READ, WRNG.LEN.RECORD, etc. when reading SYSUT1. Proving that the DCB information in the DD statement *did* override the DSCB. This is because the dataset's DASD DSCB/DCB attributes override those coded in the JCL (and would also override the programs's DCB, if hard-coded), for INPUT. No; if they overrode the DCB then you wouldn't get the I/O error. To say that the order of priority for INPUT is 'program DCB - JCL DCB - DASD DCB' is meaningless if neither the program DCB nor JCL DCB can modify/override the DASD's DSCB/DCB to avoid physical I/O errors on INPUT. To say that your name is Poncelet is meaningless if the Sun is an apple. I don't think I 'got it wrong' ... Then RTFM. -- 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
Re: CORRUPT PDS - I/O ERROR
In 4e349468.4060...@bcs.org.uk, on 07/31/2011 at 12:31 AM, CM Poncelet ponce...@bcs.org.uk said: I'm afraid I disagree. Because you are confusing the DSCB with the blocks written in the dataset. What it proves is not that the DCB on DASD was overwritten by the one in the JCL, but that the DCB in the JCL was incorrect/incompatible with the one on DASD. Why would you get an I/O error if the DCB information on the DD statement did not take precedence over that in the DSCB? -- 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
Re: CORRUPT PDS - I/O ERROR
The 'acid test' is whether the same program DCB (ignoring the MACRF= and EODAD=) can be used *both* for OUTPUT and for INPUT (with a change in MACFR= and adding EODAD= when opening for INPUT), when the dataset's physical DCB attributes on DASD are *different* from those specified in the program. If this DCB is opened for OUTPUT (MACRF=PM|L), then the program's DCB attributes override those on DASD - and the program's DCB attributes then also become those stored on DASD, all without causing I/O errors. This is because the program's DCB attributes override the dataset's existing DCB attributes on DASD when opened for OUTPUT. If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=etc.), then the program's DCB attributes do *not* override those on DASD - and, as the program's DCB attributes are inconsistent with those of the dataset on DASD, they cause I/O errors ... because the dataset's DCB attributes on DASD take priority over those of the program's DCB. If the program's DCB attributes do not match those on DASD for INPUT, it's just another case of garbage-in / garbage-out. A program's DCB attributes do *not* override an existing dataset's DCB attributes on DASD when opened for INPUT. Hence, if opened for OUTPUT, the priority order is program DCB - JCL DCB - DASD DCB. But if opened for INPUT, the priority order is DASD DCB - JCL DCB - program DCB. If the program's DCB attributes are then inconsistent with the ones on DASD, on INPUT, the program hits I/O errors - because the DCB attributes on DASD override those hard-coded in the program on INPUT (and not, as has been suggested, the other way round). If the program's DCB attributes, for INPUT, are inconsistent with those of the physical dataset stored on DASD, they do not override those stored on DASD but cause I/O failures. For the sake of expediency, DCB includes DSCB etc. - because this discussion topic is about DCBs. If I am wrong, please prove it by submitting verifiable 'general purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable example' is one in which all the program's DCB attributes are different from those of the dataset's physical DCB attributes on DASD - yet override the dataset's DCB attributes stored on DASD *both* when the dataset is opened and written for OUTPUT and also when it is opened and read for INPUT (subject to the appropriate MACRF= etc. being specified on the DCB in each case). If you cannot prove it by a 'verifiable example', then you are arguing high-falluting semantics where the interpretation of DCB override depends entirely upon what *you* mean by that, and is not subject to what DCB override is actually understood to mean in practice. Thanks, Chris Poncelet Binyamin Dissen wrote: On Sun, 31 Jul 2011 18:19:11 -0400 Gerhard Postpischil gerh...@valley.net wrote: :On 7/31/2011 12:35 PM, CM Poncelet wrote: : 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. 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. Crashing with an I/O error indicates that the program's : DCB was unable - not able - to override the DCB attributes on DASD. :What we have here is a failure to communicate. Your statement :above makes it evident that you are using DCB attributes on :DASD as applying to the format of the data, whereas the other :participants in this merry-go-round are referring to the DCB :parameters in the format 1 DSCB (DS1RECFM, DS1LRECL, DS1BLKL). Yes, that was what I was trying to point out to him. -- Binyamin Dissen bdis...@dissensoftware.com 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
Shmuel Metz (Seymour J.) wrote: In 4e349468.4060...@bcs.org.uk, on 07/31/2011 at 12:31 AM, CM Poncelet ponce...@bcs.org.uk said: I'm afraid I disagree. Because you are confusing the DSCB with the blocks written in the dataset. We are arguing semantics ... What it proves is not that the DCB on DASD was overwritten by the one in the JCL, but that the DCB in the JCL was incorrect/incompatible with the one on DASD. Why would you get an I/O error if the DCB information on the DD statement did not take precedence over that in the DSCB? Why would a square peg not fit in a round hole if the round hole did not take precedence over the square peg? -- 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
Re: CORRUPT PDS - I/O ERROR
snip-- 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. 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. Crashing with an I/O error indicates that the program's DCB was unable - not able - to override the DCB attributes on DASD. What we have here is a failure to communicate. Your statement above makes it evident that you are using DCB attributes on DASD as applying to the format of the data, whereas the other participants in this merry-go-round are referring to the DCB parameters in the format 1 DSCB (DS1RECFM, DS1LRECL, DS1BLKL). ---unsnip In several examples in this discussion, I've seen RECFM=VBA used to override RECFM=FBA. This leads me to believe, IMNSHO, that several contributors need to RTFM, especially with respect to the actual record contents and formats. Failure to grasp these differences can lead to endless frustration and gnashing of teeth. Rick -- 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
Re: CORRUPT PDS - I/O ERROR
-snip I'm afraid I disagree. Because you are confusing the DSCB with the blocks written in the dataset. What it proves is not that the DCB on DASD was overwritten by the one in the JCL, but that the DCB in the JCL was incorrect/incompatible with the one on DASD. Why would you get an I/O error if the DCB information on the DD statement did not take precedence over that in the DSCB? -unsnip- I must agree with Shmuel here. Just because the Format-1 DSCB provides a set of attributes does NOT mean that the data was necessarily written with those attributes. Granted, the exceptions are not all that common, but they do occur, usually when somebody codes incorrect attributes on a output DD statement that modifies the content of the dataset. In my last shop, coding DCB information on an output DD statement that wrote a member into an existing PDS was a severe no-no. Sometimes it's acceptable to code overrides when adding a member to a PDS, but those instances are few and far between. They should be avoided, especially changes to the RECFM. -- 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
Re: CORRUPT PDS - I/O ERROR
--snip-- I'm afraid I disagree. Because you are confusing the DSCB with the blocks written in the dataset. We are arguing semantics ... --unsnip NOT HARDLY! --snip-- What it proves is not that the DCB on DASD was overwritten by the one in the JCL, but that the DCB in the JCL was incorrect/incompatible with the one on DASD. Why would you get an I/O error if the DCB information on the DD statement did not take precedence over that in the DSCB? Why would a square peg not fit in a round hole if the round hole did not take precedence over the square peg? --unsnip-- If the attributes in the JCL are equally wrong, you'll still get that I/O error. Read up on the handling and formats of FIXED vs. VARIABLE vs. UNDEFINED records. What you apperantly don't know CAN hurt you! Rick -- 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
Re: CORRUPT PDS - I/O ERROR
Shmuel Metz (Seymour J.) wrote: In 4e34784d.2020...@bcs.org.uk, on 07/30/2011 at 10:31 PM, CM Poncelet ponce...@bcs.org.uk said: What I am saying is that, on INPUT, a dataset's physical DCB attributes from its DSCB on DASD cannot be overriden by a JCL or program DCB. Yes, and what you are saying is wrong. No, what I am saying is correct. What matters is not whether a program can open a DCB for input (trivial), but whether that DCB then actually works. According to you, the DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) on SYSUT1 (opened for input) should override the dataset's DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) on DASD. Correct. But that is not the case. Yes it is. No it isn't. What matters is whether the DCB opened for input *also* works when reading data from a dataset, when its attributes (RECFM=,LRECL=,BLKSIZE=) do not match those of the physical dataset on DASD. If you set up and run the jobsteps above, both IEBGENER and IDCAMS report IEB351I I/O ERROR etc. SYSUT1, READ, WRNG.LEN.RECORD, etc. when reading SYSUT1. Proving that the DCB information in the DD statement *did* override the DSCB. in theory, but not in practice. This is because the dataset's DASD DSCB/DCB attributes override those coded in the JCL (and would also override the programs's DCB, if hard-coded), for INPUT. No; if they overrode the DCB then you wouldn't get the I/O error. semantics ... To say that the order of priority for INPUT is 'program DCB - JCL DCB - DASD DCB' is meaningless if neither the program DCB nor JCL DCB can modify/override the DASD's DSCB/DCB to avoid physical I/O errors on INPUT. To say that your name is Poncelet is meaningless if the Sun is an apple. argumentum ad hominem? I don't think I 'got it wrong' ... Then RTFM. I don't need to. -- 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
Re: CORRUPT PDS - I/O ERROR
Rick Fochtman wrote: --snip-- I'm afraid I disagree. Because you are confusing the DSCB with the blocks written in the dataset. We are arguing semantics ... --unsnip NOT HARDLY! --snip-- What it proves is not that the DCB on DASD was overwritten by the one in the JCL, but that the DCB in the JCL was incorrect/incompatible with the one on DASD. Why would you get an I/O error if the DCB information on the DD statement did not take precedence over that in the DSCB? Why would a square peg not fit in a round hole if the round hole did not take precedence over the square peg? --unsnip-- If the attributes in the JCL are equally wrong, you'll still get that I/O error. ... because the DCB on DASD takes precedence over any coded in the JCL or in the program, in that order. The DCB attributes on DASD have the 'final say' in whether an input I/O will complete successfully. That a program can populate its own DCB from the JCL's DCB attributes, and then open it for input *before* having to deal with the real DCB on DASD, is irrelevant if the JCL DCB's attibutes are inconsistent with those of the physical dataset on DASD. It is the physical dataset's DCB attributes on DASD, and not those of the DCB opened by the program, which determine whether the I/O is successful. If those of the program's opened DCB do not match those of the physical dataset on DASD, the I/O fails - because the DCB on DASD 'overrides' (or 'takes precedence over' etc.) the DCB in the program when it is opened for input and the program then issues a read. Much of this 'discussion' has been akin to arguing that a bridge made of string and bamboo was correctly designed because, when a car tried to cross over it, the bridge broke and the car fell into the ravine ... and the car could not possibly have fallen into the ravine if the bridge had not been hanging across it in the first place - QED. Read up on the handling and formats of FIXED vs. VARIABLE vs. UNDEFINED records. What you apperantly don't know CAN hurt you! I don't need to be distracted by reading other people's opinions when I can think for myself. What I don't know can indeed hurt me - but what I know can't. Cheers, Chris Rick -- 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 -- 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
Re: CORRUPT PDS - I/O ERROR
The DCB coded in the program over-rides everything. If a data set has VB 133, 1330 and the program has FB 80,800 and opens it for either input or output, the DSCB will be changed to that coded in the program. It's always been that way. (Except the Fujitsu equivalent MSP Operating system put out warnings, or optionally wouldn't let you change certain attributes.) Cheers, Clem CM Poncelet wrote: Rick Fochtman wrote: --snip-- I'm afraid I disagree. Because you are confusing the DSCB with the blocks written in the dataset. We are arguing semantics ... --unsnip NOT HARDLY! --snip-- What it proves is not that the DCB on DASD was overwritten by the one in the JCL, but that the DCB in the JCL was incorrect/incompatible with the one on DASD. Why would you get an I/O error if the DCB information on the DD statement did not take precedence over that in the DSCB? Why would a square peg not fit in a round hole if the round hole did not take precedence over the square peg? --unsnip-- If the attributes in the JCL are equally wrong, you'll still get that I/O error. ... because the DCB on DASD takes precedence over any coded in the JCL or in the program, in that order. The DCB attributes on DASD have the 'final say' in whether an input I/O will complete successfully. That a program can populate its own DCB from the JCL's DCB attributes, and then open it for input *before* having to deal with the real DCB on DASD, is irrelevant if the JCL DCB's attibutes are inconsistent with those of the physical dataset on DASD. It is the physical dataset's DCB attributes on DASD, and not those of the DCB opened by the program, which determine whether the I/O is successful. If those of the program's opened DCB do not match those of the physical dataset on DASD, the I/O fails - because the DCB on DASD 'overrides' (or 'takes precedence over' etc.) the DCB in the program when it is opened for input and the program then issues a read. Much of this 'discussion' has been akin to arguing that a bridge made of string and bamboo was correctly designed because, when a car tried to cross over it, the bridge broke and the car fell into the ravine ... and the car could not possibly have fallen into the ravine if the bridge had not been hanging across it in the first place - QED. Read up on the handling and formats of FIXED vs. VARIABLE vs. UNDEFINED records. What you apperantly don't know CAN hurt you! I don't need to be distracted by reading other people's opinions when I can think for myself. What I don't know can indeed hurt me - but what I know can't. Cheers, Chris Rick -- 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
Re: CORRUPT PDS - I/O ERROR
On Mon, 1 Aug 2011 13:50:09 +1000, Clement Clarke wrote: If a data set has VB 133, 1330 and the program has FB 80,800 and opens it for either input or output, the DSCB will be changed to that coded in the program. Not quite. If the data set is opened for input, the program will attempt to read the data set. If a block 800 bytes is read, there will be a wrong length record error. Other errors might depend upon the access method used. The DSCB will not be changed, though. If the data set is opened for output, I don't know what happens if DISP=MOD. Is there an I/O error when the new data is written? If not there will surely be an error when the deat set is read with as either FB or VB. -- 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
Re: CORRUPT PDS - I/O ERROR
On Sat, 30 Jul 2011 04:27:44 -0700, Dale Miller wrote: In my previous note I said: one can TEMPORARILY override the dataset attributes with a DD card if the OPEN is for INPUT Mr. Marchant said NO, and referred to the JCL Reference Manual section Completing the data control block. Please read again what I said. I apologize. I wrote too fast without understanding what you wrote. I even skipped over your statement in the previous post that The stated priority is observed (which is why ... using a BLOCK CONTAINS clause with other than 0 on a COBOL input file is asking for problems). Of course you were saying that that the blocksize that was in the DCB is what is used. Thanks to Shmuel for pointing out my error. Since I no longer have much access to manuals or the class materials I generated relating to the OPEN process, I cannot cite any references They are readily available on the internet. -- 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
Re: CORRUPT PDS - I/O ERROR
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
Re: CORRUPT PDS - I/O ERROR
On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet wrote: If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=etc.), then the program's DCB attributes do *not* override those on DASD Right. No one said that they do. and, as the program's DCB attributes are inconsistent with those of the dataset on DASD, they cause I/O errors ... because the dataset's DCB attributes on DASD take priority over those of the program's DCB. No. Because the attributes specified in the completed DCB are inconsistent with the DATA on disk or tape. Consider an unlabeled tape. A data set that was written previously to tape is read by a program that specifies DCB attributes. If it specifies incorrect attributes, the program may get I/O errors. This is not because the DCB attributes on the tape override those coded in the DCB because there are no DCB attributes on an unlabeled tape. But if opened for INPUT, the priority order is DASD DCB - JCL DCB - program DCB. If the program's DCB attributes are then inconsistent with the ones on DASD, on INPUT, the program hits I/O errors It might very well because the DCB attributes on DASD override those hard-coded in the program on INPUT No, because the data on DASD are not consistent with the DCB parameters in the program. This would happen even of the DCB attributes in the DSCB were zapped to be the same as those in the program. If the program's DCB attributes, for INPUT, are inconsistent with those of the physical dataset stored on DASD, they do not override those stored on DASD The attributes in the DCB of an input data set are not written to the DSCB. That is correct. But for filling in the DCB, if a particular attribute is specified in the program, that attribute from the DSCB is not used. If I am wrong, please prove it by submitting verifiable 'general purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable example' is one in which all the program's DCB attributes are different from those of the dataset's physical DCB attributes on DASD - yet override the dataset's DCB attributes stored on DASD *both* when the dataset is opened and written for OUTPUT and also when it is opened and read for INPUT No one has claimed that the DCB attributes from the program are written to the DSCB when the data set is opened for input. If you cannot prove it by a 'verifiable example', then you are arguing high-falluting semantics where the interpretation of DCB override depends entirely upon what *you* mean by that, and is not subject to what DCB override is actually understood to mean in practice. I think that you are the one who is using a non-standard definition of what it means for a DCB attribute to be overridden. -- 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
Re: CORRUPT PDS - I/O ERROR
In my previous note I said: one can TEMPORARILY override the dataset attributes with a DD card if the OPEN is for INPUT Mr. Marchant said NO, and referred to the JCL Reference Manual section Completing the data control block. Please read again what I said. I said dataset attributes, not the data control block. My discussion of the process indicated that because of the order of the merge, if I supply a DD card with DCB attributes, the ones supplied on the DD card (JFCB) will override the DSCB/label, which is supported by the material quoted. I failed to say that that overridden information is what is used only if the program's DCB does not supply that information (or if a RDJFCB is used to allow the DD to override any defaults in the DCB.), I don't know the internal logic of IDCAMS print, but it does something like this since one CAN override the DSCB info with a DD card. Quite obviously, for a newly-created dataset, the information would have to come from the DD or the program DCB, but that is what I said:the forward merge from the dataset to the JFCB obviously cannot be done for a newly-created dataset. Since I no longer have much access to manuals or the class materials I generated relating to the OPEN process, I cannot cite any references, but they were there when I did the class. I can only say that my experience is that using IDCAMS PRINT with a bogus DD works and does not alter the PDS DSCB. The quoted material does NOT say that the DSCB is updated from the DCB for a file opened INPUT. But one thing should be obvious: the OPEN process is much more complex than indicated by the section from the JCL Reference Manual. Dale Miller dalelmil...@comcast.net -- 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
Re: CORRUPT PDS - I/O ERROR
What I am saying is that, on INPUT, a dataset's physical DCB attributes from its DSCB on DASD cannot be overriden by a JCL or program DCB. Consider the following JCL where SYS1.RECFMVBA.LRECL137.BLK27998 has physical DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) SYS1.RECFMFBA.LRECL137.BLK27948 has physical DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948,DSORG=PS): //IEBGENER EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //* //SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998, //* cannot override dataset's DCB on DASD via JCL, for INPUT: // DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) //* //SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948, // DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) //* //IDCAMS EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //* //SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998, //* cannot override dataset's DCB on DASD via JCL, for INPUT: // DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) //* //SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948, // DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) //SYSIN DD * REPRO INFILE(SYSUT1) + OUTFILE(SYSUT2) //* According to you, the DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) on SYSUT1 (opened for input) should override the dataset's DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) on DASD. But that is not the case. If you set up and run the jobsteps above, both IEBGENER and IDCAMS report IEB351I I/O ERROR etc. SYSUT1, READ, WRNG.LEN.RECORD, etc. when reading SYSUT1. This is because the dataset's DASD DSCB/DCB attributes override those coded in the JCL (and would also override the programs's DCB, if hard-coded), for INPUT. If SYSUT1 and SYSUT2 are switched round as in: //IEBGENER EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //* //SYSUT2DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998, //* can override dataset's DCB on DASD via JCL, for OUTPUT: // DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) //* //SYSUT1DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948, // DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) //* //IDCAMS EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //* //SYSUT2DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998, //* can override dataset's DCB on DASD via JCL, for OUTPUT: // DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) //* //SYSUT1DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948, // DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) //SYSIN DD * REPRO INFILE(SYSUT1) + OUTFILE(SYSUT2) //* Then SYSUT1's JCL DCB matches the one on DASD's DSCB and no I/O error occurs when reading SYSUT1. Likewise, no I/O error occurs when writing to SYSUT2 (although its JCL DCB does not match the one on DASD) because the JCL's DCB overrides the one on DASD, for OUTPUT. To say that the order of priority for INPUT is 'program DCB - JCL DCB - DASD DCB' is meaningless if neither the program DCB nor JCL DCB can modify/override the DASD's DSCB/DCB to avoid physical I/O errors on INPUT. I don't think I 'got it wrong' ... Cheers, Chris Poncelet . Tom Marchant wrote: On Thu, 28 Jul 2011 12:04:37 -0700, Dale Miller wrote: 2) There is a difference between the relative priority of DCB information, and the actual mechanism involved. The order of priority was stated correctly, stated correctly by whom? AFAIK, CM Poncelet got it wrong. but the exact mechanism is a little more complex and does depend on a) whether the DISP is NEW (or MOD if the dataset is not found and must be created), or OLD/SHR(or MOD if the dataset is found) Label (DSCB or tape label) is only used for an existing data set b) whether the file is opened for INPUT or OUTPUT. Mr. Poncelet made the same assertion. I'm pretty sure that it is incorrect. Do you have a manual reference that you can cite to justify it? one can TEMPORARILY override the dataset attributes with a DD card if the OPEN is for INPUT No. See for example the JCL Reference manual. quote 12.16.3 Completing the Data Control Block The system obtains data control block information from the following sources, in override order: - The processing program, that is, the DCB macro instruction in assembler language programs or file definition statements or language-defined defaults in programs in other languages. - The DCB subparameter of the DD statement. - The data set label. Therefore, if you supply information for the same DCB field in your processing program and on a DD statement, the system ignores the DD DCB subparameter. If a DD statement and the data set label supply information for the same DCB field, the system ignores the data set label information. /quote -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
Re: CORRUPT PDS - I/O ERROR
On Sat, 30 Jul 2011 22:31:57 +0100 CM Poncelet ponce...@bcs.org.uk wrote: :What I am saying is that, on INPUT, a dataset's physical DCB attributes :from its DSCB on DASD cannot be overriden by a JCL or program DCB. :Consider the following JCL where :SYS1.RECFMVBA.LRECL137.BLK27998 has physical :DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) :SYS1.RECFMFBA.LRECL137.BLK27948 has physical :DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948,DSORG=PS): ://IEBGENER EXEC PGM=IEBGENER ://SYSPRINT DD SYSOUT=* ://SYSIN DD DUMMY ://* ://SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998, ://* cannot override dataset's DCB on DASD via JCL, for INPUT: :// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) ://* ://SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948, :// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) ://* ://IDCAMS EXEC PGM=IDCAMS ://SYSPRINT DD SYSOUT=* ://* ://SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998, ://* cannot override dataset's DCB on DASD via JCL, for INPUT: :// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) ://* ://SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948, :// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) ://SYSIN DD * : REPRO INFILE(SYSUT1) + : OUTFILE(SYSUT2) ://* :According to you, the DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) on SYSUT1 :(opened for input) should override the dataset's :DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) on DASD. But that is :not the case. :If you set up and run the jobsteps above, both IEBGENER and IDCAMS :report IEB351I I/O ERROR etc. SYSUT1, READ, WRNG.LEN.RECORD, etc. :when reading SYSUT1. This is because the dataset's DASD DSCB/DCB :attributes override those coded in the JCL (and would also override the :programs's DCB, if hard-coded), for INPUT. Not at all. It proves that the DCB - was - overridden. Of course, the DCB override does not affect the physical data. If the actual data block length is longer than the DCB block length there will be an I/O error. For example, if your override was for a - larger - blocksize it would have worked fine (other than perhaps IDCAMS/IEBGENER) warnings about different block sizes. -- Binyamin Dissen bdis...@dissensoftware.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
I'm afraid I disagree. What it proves is not that the DCB on DASD was overwritten by the one in the JCL, but that the DCB in the JCL was incorrect/incompatible with the one on DASD. If I allocate SYSUT1 with DCB=(RECFM=FBA,LRECL=121,BLKSIZE=16093) and SYSUT2 with DCB=(REFM=FBA,LRECL=133,BLKSIZE=16093), where 121*133=16093, then both the physical RECFM and data block lengths are the same for SYSUT1 and SYSUT2. If I specify: //IEBGENER EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //* //SYSUT1DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL121.BLK16093, //* cannot override dataset's DCB on DASD via JCL, for INPUT: // DCB=(RECFM=FBA,LRECL=133,BLKSIZE=16093) //* //SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL133.BLK16093, // DCB=(RECFM=FBA,LRECL=133,BLKSIZE=16093) //* etc. I then still hit I/O errors without IEBGENER issuing message IEB311I CONFLICTING DCB PARAMETERS and the DCB BLKSIZEs are compatible, i.e. the physical data block size is not larger than the DCB BLKSIZE in the JCL's override. If instead I allocate SYSUT1 with DCB=(RECFM=FBA,LRECL=121,BLKSIZE=16093) and SYSUT2 with DCB=(REFM=FBA,LRECL=133,BLKSIZE=27930) and specify //IEBGENER EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //* //SYSUT1DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL121.BLK16093, //* cannot override dataset's DCB on DASD via JCL, for INPUT: // DCB=(RECFM=FBA,LRECL=133,BLKSIZE=27930) //* //SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL133.BLK16093, // DCB=(RECFM=FBA,LRECL=133,BLKSIZE=27930) //* etc. I then still hit I/O errors without IEBGENER issuing message IEB311I CONFLICTING DCB PARAMETERS and the JCL's DCB BLKSIZE override for SYSUT1 is now greater than its physical data block size on DASD (hence there is enough buffer space allocated via the JCL DCB's override to read in a SYSUT1's complete physical data block from DASD). Hence your For example, if your override was for a - larger - blocksize it would have worked fine (other than perhaps IDCAMS/IEBGENER) warnings about different block sizes. is not correct. An equal or larger blocksize override in the JCL makes no difference. What you are implicitly suggesting is that the I/O error has nothing to do with the JCL or program DCB being in error. But if so, is it then the one on DASD that is incorrect? I am saying that the DCB on DASD can be overridden only during OUTPUT, not INPUT. That the JCL or program DCB specifies a 'round hole' override into which the DASD's 'square peg' DCB cannot fit does not imply that the JCL or program DCB has successfully overridden the one on DASD, but rather that the program or JCL DCB is wrong and cannot override the one on DASD. Thanks anyway. Chris Poncelet Binyamin Dissen wrote: On Sat, 30 Jul 2011 22:31:57 +0100 CM Poncelet ponce...@bcs.org.uk wrote: :What I am saying is that, on INPUT, a dataset's physical DCB attributes :from its DSCB on DASD cannot be overriden by a JCL or program DCB. :Consider the following JCL where :SYS1.RECFMVBA.LRECL137.BLK27998 has physical :DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) :SYS1.RECFMFBA.LRECL137.BLK27948 has physical :DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948,DSORG=PS): ://IEBGENER EXEC PGM=IEBGENER ://SYSPRINT DD SYSOUT=* ://SYSIN DD DUMMY ://* ://SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998, ://* cannot override dataset's DCB on DASD via JCL, for INPUT: :// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) ://* ://SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948, :// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) ://* ://IDCAMS EXEC PGM=IDCAMS ://SYSPRINT DD SYSOUT=* ://* ://SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998, ://* cannot override dataset's DCB on DASD via JCL, for INPUT: :// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) ://* ://SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948, :// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) ://SYSIN DD * : REPRO INFILE(SYSUT1) + : OUTFILE(SYSUT2) ://* :According to you, the DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) on SYSUT1 :(opened for input) should override the dataset's :DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) on DASD. But that is :not the case. :If you set up and run the jobsteps above, both IEBGENER and IDCAMS :report IEB351I I/O ERROR etc. SYSUT1, READ, WRNG.LEN.RECORD, etc. :when reading SYSUT1. This is because the dataset's DASD DSCB/DCB :attributes override those coded in the JCL (and would also override the :programs's DCB, if hard-coded), for INPUT. Not at all. It proves that the DCB - was - overridden. Of course, the DCB override does not affect the physical data. If the actual data block length is longer than the DCB block length there will be an I/O error. For example, if your override was for a - larger - blocksize it would have worked fine (other than perhaps IDCAMS/IEBGENER) warnings about different block
Re: CORRUPT PDS - I/O ERROR
In 1311699756.83896.yahoomail...@web34508.mail.mud.yahoo.com, on 07/26/2011 at 10:02 AM, esmie moo esmie_...@yahoo.ca said: When I try to browse a member of my pds I get a I/O error. I tried browsing several members but I get the same error message. Is there a way of fixing it? Not without knowing what the error message is. -- 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
Re: CORRUPT PDS - I/O ERROR
In 4e2f48fa.8010...@bcs.org.uk, on 07/27/2011 at 12:08 AM, CM Poncelet ponce...@bcs.org.uk said: But the exit points 'count' as program DCBs NFW; they count as exits. The actual priority order is: DSCB1 JFCB[1] DCB Changes made by DCB Exit regardless of whether it is input or output. as they execute first No. and override what is in the JCL. Some do, some don't. I don't check Using Data Sets; That was your first mistake. but that is how things were in the days of MVS OS/VS SP1 (1985): There was no such animal. That wasn't the way that OS/360, OS/VS1, OS/VS2 R1, OS/VS2 MVS, MVS/SP or any subsequent version of MVS behaved. [1] Initially from JCL. -- 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
Re: CORRUPT PDS - I/O ERROR
In a6b9336cdb62bb46b9f8708e686a7ea00afc0ed...@nrhmms8p02.uicnrh.dom, on 07/27/2011 at 07:20 AM, McKown, John john.mck...@healthmarkets.com said: Many placed do. I don't understand why. Stupidity above and beyond the call of duty. It's an example of auditing by checklist, with the checklist written by Kafka. -- 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
