Re: Braces, Brackets, Broken braces, and Parentheses
The French language is defined by the Académie Française ... and is
subject to change 'without notice'. When I was studying in French at
school, and I did so for 13 years, a "guillemet" was a single quote.
Hence, expressions such as "entre guillemets" meant "in quotes". Double
quotes were known as "double-guillemets". However, there were no "<" or
">" symbols in common use in those days (1950-60's) - and it is quite
possible that "guillemets" has several meanings in French.
My 1948 edition of the "Nouveau petit Larousse illustré" defines
"guillemet" as: "Petit crochet double, qui se met au commencement (<<)
et à la fin (>>) d'une citation." That concurs with what wikipedia is
saying. But when I was at school, "guillemets" always meant quotes - not
angled brackets. (Angled brackets did not exist - they were not part of
French 'orthography' - to my knowledge.)
By contrast, my 1982 edition of "Harrap's Shorter French and English
Dictionary" interprets "guillemets" as "inverted commas, quotation
marks; F: (colloquial) quotes; mot entre g., word in inverted commas;
(when dictating) ouvrez, fermez, les g., quote; unquote". Also, it
translates "quotes" as "guillemets; in quotes, entre guillemets."
So there seem to be different interpretations of the word - with "<<"
and ">>" also being called "guillemets". But that's new to me.
Shmuel Metz (Seymour J.) wrote:
In <4ec8a525.2010...@bcs.org.uk>, on 11/20/2011
at 06:58 AM, CM Poncelet said:
In French, "guillemets" refer to single quotes (" ' "). Double quotes
(' " ') are called "double guillemets".
Are you sure that it's not <> and <<>> rather than apostrophes and
quotes? See <http://en.wikipedia.org/wiki/Guillemets>. Also see
Unicode code points U+00AB, U+00BB, U+2039, U+203A.
--
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: Braces, Brackets, Broken braces, and Parentheses
In French, "guillemets" refer to single quotes (" ' "). Double quotes ('
" ') are called "double guillemets".
John Gilmore wrote:
Shmuel,
If you'll look into the Wikipedia piece on Brackets, you'll find
mention of the "occasional" use of the term "broken brackets" and
some examples. It is the one I have used routinely for many years.
(I have consulted my colleagues, and they use it too, but I may very
well have contaminated what they say.)
The French word you're looking for may be "guillemets", viz., «, »,
which in written Metropolitan French are almost exact equivalents of
written English-language [double] quotes, ",".
The use of ",'' instead of «, » is increasingly common in
non-Metropolitan French, which is, I think, unfortunate: I like the
fact that the difference between the prefixing and suffixing values is
builtin, not at the mercy of some typeface designer or a text-editing
program that never gets things quite right.
John Gilmore, Ashland, MA 01721 - USA
--
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: Religious controversy on IBM-MAIN
The only religion that matters is logic. Shmuel Metz (Seymour J.) wrote: In , on 11/19/2011 at 09:18 AM, John Gilmore said: We are a mixture of the devout, the indifferent, and the militantly anti-religious. This mixture is explosive. Religous comments would be potentially explosive even if everyone here were devout, perhaps especially if everyone here were devout. Different religions, even different sects of the "same" religion, hold profoundly different views. -- 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 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... 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
Shmuel Metz (Seymour J.) wrote: In <4e3ca3f5.1060...@bcs.org.uk>, on 08/06/2011 at 03:16 AM, CM Poncelet 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... 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
Shmuel Metz (Seymour J.) wrote: In <4e3a4e7e.5090...@bcs.org.uk>, on 08/04/2011 at 08:47 AM, CM Poncelet 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 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
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
'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
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
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
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
Tom Marchant wrote: On Tue, 2 Aug 2011 20:11:27 +0100, CM Poncelet 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
Shmuel Metz (Seymour J.) wrote: In <4e38932c.2030...@bcs.org.uk>, on 08/03/2011 at 01:15 AM, CM Poncelet 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
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" 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
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 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 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
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
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: --- 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 "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. -- 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. --- 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
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 'pr
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'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
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 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=&&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=&&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
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 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 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
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=), 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
Rick Fochtman wrote: I'm afraid I disagree. Because you are confusing the DSCB with the blocks written in the dataset. We are arguing semantics ... -- NOT HARDLY! 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? 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
Shmuel Metz (Seymour J.) wrote: In <4e34784d.2020...@bcs.org.uk>, on 07/30/2011 at 10:31 PM, CM Poncelet 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 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
Shmuel Metz (Seymour J.) wrote: In <4e349468.4060...@bcs.org.uk>, on 07/31/2011 at 12:31 AM, CM Poncelet 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
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=), 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 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 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
Binyamin Dissen wrote: On Sun, 31 Jul 2011 15:43:15 +0100 CM Poncelet 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 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 <4e2f48fa.8010...@bcs.org.uk>, on 07/27/2011 at 12:08 AM, CM Poncelet 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
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) //* 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) //* 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 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 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
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 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. 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. -- For IBM-MAIN subscribe / signoff / archive access i
Re: CORRUPT PDS - I/O ERROR
In that case I'd have to check it physically (with a 'program v. JCL' DCB with MACRF=(R/G)) ... and I don't have the time to do that. Thanks anyway. Tom Marchant wrote: On Wed, 27 Jul 2011 00:08:42 +0100, CM Poncelet wrote: I don't check "Using Data Sets"; Perhaps you should. but that is how things were in the days of MVS OS/VS SP1 (1985): It was not how it worked in OS/360. I just looked it up in the JCL manual on bitsavers. The sequence of completing a DCB is the same regardless of whether the data set is opened for input, output or I/O. if things have 'changed' since then, so be it. Tom Marchant wrote: On Tue, 26 Jul 2011 22:47:16 +0100, CM Poncelet wrote: When opening for input, the priority order is reversed (DASD, JCL, program). I don't think so, and Using Data Sets seems to say otherwise. Can you cite a reference? -- 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
But the exit points 'count' as program DCBs ... as they execute first and override what is in the JCL. I don't check "Using Data Sets"; but that is how things were in the days of MVS OS/VS SP1 (1985): if things have 'changed' since then, so be it. Tom Marchant wrote: On Tue, 26 Jul 2011 22:47:16 +0100, CM Poncelet wrote: When opening for output, the DCB used is (a) the one specified in the program; (b) the one in the JCL; (c) the one on DASD - in that order of priority. Correct, but incomplete. There are exits points that can alter the DCB attributes too. When opening for input, the priority order is reversed (DASD, JCL, program). I don't think so, and Using Data Sets seems to say otherwise. Can you cite a reference? -- 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
This can happen with any PDS if it is opened for output with a DCB other than its original one (e.g. originally RECFM=FB, but opened with RECFM=VB etc.) When opening for output, the DCB used is: (a) the one specified in the program; (b) the one in the JCL; (c) the one on DASD - in that order of priority. When opening for input, the priority order is reversed (DASD, JCL, program). If the incorrect output DCB was specified in a program, it needs to be fixed there: this program should then be rerun to open the PDS with its correct attributes; then close the PDS. After that, the original members will be accessible again. But any members which were created using the program's previously incorrect DCB will now hit I/O errors (so copy them to another PDS beforehand if they need to be kept). esmie moo wrote: Good Morning Gentle Readers, 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? For some reason the storage group is NOT backed up so I cannot restore it from an old backup. I recovered the PDS from a DFHSM backup but when I try to browse any members I still get the I/O error. Is there a work around to this problem or should I consider it lost? Thanks. -- 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
This can happen with any PDS if it is opened for output with a DCB other than its original one (e.g. originally RECFM=FB, but opened with RECFM=VB etc.) When opening for output, the DCB used is (a) the one specified in the program; (b) the one in the JCL; (c) the one on DASD - in that order of priority. When opening for input, the priority order is reversed (DASD, JCL, program). If the incorrect output DCB was specified in a program, it needs to be fixed there: this program should then be rerun to open the PDS with its correct attributes; then close the PDS. After that, the original members will be accessible again. But any members which were created using the program's previously incorrect DCB will now hit I/O errors (so copy them to another PDS beforehand if they need to be kept). Schwarz, Barry A wrote: If the storage group is not backed up, how did HSM ever back up a copy for you to recover from? Was there a copy of the dataset on disk when you recovered it from HSM? What was the command you used to perform the recovery? When you browse the PDS, does the member list display correctly? What are the DCB attributes of the PDS? Do they match what you think they should be? What is the exact error message? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo Sent: Tuesday, July 26, 2011 10:03 AM To: IBM-MAIN@bama.ua.edu Subject: CORRUPT PDS - I/O ERROR Good Morning Gentle Readers, 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? For some reason the storage group is NOT backed up so I cannot restore it from an old backup. I recovered the PDS from a DFHSM backup but when I try to browse any members I still get the I/O error. Is there a work around to this problem or should I consider it lost? -- 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: If Else JCL question
Paul Gilmartin wrote: On Fri, 21 Jan 2011 02:01:45 +, CM Poncelet wrote: Any boolean tests can be performed with 'COND=', but not so with 'IF ELSE etc.' We have already discussed this in the past. Sorry; I missed that. But please show me how 'IF ELSE ...' handles the following: Execute STEPF if - STEPA sets CC=04, STEPB sets CC=00, STEPC did not execute, STEPD sets CC=08 and STEPE did not execute or if - STEPA sets CC=00, STEPB did not execute, STEPC sets CC=04, STEPD did not execute and STEPE sets CC=00 or if - STEPA did not execute, STEPB sets CC=00, STEPC sets CC=04, STEPD sets CC=08 and STEPE sets either CC=04 or CC=08 otherwise do not execute STEPF. OK: // //IFELSEJOB 505303JOB,'Paul Gilmartin', // MSGLEVEL=(1,1),REGION=0M //* //USERCOUTPUT JESDS=ALL,DEFAULT=YES, // CLASS=R,PAGEDEF=V0648Z,CHARS=GT12 //* //STEPA EXEC PGM=IEFBR14 //STEPB EXEC PGM=IEFBR14 //STEPC EXEC PGM=IEFBR14 //STEPD EXEC PGM=IEFBR14 //STEPE EXEC PGM=IEFBR14 //TEST IF ( STEPA.RC=04 & STEPB.RC=00 & x // STEPC.RUN=FALSE & STEPD.RC=08 & STEPE.RUN=FALSE ) | x // ( STEPA.RC=00 & STEPB.RUN=FALSE & x // STEPC.RC=04 & STEPD.RUN=FALSE & STEPE.RC=00 ) | x // ( STEPA.RUN=FALSE & STEPB.RC=00 & x // STEPC.RC=04 & STEPD.RC=08 & x // ( STEPE.RC=04 | STEPE.RC=08 ) ) THEN //STEPF EXEC PGM=IEFBR14 //TEST ENDIF // :w ! submit Tested; STEPA through STEPE execute; STEPF is skipped because of condiional expression. I didn't check with truth table. Also typos possible. Now, kindly reciprocate and show me how this is coded with the COND parameter on the EXEC statement, please, Here it is again, hopefully more legible ... Case #1: //STEPA EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSINDD * SET MAXCC EQ 4 //STEPB EXEC PGM=IEFBR14 //STEPC EXEC PGM=IEFBR14,COND=(0,LE) //STEPD EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSINDD * SET MAXCC EQ 8 //STEPE EXEC PGM=IEFBR14,COND=(0,LE) //* //EX01 EXEC PGM=IEFBR14, //COND=((04,NE,STEPA),(00,NE,STEPB),(00,LE,STEPC), //(08,NE,STEPD),(00,LE,STEPE)) //EX02 EXEC PGM=IEFBR14, //COND=((00,NE,STEPA),(00,LE,STEPB),(04,NE,STEPC), //(00,LE,STEPD),(00,NE,STEPE)) //OX03 EXEC PGM=IEFBR14, //COND=((04,EQ,STEPE),(08,EQ,STEPE)) //EX03 EXEC PGM=IEFBR14, //COND=((00,LE,STEPA),(00,NE,STEPB),(04,NE,STEPC), //(08,NE,STEPD),(00,LE,OX03)) //NX04 EXEC PGM=IEFBR14, //COND=((00,LE,EX01),(00,LE,EX02),(00,LE,EX03)) //* //STEPF EXEC PGM=IEFBR14,COND=(00,LE,NX04) Case #2: //STEPA EXEC PGM=IEFBR14 //STEPB EXEC PGM=IEFBR14,COND=(0,LE) //STEPC EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSINDD * SET MAXCC EQ 4 //STEPD EXEC PGM=IEFBR14,COND=(0,LE) //STEPE EXEC PGM=IEFBR14 //* //EX01 EXEC PGM=IEFBR14, //COND=((04,NE,STEPA),(00,NE,STEPB),(00,LE,STEPC), //(08,NE,STEPD),(00,LE,STEPE)) //EX02 EXEC PGM=IEFBR14, //COND=((00,NE,STEPA),(00,LE,STEPB),(04,NE,STEPC), //(00,LE,STEPD),(00,NE,STEPE)) //OX03 EXEC PGM=IEFBR14, //COND=((04,EQ,STEPE),(08,EQ,STEPE)) //EX03 EXEC PGM=IEFBR14, //COND=((00,LE,STEPA),(00,NE,STEPB),(04,NE,STEPC), //(08,NE,STEPD),(00,LE,OX03))
Re: If Else JCL question
Paul Gilmartin wrote: On Fri, 21 Jan 2011 02:01:45 +, CM Poncelet wrote: Any boolean tests can be performed with 'COND=', but not so with 'IF ELSE etc.' We have already discussed this in the past. Sorry; I missed that. Actually, I did not realise 'IF ELSE ...' now supports boolean testing (if it does, that is). As far as I know, it didn't in the past - but, then again, I never use it anyway. But please show me how 'IF ELSE ...' handles the following: Execute STEPF if - STEPA sets CC=04, STEPB sets CC=00, STEPC did not execute, STEPD sets CC=08 and STEPE did not execute or if - STEPA sets CC=00, STEPB did not execute, STEPC sets CC=04, STEPD did not execute and STEPE sets CC=00 or if - STEPA did not execute, STEPB sets CC=00, STEPC sets CC=04, STEPD sets CC=08 and STEPE sets either CC=04 or CC=08 otherwise do not execute STEPF. OK: // //IFELSEJOB 505303JOB,'Paul Gilmartin', // MSGLEVEL=(1,1),REGION=0M //* //USERCOUTPUT JESDS=ALL,DEFAULT=YES, // CLASS=R,PAGEDEF=V0648Z,CHARS=GT12 //* //STEPA EXEC PGM=IEFBR14 //STEPB EXEC PGM=IEFBR14 //STEPC EXEC PGM=IEFBR14 //STEPD EXEC PGM=IEFBR14 //STEPE EXEC PGM=IEFBR14 //TEST IF ( STEPA.RC=04 & STEPB.RC=00 & x // STEPC.RUN=FALSE & STEPD.RC=08 & STEPE.RUN=FALSE ) | x // ( STEPA.RC=00 & STEPB.RUN=FALSE & x // STEPC.RC=04 & STEPD.RUN=FALSE & STEPE.RC=00 ) | x // ( STEPA.RUN=FALSE & STEPB.RC=00 & x // STEPC.RC=04 & STEPD.RC=08 & x // ( STEPE.RC=04 | STEPE.RC=08 ) ) THEN //STEPF EXEC PGM=IEFBR14 //TEST ENDIF // :w ! submit Tested; STEPA through STEPE execute; STEPF is skipped because of condiional expression. I didn't check with truth table. Also typos possible. Now, kindly reciprocate and show me how this is coded with the COND parameter on the EXEC statement, please, Case #1: //STEPA EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSINDD * SET MAXCC EQ 4 //STEPB EXEC PGM=IEFBR14 //STEPC EXEC PGM=IEFBR14,COND=(0,LE) //STEPD EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSINDD * SET MAXCC EQ 8 //STEPE EXEC PGM=IEFBR14,COND=(0,LE) //* //* THE FOLLOWING ARE THE SAME IN ALL CASES: //* //EX01 EXEC PGM=IEFBR14, //COND=((04,NE,STEPA),(00,NE,STEPB),(00,LE,STEPC), //(08,NE,STEPD),(00,LE,STEPE)) //EX02 EXEC PGM=IEFBR14, //COND=((00,NE,STEPA),(00,LE,STEPB),(04,NE,STEPC), //(00,LE,STEPD),(00,NE,STEPE)) //OX03 EXEC PGM=IEFBR14, //COND=((04,EQ,STEPE),(08,EQ,STEPE)) //EX03 EXEC PGM=IEFBR14, //COND=((00,LE,STEPA),(00,NE,STEPB),(04,NE,STEPC), //(08,NE,STEPD),(00,LE,OX03)) //NX04 EXEC PGM=IEFBR14, //COND=((00,LE,EX01),(00,LE,EX02),(00,LE,EX03)) //* //STEPF EXEC PGM=IEFBR14,COND=(00,LE,NX04) Case #2: //STEPA EXEC PGM=IEFBR14 //STEPB EXEC PGM=IEFBR14,COND=(0,LE) //STEPC EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSINDD * SET MAXCC EQ 4 //STEPD EXEC PGM=IEFBR14,COND=(0,LE) //STEPE EXEC PGM=IEFBR14 //* //* THE FOLLOWING ARE THE SAME IN ALL CASES: //* //EX01 EXEC PGM=IEFBR14, //COND=((04,NE,STEPA),(00,NE,STEPB),(00,LE,STEPC), //(08,NE,STEPD),(00,LE,STEPE)) //EX02 EXEC PGM=IEFBR14, //COND=((00,NE,STEPA),(00,LE,STEPB),(04,NE,STEPC), //(00,LE,STEPD),(00,NE,STEPE)) //OX03 EXEC PGM=IEFBR14,
Re: If Else JCL question
Any boolean tests can be performed with 'COND=', but not so with 'IF ELSE etc.' We have already discussed this in the past. But please show me how 'IF ELSE ...' handles the following: Execute STEPF if - STEPA sets CC=04, STEPB sets CC=00, STEPC did not execute, STEPD sets CC=08 and STEPE did not execute or if - STEPA sets CC=00, STEPB did not execute, STEPC sets CC=04, STEPD did not execute and STEPE sets CC=00 or if - STEPA did not execute, STEPB sets CC=00, STEPC sets CC=04, STEPD sets CC=08 and STEPE sets either CC=04 or CC=08 otherwise do not execute STEPF. 'IF ELSE ...' is to 'COND=' as 'mouse' is to 'keyboard'. Cheers, Chris Poncelet Paul Gilmartin wrote: On Thu, 20 Jan 2011 20:04:08 +, CM Poncelet wrote: But one of the most useful purposes of COND= testing is COND=(0,LE,) ... which ensures the current jobstep will NOT execute unless previous jobstep did NOT execute. So 'NOT logic' can still do what 'IF ELSE etc.' cannot. CP What am I missing? From: Title: z/OS V1R12.0 MVS JCL Reference Document Number: SA22-7597-14 17.1.4.5 Relational-Expression Keywords ... ^stepname.RUN stepname.RUN=FALSE Indicates that the relational expression tests that a specific job step (stepname) did not start execution. -- gil -- 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: If Else JCL question
But one of the most useful purposes of COND= testing is COND=(0,LE,) ... which ensures the current jobstep will NOT execute unless previous jobstep did NOT execute. So 'NOT logic' can still do what 'IF ELSE etc.' cannot. CP Mark Pace wrote: One thing I've been taught since I was in school 30+ years ago. Do not use NOT logic. COND goes against everything I've worked at my entire career. On Thu, Jan 20, 2011 at 2:07 PM, Lindy Mayfield wrote: LOL. I've been writing JCL for 25 years and I still cannot get the COND right. From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin [paulgboul...@aim.com] Sent: 20 January 2011 02:45 To: IBM-MAIN@bama.ua.edu Subject: Re: If Else JCL question On Wed, 19 Jan 2011 13:13:03 -0800, Cris Hernandez #9 wrote: suppose I'm old school, never saw a need to code IF-THEN-ELSE in JCL, only use cond code checking and never have any issues with step execution or job flow. the only cond code testing I ever do when writing procs is, "if it's true, it's through", meaning the step/job won't execute if the COND is true. I guess IBM added all that IF-THEN-ELSE stuff because too many coders never learned that lesson. http://db.cs.berkeley.edu/postgres.html -- gil -- 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 -- 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: IEFBR14
It had one instruction at the time. After the APAR it had two. CP Gerhard Adam wrote: Well with two instructions a single APAR would make the ratio 50%. If it only had one instruction at the time, it would have been 100%. So I'm sure the ratio is true, even if it is trivial. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Gould Sent: Saturday, November 20, 2010 8:09 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFBR14 --- On Fri, 11/19/10, Paul Gilmartin wrote: It is rumored that IEFBR14 has the highest ratio of APARs to bytes of code of any MVS program supplied by IBM. I don't know how to substantiate that. I'd be more confident that IEFBR14 has the highest ratio of lines of Friday LISTSERV discussion to lines of executable code. Just doing my part, gil Gil: The only APAR that I can ever remember IEFBR14 was zeroing out the return code in reg 15. I know I was one of those people who asked for tyhe APAR and that was a *LONG TIME AGO*. I am talking late 70's or early 80's. I know at one time there was "talk" about having an Eye catcher in the "module" but I do not recall ever hearing where that ended up.Personally I think its a waste of time as we are talking 2 instrctions. ed -- 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 -- 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: QUERY IN ASSEMBLER
Do you clear R15 (e.g. "XR 15,15") before you end your program? Cheers, Chris Poncelet Ram Study wrote: Hi All, I have written a basic file handling program and ran in assembler. Program went fine but I am getting cond code 3552. Is that common..? Is there any cond code list for assembler. Regards, Ram Balaji.S. -- 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: C-I-C-S vs KICKS
For what it's worth, the chap who told me that CICS' original name was "Cincinnati Information Control System" also said that "DFH" stood for "Denver Foot Hills"; but no one has ever confirmed this. I once asked Pete Sadler whether he could explain where "DFH" came from (because of IMS's similar "DFS" prefix): he said the prefixes had no particular meaning as far as he knew. So I guess that puts the lid on it. Thanks for all the other info, BTW. Cheers, Chris Poncelet Anne & Lynn Wheeler wrote: ponce...@bcs.org.uk (CM Poncelet) writes: That is what an ex-IBMer from the old days told me 'CICS' originally stood for - before it was renamed as 'Customer Information Control System' and sold to the rest of the world. I have no supporting evidence apart from this hearsay. I was undergraduate at the univ. and responsible for os/360 ... and also did a bunch of cp67 stuff. the univ. library got an ONR grant to do online catalog ... they used some of the money to buy a 2321 (datacell). that effort also got selected to be beta-test for CICS product release ... and I got tasked to (also) debug/support CICS. I was told it was originally developed at some utility customer ... before being selected for release. One of the bugs I remember tracking down turned out to be an BDAM OPEN bug ... it involved some conflict between the BDAM features used in the original implementation and the BDAM features selected by the library. misc. past posts mentioning CICS (&/or BDAM) http://www.garlic.com/~lynn/submain.html#cics doesn't mention any of that here: http://www-01.ibm.com/support/docview.wss?uid=swg21025234 this has a little more (but can't always trust wiki) http://en.wikipedia.org/wiki/CICS from above: The first CICS product was released in 1968, named Public Utility Customer Information Control System, or PU-CICS. CICS was originally developed to address requirements from the public utility industry, but it became clear immediately that it had applicability to many other industries, so the Public Utility prefix was dropped with the introduction of the first release of the CICS Program Product. ... snip ... cics specific wiki http://cicswiki.org/cicswiki1/index.php?title=History from above: CICS is born In 1968, CICS became available as a free, Type II Application Program, with users in every industry category. Transamerica in Los Angeles, Northern Indiana Public Service Company (NIPSCO), Colorado Public Service of Colorado, United Airlines, and many others were early adopters of the software known as CICS. The other accounts which had begun to develop their own approach (Commonwealth Edison, ConEd, etc) continued with their proprietary software. In 1969, IBM announced Program Products and CICS was no longer a free software offering. This did inhibit sales and customer acceptance. CICS enabled customers, in any industry, to quickly implement their online systems, most of which were inquiry only at that time. ... snip ... aka 23jun1969 ... "unbundling announcement" ... starting to charge for software, se services, maint. etc. misc. past posts mentioning unbundling http://www.garlic.com/~lynn/submain.html#unbundle this use to be an authoritative source for things CICS http://www.yelavich.com/ but it has gone 404 ... although it still lives on at the wayback machine http://web.archive.org/web/19990427231345/http://www.yelavich.com/ CICS Reference Information & Trivia http://web.archive.org/web/20010104201400/www.yelavich.com/5000fram.htm CICS-Related Announcements, 1968-Present http://web.archive.org/web/20010709064102/www.yelavich.com/5100cont.htm from above ... this claims available mid-69 (which better corresponds to my fading memory) ... as opposed to the above reference of availble in in 1968 P68-66 4/29/68 Three New Type II Programs on Information Systems to be Available Mid 1969 Overview - Generalized Information System (Basic) - Information Management System/360 - Public Utility Customer Information Control System Generalized Information System Basic (GIS) - Data set creation, maintenance, retrieval Information Management System/360 (IMS/360) - Implementation of medium to large data bases - Teleprocessing and conventional batch processing - Operate under MFT-II or MVT - Highlights - Messages to/from remote input/output devices - Aplications scheduled concurrently under unique storage protection key of OS/360 - System provides checkpoint/restart capabilities Public Utility Customer Information Control System - Planned availabilit
Re: C-I-C-S vs KICKS
That is what an ex-IBMer from the old days told me 'CICS' originally stood for - before it was renamed as 'Customer Information Control System' and sold to the rest of the world. I have no supporting evidence apart from this hearsay. zMan wrote: On Fri, Jul 23, 2010 at 10:21 PM, CM Poncelet wrote: Slight diversion ... but if CICS originally stood for 'Cincinnati Information Control System' should it not be pronounced SICS? Meanwhile it's developed at Hursley here in England and we pronounce it KICKS. ;-) Cheers, Chris Poncelet CA CM, are you suggesting that was the original name (a la "CMS" originally being "Cambridge Monitor System" rather than "Conversational")? I hadn't heard that one. The Google gets no hits, which doesn't prove or disprove it. I'm certainly not challenging you, just curious: do you have any supporting evidence? Or were you just being funny, and I'm taking this wy too seriously? -- 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: C-I-C-S vs KICKS
Slight diversion ... but if CICS originally stood for 'Cincinnati Information Control System' should it not be pronounced SICS? Meanwhile it's developed at Hursley here in England and we pronounce it KICKS. ;-) Cheers, Chris Poncelet CA john gilmore wrote: Agreeing with Ted O'Neill is not something I undertake to do lightly, but he is I think right about the provenance of these two pronunciations. In my experience United Statesians use the first and the rest of the world mostly uses the second. The notion that one is right and the other wrong is drôle. Spoken dialects differ about things that are indistinguishable in a written language. The spelling of the word 'laboratory' is, so far as I know, invariant in written English. In Canada and the UK I say lab-or-ah-tory; in the US I say lab-ri-tory; etc., etc. Surprise is of course possible. The first time, circa 1947, I heard a Scot say man-DATE-or-ee instead of man-duh-TORY for the word we both spelled 'mandatory' I was taken aback. The second time I heard it I recognized it for what it is, a wholly legitimate dialectal variant. As English become a world language the number of such variants is increasing very rapidly, and it is time for this to be more widely understood. Specifically, many American posters to this list exhibit far too much astonishment at departures from whaqt are, finally, provincial United Statesian usages. They need to read and travel more. John Gilmore Ashland, MA 01721-1817 USA _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_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 -- 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: SPF/pc, Gone???
Brian, The CTC website is http://www.commandtechnology.com. However their SPF/SE does not support REXX, or even numeric keyboard remapping. I mentioned that mainframe 3270 emulators (e.g. TN3270 Plus and QWS3270) do support keyboard remapping, but they replied they would not support this (i.e. unlike SPF/PC): Hello Chris, SPF/SE 6.0 Standard Edition is closest to the obsolete SPF/PC 4.x. All keyboard remapping supported by SPF/SE is found under OPTIONS, item KEYS: Standard Edition: PF1-->12 SHIFT+PF1-->12 CTRL-PF1-->12 ALT-PF1-->12 CTRL+A-->Z (some exceptions) ALT+A-->Z, 0-->9, some punctuation characters 3270-ENTER Graphic Edition: PF1-->12 SHIFT+PF1-->12 CTRL-PF1-->12 ALT-PF1-->12 CTRL+A-->Z (some exceptions) 3270-ENTER We have no plan to offer any further mapping support. Tim Tetiva CTC Support You can download a trial version of SPF/SE from their website if you want to check it out. Cheers, Chris Poncelet, CA Brian Kenny wrote: Recently I attempted to check in with Command Technology, authors of the SPF/pc product, only to find the web site had expired and the phone numbers in use by other companies/individual. It has been some years since I last purchased the product (rexx support), but I continued to check in yearly to see if new feature would entice me away from the old version. I did this as recently as late last year, and at that time saw no signs that they were about to pull the product. A search of the internet failed to turn up any recent web addresses, new owners or even recent conversations about the product. - Does anyone have any contact information? - Have any currently registered owners of SPF/SE heard anything from the company? So here I am, an MVS guy without SPF for my PC. Next thing you know it’ll be an end to ISAM, CVOLS and reel tapes. Where will it all end? -- 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: Cancel tso id
Fill in the details below (LPAR on which the user is logged on, userid of user to be cancelled etc., removing the '<>' but keeping the quotes - e.g. /*$VS,'CANCEL U=ABCDEFGH'), select either the /*ROUTE or the /*JOBPARM card but not both, and then submit the job. That should do it. // //* /*ROUTE XEQ <-- either /*JOBPARM SYSAFF=<4-char LPAR system ID> <-- or //* //* //* CANCEL A USER ON ANOTHER LPAR, IN BATCH * //* //INTRDR EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //SYSUT2DD SYSOUT=(*,INTRDR) //SYSUT1DD *,DLM=@@ /*$VS,'CANCEL U=cancelled>' @@ //* // Cheers, Chris Poncelet, CA Ron Thomas wrote: Hello. We are using SYSVIEW , many a times connections gets lost due to network problems and id gets locked. In SDSF we can purge the id from my my fellow's machine, here we need to call the helpdesk and do the same? is there any faclity here by which we can cancel the id? Thanks, Ron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Loop in REXX
Yes ... silly me: I wasn't thinking :-[ Thanks for noticing. do while \datatype(year,'N') | LENGTH(year) \= 4 SAY 'Invalid Date!!... enter year, using only 4 num digits' pull year end Cheers, Chris Poncelet Hunkeler Peter (KIUK 3) wrote: If you want to check that the user has entered a 4-digit year, you could code: do while \datatype(year,'N') & LENGTH(year) \= 4 SAY 'Invalid Date!!... enter year, using only 4 num digits' pull year end You could but it would not work as intended. You need to use the OR operator not the AND. -- Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Loop in REXX
"datatype(year,'N') " sets return code 1 if year is numeric, but sets
return code 0 if year is not numeric; "\" means NOT; so
"\datatype(year,'N')" is true (boolean = 1) when year is *not* numeric
and the DO WHILE loop then continues to execute until
"\datatype(year,'N')" is false (boolean = 0) ... which happens only when
year is numeric.
If you want to check that the user has entered a 4-digit year, you could
code:
do while \datatype(year,'N') & LENGTH(year) \= 4
SAY 'Invalid Date!!... enter year, using only 4 numeric digits'
pull year
end
Your 'pull answer' assigns 'S' or 'N' to function variable 'answer' -
but does not change the value of function variable 'year'.
To check if the user enters 'N', you could code:
if answer = "N" then do
SAY 'Bye bye '
Exit 0
END
without going back to the DO WHILE loop.
Cheers,
Chris Poncelet
CA
Claudio Marcio wrote:
Hi see my rexx exec
/* rexx by Claudio Marcio */
Say 'Enter with the year',
pull year
do while \datatype(year,'N')
SAY 'Invalid Date!!... enter year, using only numeric digits''
pull year
end
do until answer \= "S"
dec25 = date("B",year"1225","S")//7
select
when dec25 = 0 then day = "Segunda-feira"
when dec25 = 1 then day = "Terca-feira"
when dec25 = 2 then day = "Quarta-feira"
when dec25 = 3 then day = "Quinta-feira"
when dec25 = 4 then day = "Sexta-feira"
when dec25 = 5 then day = "Sabado"
when dec25 = 6 then day = "Domingo"
end
if year < right(date(),4) then
say 'In 'year', the Christmas was 'day
else
say 'In 'year', the Christmas will be 'day
say 'Want to learn some more years? (s/n)'
pull answer
if answer = "S" then
say 'Enter with another year!'
pull year---
> HERE TO UP it´s ok
do while \datatype(year,'N')
SAY 'Invalid Date!!... enter year, using only numeric digits'' ,
pull year
end
end
if answer = "N" then--> not be
enter to if when type answer equal the "N"???
do the program returns to the message of while command and
say 'Invalid answer BYE! BYE!'
when type the year( ex. 1970), he cancel ??? why??
leave
end
end more a question... how to verify the number of digits of the year??
end ex. If digits of thhe year less than 4
exit say 'Invalid Date!!... Invalid number of the digits'
regards
Bottom of Data *
if answer = "N" then
- Original Message - From: "Paul Gilmartin"
<[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To:
Sent: Thursday, October 23, 2008 12:10 PM
Subject: Re: Loop in REXX
On Thu, 23 Oct 2008 04:39:38 +0100, CM Poncelet wrote:
Try:
SAY 'Enter year'
PULL YEAR
DO WHILE \DATATYPE(YEAR,'N')
SAY 'Invalid date 'YEAR':' enter year, using only numeric digits'
PULL YEAR
END
SAY 'Year is 'YEAR /* this line is just to verify ... */
I loathe the top-and-bottom input style. The need for it is
a symptom of a deficiency of control structures in the language.
Would you code assembler this way? What could be done with
SPM?
Better:
SAY 'Enter year'
DO InputYear=1
PULL YEAR
IF DATATYPE(YEAR,'N') THEN LEAVE InputYear
SAY 'Invalid date 'YEAR':' enter year, using only numeric digits'
END InputYear
SAY 'Year is 'YEAR /* this line is just to verify ... */
Best to code a function to put the expression in the
loop control:
SAY 'Enter year'
DO InputYear=1 WHILE \GETYEAR()
SAY 'Invalid date 'YEAR':' enter year, using only numeric digits'
END InputYear
SAY 'Year is 'YEAR /* this line is just to verify ... */
...
GETYEAR PROCEDURE
PULL YEAR
RETURN DATATYPE(YEAR,'N')
Better languages allow a compound in the control expression
(not Rexx):
DO InputYear=1 WHILE (PULL YEAR; DATATYPE(YEAR,'N'))
...
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Loop in REXX
I retained the original 'structure' because the objective was to fix the REXX 'DO' loop problem ... without complicating things by also improving its 'design'. No, I would not write my own assembler (or any other) code this way. Cheers, Chris Poncelet CA Paul Gilmartin wrote: On Thu, 23 Oct 2008 04:39:38 +0100, CM Poncelet wrote: Try: SAY 'Enter year' PULL YEAR DO WHILE \DATATYPE(YEAR,'N') SAY 'Invalid date 'YEAR':' enter year, using only numeric digits' PULL YEAR END SAY 'Year is 'YEAR /* this line is just to verify ... */ I loathe the top-and-bottom input style. The need for it is a symptom of a deficiency of control structures in the language. Would you code assembler this way? What could be done with SPM? Better: SAY 'Enter year' DO InputYear=1 PULL YEAR IF DATATYPE(YEAR,'N') THEN LEAVE InputYear SAY 'Invalid date 'YEAR':' enter year, using only numeric digits' END InputYear SAY 'Year is 'YEAR /* this line is just to verify ... */ Best to code a function to put the expression in the loop control: SAY 'Enter year' DO InputYear=1 WHILE \GETYEAR() SAY 'Invalid date 'YEAR':' enter year, using only numeric digits' END InputYear SAY 'Year is 'YEAR /* this line is just to verify ... */ ... GETYEAR PROCEDURE PULL YEAR RETURN DATATYPE(YEAR,'N') Better languages allow a compound in the control expression (not Rexx): DO InputYear=1 WHILE (PULL YEAR; DATATYPE(YEAR,'N')) ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Loop in REXX
Try: SAY 'Enter year' PULL YEAR DO WHILE \DATATYPE(YEAR,'N') SAY 'Invalid date 'YEAR':' enter year, using only numeric digits' PULL YEAR END SAY 'Year is 'YEAR /* this line is just to verify ... */ Cheers, Chris Poncelet CA Claudio Marcio wrote: hi, how make a loop using the DO command in REXX? ex: Say ' enter wiith the year' pull year do until year (not numeric???) say ' invalid date, enter with the year' pull year end be right the command above? regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INLINE JCL PROC Question
Yes ... inline REXX/Clist can be done. But you then need to invoke an
initial REXX/Clist to read the inline code, build a member in a
SYSEXEC/SYSPROC PDS from the inline REXX/Clist data and finally call
your newly built REXX/Clist from your initially invoked REXX/Clist.
Here is an example (Clist %BTCHEDIT and for an inline edit macro):
PROC 2 DDNAME DSNAME DEBUG
/*---*/
/* BATCH CLIST */
/* ¯¯¯ */
/* CLIST TO ISSUE EDIT MACRO COMMANDS SUPPLIED VIA &DDNAME AGAINST */
/* A DATASET WHOSE NAME IS SUPPLIED VIA &DSNAME */
/* */
/* PARAMETERS:- */
/* */
/* - DDNAME : DDNAME OF DATASET CONTAINING INPUT EDIT MACRO COMMANDS */
/*FOR EDITING DATASET &DSNAME*/
/* - DSNAME : THE DATASET TO BE EDITED */
/* */
/* FLOW LOGIC:- */
/* */
/* - THE CLIST READS, PROCESSES AND STORES ALL CARDS REFERENCED BY */
/* DDNAME=&DDNAME IN THE JCL. */
/* - BY DEFAULT, THE CLIST STORES THE CARDS IT HAS PROCESSED (AS AN */
/* INVOCABLE EDIT MACRO) IN DATASET '@@.ISPCLIB(BMACRO)'. */
/* - WHEN IT HAS PROCESSED AND STORED ALL ITS CARDS, IT INVOKES */
/* THE EDIT MACRO IT CREATED TO EDIT THE DATASET REFERENCED BY */
/* &DSNAME.*/
/* */
/* PROCESS LOGIC:- */
/* ¯¯¯ */
/* - IF THERE ARE ANY CARDS TO BE PROCESSED, THE CLIST CREATES ITS */
/* OWN 'ISREDIT MACRO' CARD BEFORE PROCESSING EACH CARD IT READS. */
/* - THE CLIST THEN APPENDS THE 'ISREDIT' STATEMENT TO THE BEGINNING */
/* OF EACH CARD IT READS IN. */
/* - WHEN ALL CARDS HAVE BEEN READ AND PROCESSED, THE CLIST ADDS */
/* THE REQUIRED CLOSING CARDS TO COMPLETE THE EDIT MACRO. */
/* - THE CLIST THEN INVOKES THE EDIT MACRO WHICH IT HAS JUST CREATED */
/* TO EDIT THE DATASET PASSED VIA &DSNAME. */
/* */
/* */
/* 08/02/96 CMP */
/*---*/
CONTROL: +
CONTROL MAIN END(ENDO)
IF &DEBUG = DEBUG | &DEBUG = D THEN +
CONTROL LIST SYMLIST CONLIST MSG
ELSE +
CONTROL NOLIST NOSYMLIST NOCONLIST NOMSG
INITS: +
SET DMACRO = '@@.ISPCLIB(BMACRO)' /* DEFAULT */
ALLOCS: +
ALLOC FILE(BMACRO) DSNAME(&DMACRO) SHR KEEP
IF &MAXCC > 0 THEN +
DO
WRITE ERROR ALLOCATING DATASET &DMACRO: RC = &MAXCC
GOTO EXIT
ENDO
OPENFILE BMACRO OUTPUT
IF &MAXCC > 0 THEN +
DO
WRITE ERROR OPENING DATASET &DMACRO FOR OUTPUT : RC = &MAXCC
FREE FI(BMACRO)
GOTO EXIT
ENDO
PROCESS: +
SET REC = &&&DDNAME
OPENFILE &DDNAME INPUT
GETFILE &DDNAME
SET RC = &LASTCC
IF &RC > 0 THEN +
DO
WRITE ERROR READING DDNAME = &DDNAME : RC = &RC
GOTO EXIT
ENDO
CONTINUE: +
SET BMACRO = &STR(ISREDIT MACRO)
PUTFILE BMACRO
SET BMACRO = &STR(CONTROL LIST SYMLIST CONLIST MSG)
PUTFILE BMACRO
SET BMACRO = &STR(SET SYSSCAN = 1)
PUTFILE BMACRO
ERROR RETURN
SET SYSSCAN = 3
DO WHILE &MAXCC = 0
SET BMACRO = &SUBSTR(1:80,ISREDIT &REC)
PUTFILE BMACRO
GETFILE &DDNAME
ENDO
IF &MAXCC = 400 THEN SET MAXCC = 0
CLOSFILE &DDNAME
SET BMACRO = &STR(ISREDIT END)
PUTFILE BMACRO
SET BMACRO = &STR(ISREDIT MEND)
PUTFILE BMACRO
SET SYSSCAN = 1
SET BMACRO = &STR(EXIT CODE(&&LASTCC))
PUTFILE BMACRO
CLOSFILE BMACRO
FREE FI(BMACRO)
EDIT_STAGE2: +
ISPEXEC EDIT DATASET('&DSNAME') MACRO(BMACRO)
EXIT: +
EXIT CODE (&MAXCC)
and here is example JCL to invoke something similar (actually for
another Clist, which interprets '.' in column 1 to mean the line should
be read/written asis instead of converted to an edit macro one. But
%BTCHEDIN calls another Clist (to extract the DSN associated with DDNAME
parm 'DSNAME'), which makes the complete 'bundle/package' too long to
publish. Let me know offline if you need the whole works):
//*
//* EXECUTE A CLIST IN BATCH *
//* *
Re: RES: Counting occurrences of a string in loadlib
Have you considered: (a) IEBCOPYing both your load libraries to flat files (b) Reading/reblocking both flat files into separate RECFM=FBS,LRECL=4160,BLKSIZE=4160 IPCS-readable files - via a program which will do this (c) Finding the number of strings in the IPCS-readable files under IPCS - either by doing a "FIND ALL NOBREAK", if that works (can't remember), or by counting the strings one-at-a-time in a loop until EOD via some IPCS REXX? That might work, if all else fails. Cheers, CP Ira Broussard wrote: I have given up on the idea of doing this via an IBM utility or ISPF function (like SEARCH FOR). Instead, I'm playing around with a REXX EXEC using ISPF services that will do the following... 1. Build a list containing the names of each of the modules in the "old" load library. 2. Read each module, record by record, into a single REXX variable string so I end up with one large string that contains the entire module. 3. Scan the resulting data string looking for the character string I'm interested in and count the number of occurrences of the string. 4. Repeat 2 and 3 for each module in the load library. 5. Repeat 1 thru 4 for the "new" load library. 6. Display totals. Initial tests suggest this will work, but I haven't thought about all of the possibilities. Note that an occasional "false negative" (reporting that the load libraries contain different numbers of occurrences of the string when they really have the same "count") is much more acceptable than a "false positive" (reporting that the load libraries contain the same number of occurrences when they really don't). Comments? Thanks, Ira In a message dated 4/27/2007 11:45:27 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Tom Marchant wrote: On Fri, 27 Apr 2007 11:01:13 -0400, John Eells <[EMAIL PROTECTED]> wrote: Tom Marchant wrote: On Fri, 27 Apr 2007 10:14:55 -0300, ITURIEL DO NASCIMENTO NETO <[EMAIL PROTECTED]> wrote: Ira, Try copying one of these PDSs (IEBCOPY - COPYMOD) to a new one with the other blksize, and then proceed with your compare step. Still might not work. Unless you can guarantee that each member starts at the same location on a track, you will likely have blocks in one PDS that are different sizes than the blocks in the other. If a large load module starts on a new track, you'll have a 32K block at the beginning of the track, then a shorter block at the end. If the same load moule starts after a member that ends with a 32K block at the beginning of a track, it will start with a smaller block, then have a 32K block at the beginning of the next track. Well...this ain't easy. Each member must start on a new track, because directory entries use TTR pointers to PDS members. See (watch for wrap): Not true. The TTR points to the track and record number where the member starts. I just looked at one of my load libraries that has 27 members and is using 19 tracks. This would be impossible if each member had to start on a new track. It would also be very inefficient. SYS1.LINKLIB on one system here has 3725 members and is using 70% of 3318 tracks. SYS1.LPALIB has 1695 members and is using 79% of 909 tracks. Doh! That's what the "R" stands for, of course. You're completely right. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Printing ISPF Display from a Clist
Copy the original Clist to your own library (concatenated ahead of the BMC one), then edit your Clist and add some code (EXECIO, OUTTRAP, CALL IEBGENER or whatever works) to copy member X37PARMS to one of your datasets/members, and then print it from there. You should be able to access the original member X37PARMS from within your Clist. CP Eric Bielefeld wrote: We have the StopX37/II product from BMC. There is a clist that comes with the product that displays all of the parameters in effect, and puts it in to a nice 80 column display. I've been trying to figure out how to print this list, so I can compare my old release with the new release. The display is about 800 lines long. The ISPF display is in a browse session with the dsname of the parmlib dataset for StopX37. It shows a member name of X37PARMS, but there is no member with that name in the parmlib dataset. I tried ISRDDN, and looked at all the DDs allocated. I see one DD called DISPX37L, which is allocated in the Clist, but ISRDDN doesn't allow me to browse the file. Can anyone help me in figuring out a way to print this? Eric Bielefeld Sr. Systems Programmer Lands End 608-935-4680 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: edit macro that won't
Bob,
I've quick-written and checked that the following works OK.
(Apologies if the JCL, REXX etc. source have been "reformatted" by Big
D. ;-) )
JCL:
//CALLMACR EXEC PGM=IKJEFT01,
// REGION=8192K,
// DYNAMNBR=25
//*
//SYSTSIN DD *
ISPSTART CMD(%CALLMACR CONVUPPR TTSMV14.TEST MAKEUC)
/*
//SYSEXEC DD DISP=SHR,DSN=TTSMV14.REXX
//ISPLOGDD SYSOUT=*,DCB=(RECFM=VBA,LRECL=125,BLKSIZE=129)
//ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU
//ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU
//ISPPROF DD SPACE=(TRK,(2,1,5)),DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120)
//ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU
//ISPTABL DD DUMMY
//ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU
//SYSHELP DD DISP=SHR,DSN=SYS2.HELP
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//*
CALLMACR: REXX to invoke an edit macro:
/*---*/
/* REXX TO INVOKE AN EDIT MACRO 'MACRO' AGAINST DSN='DATASET', IN*/
/* BATCH TSO */
/* */
/* 03/03/06 CMP */
/*---*/
ARG MACRO DATASET TRACE
IF ABBREV('DEBUG',TRACE,1) THEN TRACE INTERMEDIATE
"ISPEXEC VPUT TRACE SHARED"
PROCESS:
"ISPEXEC EDIT DATASET('"DATASET"') MACRO("MACRO")"
EXIT:
EXIT 0
CONVUPPR: REXX Edit macro to change all lowercase to uppercase:
"ISREDIT MACRO"
ARG TRACE
"ISPEXEC VGET TRACE"
IF ABBREV('DEBUG',TRACE,1) THEN TRACE INTERMEDIATE
"ISREDIT CHANGE ALL P'<' P'>'"
"ISREDIT SAVE"
"ISREDIT END"
EXIT 0
Cheers - Chris
Bob H wrote:
Chris - will give your suggestion a try.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: edit macro that won't
Readable version :-)
You need to write an intermediate REXX or CLIST proc - say CALLMACR -
which issues an "ISPEXEC EDIT DATASET('TTSMV14.TEST MAKEUC')
MACRO(EDITREXX)". Then invoke CALLMACR instead of EDITREXX in your batch
job.
e.g.
TSO Clist:
PROC 2 MACRO DATASET DEBUG
/*---*/
/* CLIST TO INVOKE AN EDIT MACRO &MACRO AGAINST DSN=&DATASET, IN */
/* BATCH TSO */
/* */
/* 20/12/95 CMP */
/*---*/
CONTROL: +
CONTROL MAIN END(ENDO)
IF &DEBUG = DEBUG | &DEBUG = D THEN +
CONTROL LIST SYMLIST CONLIST MSG
ELSE +
CONTROL NOLIST NOSYMLIST NOCONLIST NOMSG
ISPEXEC VPUT (DEBUG) SHARED
PROCESS: +
ISPEXEC EDIT DATASET('&DATASET') MACRO(&MACRO)
EXIT: +
EXIT CODE (&MAXCC)
Batch TSO job:
//CALLMACR EXEC PGM=IKJEFT01,
// REGION=8192K,
// DYNAMNBR=25
//*
//SYSTSIN DD *
ISPSTART CMD(%CALLMACR EDITREXX TTSMV14.TEST MAKEUC)
/*
//SYSEXEC DD etc.
//SYSPROC DD etc.
Regards,
Chris Poncelet
Software Engineer
CA
Bob H wrote:
Hi Folks,
I had a guy ask me for a way convert a flat file from mixed to uppercase
only, in place, in batch.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: edit macro that won't
You need to write an intermediate REXX or CLIST proc - say CALLMACR -
which issues an "ISPEXEC EDIT DATASET('TTSMV14.TEST MAKEUC')
MACRO(EDITREXX)". Then invoke CALLMACR instead of EDITREXX in your batch
job.
e.g.
TSO Clist:
PROC 2 MACRO DATASET DEBUG
/*---*/
/* CLIST TO INVOKE AN EDIT MACRO &MACRO AGAINST DSN=&DATASET, IN */
/* BATCH TSO */
/* */
/* 20/12/95 CMP */
/*---*/
CONTROL: +
CONTROL MAIN END(ENDO)
IF &DEBUG = DEBUG | &DEBUG = D THEN +
CONTROL LIST SYMLIST CONLIST MSG
ELSE +
CONTROL NOLIST NOSYMLIST NOCONLIST NOMSG
ISPEXEC VPUT (DEBUG) SHARED
PROCESS: +
ISPEXEC EDIT DATASET('&DATASET') MACRO(&MACRO)
EXIT: +
EXIT CODE (&MAXCC)
Batch TSO job:
//CALLMACR EXEC PGM=IKJEFT01,
// REGION=8192K,
// DYNAMNBR=25
//*
//SYSTSIN DD *
ISPSTART CMD(%CALLMACR EDITREXX TTSMV14.TEST MAKEUC)
/*
//SYSEXEC DD etc.
//SYSPROC DD etc.
Regards,
Chris Poncelet
Software Engineer
CA
Bob H wrote:
Hi Folks,
I had a guy ask me for a way convert a flat file from mixed to uppercase
only, in place, in batch.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COND= on an EXEC Statement
... and specify: //COND4A EXEC PGM=IEFBR14,COND=(0,NE) if you want to flush PROC2 for any PROC1 COND code GT 0 - including e.g. CC=01 ... Cheers - CP CM Poncelet wrote: To avoid overriding the COND='s in PROC2, specify the following: //STEP1 EXEC PROC1 //* //COND4A EXEC PGM=IEFBR14,COND=(4,LE) //COND4B EXEC PGM=IEFBR14,COND=(0,EQ,COND4A) //* //STEP2 EXEC PROC2,COND=(0,EQ,COND4B) Regards, Chris Poncelet Software Engineer CA Dean Montevago wrote: Hi, I'm looking at the JCL manual and I'm not clear as to what's written on this topic. If I have the following: //STEP1 EXEC PROC1 //* //STEP2 EXEC PROC2 Proc 2 contains multiple steps with COND='s on the EXEC steps. If I add a COND=(0,NE) to the statement that calls PROC2 will this override the COND='s on the individual steps in PROC2 ? Basically what I want to do is flush the job if the first proc doesn't complete with a condition code of zero. TIA Dean Dean Montevago Sr. Systems Specialist Visiting Nurse Service of New York (212) 609 - 5596 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COND= on an EXEC Statement
To avoid overriding the COND='s in PROC2, specify the following: //STEP1 EXEC PROC1 //* //COND4A EXEC PGM=IEFBR14,COND=(4,LE) //COND4B EXEC PGM=IEFBR14,COND=(0,EQ,COND4A) //* //STEP2 EXEC PROC2,COND=(0,EQ,COND4B) Regards, Chris Poncelet Software Engineer CA Dean Montevago wrote: Hi, I'm looking at the JCL manual and I'm not clear as to what's written on this topic. If I have the following: //STEP1 EXEC PROC1 //* //STEP2 EXEC PROC2 Proc 2 contains multiple steps with COND='s on the EXEC steps. If I add a COND=(0,NE) to the statement that calls PROC2 will this override the COND='s on the individual steps in PROC2 ? Basically what I want to do is flush the job if the first proc doesn't complete with a condition code of zero. TIA Dean Dean Montevago Sr. Systems Specialist Visiting Nurse Service of New York (212) 609 - 5596 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PREVENTING TAKING TOO MUCH STOR IN ISPF
If it helps, look at the small print in *.SISPPENU(ISREDDE) and then set
PANELID ON to see which panels are loaded into VS. Then alias ISREDDE as
ISREDDE2/3/4/5.
As for BROWSE, issue ISPEXEC BROWSE DATASET('&DSN'), with your choice of
&DSN via Clist or REXX - or copy/concat-ahead [EMAIL PROTECTED] on DDNAME=ISPPLIB
(in your PDS) and change it to use BROWSE instead of VIEW.
Cheers. CP
Martin Kline wrote:
But, are you so memory constrained that this is an issue?
Some users may need more than your arbitrary limit to do their job.
Some/most may not. Set the size limit to a reasonable number. Then, let
each user justify the requirement for more. Unjustified users shouldn't be
allowed to open huge files in edit/view mode. Too many such users can bring
even a system with "lots" of real storage to its knees.
CONFIDENTIALITY NOTICE: This electronic transmission (including any
accompanying attachments) is intended solely for its authorized
recipient(s), and may contain confidential and/or legally privileged
information. If you are not an intended recipient, or responsible for
delivering some or all of this transmission to an intended recipient, be
aware that any review, copying, printing, distribution, use or disclosure of
the contents of this message is strictly prohibited. If you have received
this electronic message in error, please contact us immediately by
electronic mail at [EMAIL PROTECTED] or notify us
immediately by telephone at 1-800-345-2021 or 816-531-5575 and destroy the
original and all copies of this transmission (including any attachments).
Thank you.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
