Re: action in UK33496
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, April 29, 2008 1:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: action in UK33496 snip However, I had a friend at another shop do this. He got a royal dressing down by the lead sysprog because he (the sysprog) had decided that the S0C3 abend was his alone and had placed a SLIP in COMMNDnn to take SVC dumps on every S0C3 to debug __his__ programs. And didn't document it because? He was a donkey's rear-end? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: action in UK33496
In [EMAIL PROTECTED], on 04/21/2008 at 11:15 AM, Paul Gilmartin [EMAIL PROTECTED] said: Every well-designed language, application, programming system should have a way to force an error. IDCAMS has such; HLASM has MNOTE; zSeries has x'00'. No; a program check with PIC 1 might not be an error, and I've seen code that uses it as a normal event. Rexx lacks such; Are you a betting man? I resort to dividing by zero or accessing an uninitialized variable to force an error. Aren't you contradicting yourself? If you've discovered two ways to force an error then there is a way. BTW, why not use SIGNAL? As a courtesy, the vendor should partition the name space and commit to leaving some fraction available for user-defined macros and promising that no new OP code or macro will intrude on the space ceded to users. I'd like that. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: action in UK33496
In [EMAIL PROTECTED], on 04/21/2008 at 11:30 AM, McKown, John [EMAIL PROTECTED] said: I would, sort of, like HLASM to implement namespaces. My idea would be something along the lines of it working like it does today, with one addition. Where you can currently place either a macro name (opcode field), or as part of the parameter (member name) of the COPY, be able to specify a DD name which is used instead of SYSLIB to resolve the macro or copy statement. Eg COPYCALIB:MSG or CALIB:MSG 'THIS IS A MESSAGE FROM A CA PRODUCT',other parms I'd like name spaces, but I wouldn't want them syntactically tied to ddnames. I'd prefer some sort of qualified names, with pseudo-ops to establish default qualifications. IBMAP had a nice facility, except that it didn't extend to macro or op code names. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: action in UK33496
In [EMAIL PROTECTED], on 04/21/2008 at 07:56 AM, McKown, John [EMAIL PROTECTED] said: IIRC, IBM has stated that an opcode of x'00' will __never__ be valid and will __always__ produce a program check interrupt code 1 (S0C1 in MVS-speak). S0C1 is S0C1 in MVS speak; program check interrupt code 1 is not. There's lots of code that would break if it got an ABEND when it was expecting a program check. However, I had a friend at another shop do this. He got a royal dressing down by the lead sysprog because he (the sysprog) had decided that the S0C3 abend was his alone and had placed a SLIP in COMMNDnn to take SVC dumps on every S0C3 to debug __his__ programs. And didn't document it because? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: action in UK33496
On Mon, 21 Apr 2008 11:30:57 -0500, McKown, John wrote: A well designed language would not just have comments, but would enforce comments. Of course, the most excellent language would understand the comments themselves and that would actually be the code! Nerd-vana. DEK has a similar idea: URL: http://infohost.nmt.edu/~al/Literate-programming/draft/knuth-web.html As a courtesy, the vendor should partition the name space and commit to leaving some fraction available for user-defined macros I do not really care for component prefixes. What about my macros? What if some vendor duplicates my name? That's why IBM maintains a registry. I would, sort of, like HLASM to implement namespaces. My idea would be something along the lines of it working like it does today, with one addition. Where you can currently place either a macro name (opcode field), or as part of the parameter (member name) of the COPY, be able to specify a DD name which is used instead of SYSLIB to resolve the macro or copy statement. Eg I like it; is it on John Ehrman's wishlist? -- 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
Re: action in UK33496
At 11:15 -0500 on 04/21/2008, Paul Gilmartin wrote about Re: action in UK33496: As a courtesy, the vendor should partition the name space and commit to leaving some fraction available for user-defined macros and promising that no new OP code or macro will intrude on the space ceded to users. IBM has violated this Allocated for Customer Use rule at times. One case is that SVC numbers 200-255 are designate for Customer (ie: Non-IBM-MVS supplied) use and ABEND Code SXYY is designed as ABEND number X (X=0-E) from SVC YY. The problem is that IBM has violated this For Customer Use set aside by grabbing some SXYY codes (Aside from the valid SFYY that says SVC YY is undefined) for its own use so that you must KNOW of this invalid grabbing and either not define a User-SVC-YY that intersects such an ABEND Code or at a minimum not use the X codes of these IBM Squatting ABEND Codes so that a Vendor Supplied (or User Written) User SVCs do not issue an ABEND code that can be mistaken for the IBM issued one. -- 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: action in UK33496
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patrick O'Keefe Sent: Sunday, April 20, 2008 10:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: action in UK33496 On Sun, 20 Apr 2008 18:11:45 -0700, Skip Robinson [EMAIL PROTECTED] wrote: ... There was a note of caution that I found almost funny: the new OP code would not cause a problem for any program *unless* that program were depending on the OP code *not* to be valid. Where's my S0C1? I need my S0C1! After all these years in the business, I would not bet the farm on there being no such program. ... I remember seeing such a program sometime within the last 15 years. I don't remember what character string used to create the S0C1, but I remember thinking that some day it would be a valid opcode and there was going to be some very unanticipated behavior in that program. Sheesh! Everybody knows you're supposed to EX and EX in such circumstances, not execute some clever word. You need a more intuitive, self-explanatory abend like S0C3 to aid your debugging. :-) Pat O'Keefe IIRC, IBM has stated that an opcode of x'00' will __never__ be valid and will __always__ produce a program check interrupt code 1 (S0C1 in MVS-speak). I always use the S0C3 method as it is guaranteed by the Principles of Operation to do this. However, I had a friend at another shop do this. He got a royal dressing down by the lead sysprog because he (the sysprog) had decided that the S0C3 abend was his alone and had placed a SLIP in COMMNDnn to take SVC dumps on every S0C3 to debug __his__ programs. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: action in UK33496
Patrick O'Keefe wrote: Sheesh! Everybody knows you're supposed to EX and EX in such circumstances, not execute some clever word. You need a more intuitive, self-explanatory abend like S0C3 to aid your debugging. :-) I've remember some old code that used: EX 0,* to force a logic error abend. Such specification no longer compile in the immediate relative world. These days we use: J *+2 -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: action in UK33496
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Monday, April 21, 2008 9:46 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: action in UK33496 Patrick O'Keefe wrote: Sheesh! Everybody knows you're supposed to EX and EX in such circumstances, not execute some clever word. You need a more intuitive, self-explanatory abend like S0C3 to aid your debugging. :-) I've remember some old code that used: EX 0,* to force a logic error abend. Such specification no longer compile in the immediate relative world. These days we use: J *+2 -- Edward E Jaffe Yea, I just changed a module to be baseless. I had to include an EX 0,* in the constants area. Since I didn't want the S0C3 abend to always be from that address, I had to put an EX in the code section which referenced the EX in the constants section. That works OK. I could have jumped to the constants section, then looked at the BEAR register to tell where I came from, but I thought my way was a bit easier to debug. Why use J *+2 ? It assembles to A7F4 0001, which would jump to the 0001 portion of the instruction. Why not just hard code a H'0'? Do you have some fancy debugger which detects this particular sequence by saying something like: If the abend is a S0C1, and the opcode is x'00' followed by a x'01' and the BEA register points 2 bytes before the abend address, then report a deliberate abend.? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: action in UK33496
McKown, John wrote: IIRC, IBM has stated that an opcode of x'00' will __never__ be valid and will __always__ produce a program check interrupt code 1 (S0C1 in MVS-speak). A Few years back I would have disagreed with you.. The ESA/390 POO states (6.5.2.24, programing note 2 of SA22-7201-04) : //The operation code 00, with a two-byte instruction format, currently is not assigned. It is improbable that this operation code will ever be assigned.// (so it was not __never__ and __always__ !) But they changed the wording now (and for a pedant like me, the meaning) : The z/Architecture POO States (Page 6-27, left col, Programming note 2 of Operation Exception Program Interrupt of SA22-7832-06) : //Operation code 00 hex will never be assigned to an instruction implemented in the CPU.// So after 40+ years - they finally made up their mind ! --Ivan -- 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: action in UK33496
McKown, John wrote: Why use J *+2 ? It assembles to A7F4 0001, which would jump to the 0001 portion of the instruction. Why not just hard code a H'0'? Do you have some fancy debugger which detects this particular sequence by saying something like: If the abend is a S0C1, and the opcode is x'00' followed by a x'01' and the BEA register points 2 bytes before the abend address, then report a deliberate abend.? Jumps can be conditional. DC H'0', EX of EX, and all similar techniques are messy because you must always branch *around* the code to force the abend. For example: CLI 0(R1),C'A' Value too low? JNL LABEL1 Branch if not DCH'0'Force logic error abend LABEL1 DC 0H CLI 0(R1),C'9' Value too high? JNH LABEL2 Branch if not DCH'0'Force logic error abend LABEL2 DC 0H vs the very simple ... CLI 0(R1),C'A' Value too low? JL*+2 Force logic error abend CLI 0(R1),C'9' Value too high? JH*+2 Force logic error abend -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: action in UK33496
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Monday, April 21, 2008 10:15 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: action in UK33496 McKown, John wrote: Why use J *+2 ? It assembles to A7F4 0001, which would jump to the 0001 portion of the instruction. Why not just hard code a H'0'? Do you have some fancy debugger which detects this particular sequence by saying something like: If the abend is a S0C1, and the opcode is x'00' followed by a x'01' and the BEA register points 2 bytes before the abend address, then report a deliberate abend.? Jumps can be conditional. DC H'0', EX of EX, and all similar techniques are messy because you must always branch *around* the code to force the abend. For example: CLI 0(R1),C'A' Value too low? JNL LABEL1 Branch if not DCH'0'Force logic error abend LABEL1 DC 0H CLI 0(R1),C'9' Value too high? JNH LABEL2 Branch if not DCH'0'Force logic error abend LABEL2 DC 0H vs the very simple ... CLI 0(R1),C'A' Value too low? JL*+2 Force logic error abend CLI 0(R1),C'9' Value too high? JH*+2 Force logic error abend -- Edward E Jaffe Ah. Now that is __CLEVER__! I may adopt it myself. In fact, time to rewrite the code that I was rewriting! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: action in UK33496
---snip I always use the S0C3 method as it is guaranteed by the Principles of Operation to do this. However, I had a friend at another shop do this. He got a royal dressing down by the lead sysprog because he (the sysprog) had decided that the S0C3 abend was his alone and had placed a SLIP in COMMNDnn to take SVC dumps on every S0C3 to debug __his__ programs. ---unsnip-- Any respect I might have had for that lead guy just took a serious nosedive. I also use a S0C3 abend as a trigger for my debuggers, coupled with a SPIE/ESPIE exit that uses a funky parm list. What I'd REALLY like to see is a user-controllable intercept for a Monitor Call instruction, like GTF uses (or at least used to use.) -- 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: action in UK33496
On Sun, 20 Apr 2008 18:11:45 -0700, Skip Robinson wrote: I remember back when a very fundamental utility changed to SDB by default. I believe it was IEBGENER itself. If we had HOLDDATA back then, I'm not sure how big a deal we made of it. In any case, one major application had an 'outage' because a particular job step had been counting on the historic default where output blocksize was equal to input blocksize. Their master file was required to be a certain blocksize. For years the offending utility step copied the file without specifying blocksize. Suddenly with SDB the output changed, and subsequent steps failed. Silly application designer. A well designed application should not be sensitive to blocksize, simply because it should be designed to accommodate future changes in device geometries. IEBGENER changed to SDB by default and subsequently (or immediately) grew a PARM to override the behavior. I believe later the design changed to make the historic behavior the default. I'm torn on this one. Much as I admire SDB, I respect the intent of a copy program to replicate all attributes of the input data. OTOH, it ought to support optimal copying to a different device type. The final solution should be FBA, where block size becomes irrelevant. Or something like PDSE's protean treatment of BLKSIZE: on input it can be anything the programmer codes in the DCB. I once had to explain to the author of a very silly CLIST why it suddenly failed to enter an expected (!) ERROR routine because underscore was no longer invalid in labels. I didn't feel very guilty about that one. What a dope. Every well-designed language, application, programming system should have a way to force an error. IDCAMS has such; HLASM has MNOTE; zSeries has x'00'. Rexx lacks such; I resort to dividing by zero or accessing an uninitialized variable to force an error. Also, every well-designed language should have: o Comments o A no-op. I remember reading about a new OP code being introduced on a processor. There was a note of caution that I found almost funny: the new OP code would not cause a problem for any program *unless* that program were depending on the OP code *not* to be valid. Where's my S0C1? I need my S0C1! After all these years in the business, I would not bet the farm on there being no such program. This more likely happens with new OP codes overloading user-defined macro names. As a courtesy, the vendor should partition the name space and commit to leaving some fraction available for user-defined macros and promising that no new OP code or macro will intrude on the space ceded to users. The component prefix registry could be used for this, and also to mitigate contention between ISVs. The statement should be that no new OP code or macro name will ever overlap a registered component prefix. -- 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
Re: action in UK33496
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, April 21, 2008 11:15 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: action in UK33496 [snip] Every well-designed language, application, programming system should have a way to force an error. IDCAMS has such; HLASM has MNOTE; zSeries has x'00'. Rexx lacks such; I resort to dividing by zero or accessing an uninitialized variable to force an error. Also, every well-designed language should have: o Comments A well designed language would not just have comments, but would enforce comments. Of course, the most excellent language would understand the comments themselves and that would actually be the code! Nerd-vana. o A no-op. [snip] This more likely happens with new OP codes overloading user-defined macro names. As a courtesy, the vendor should partition the name space and commit to leaving some fraction available for user-defined macros and promising that no new OP code or macro will intrude on the space ceded to users. The component prefix registry could be used for this, and also to mitigate contention between ISVs. The statement should be that no new OP code or macro name will ever overlap a registered component prefix. -- gil I do not really care for component prefixes. What about my macros? What if some vendor duplicates my name? I would, sort of, like HLASM to implement namespaces. My idea would be something along the lines of it working like it does today, with one addition. Where you can currently place either a macro name (opcode field), or as part of the parameter (member name) of the COPY, be able to specify a DD name which is used instead of SYSLIB to resolve the macro or copy statement. Eg COPYCALIB:MSG or CALIB:MSG 'THIS IS A MESSAGE FROM A CA PRODUCT',other parms -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: action in UK33496
Since the blocksize that would have been used before this PTF was not the System Defined Blocksize, then some installations may have already adjusted their procedures to be compatible with the previous incorrect behaviour. They may now need to take some action to deal with the change in behaviour introduced by this PTF. In other cases, similar (or even more drastic) changes are classified as documentation change which can cause grief when people assume that applying those PTFs will not require changes to existing production applications. Also, the information contained on the HOLD may not always be sufficient to understand all the implications of applying the maintenance and it may sometimes be necessary to examine the APAR/PTF text. Bill On Sat, 19 Apr 2008 21:12:13 +0200, R.S. [EMAIL PROTECTED] wrote: HOLD(UK33496) SYS FMID(HCI6500) REASON(ACTION) DATE(08037) COMMENT (If the SYSPRINT file is being written to a data set, please note that a System Defined Blocksize will be allocated if no BLKSIZE is defined or a BLKSIZE of 0 is defined on the DD card. My humble questions: 1. Is it really ACTION to perform ? 2. Isn't the behaviour obvious and expected ? If yes, then why to mention it under any HOLD type ? 3. Is it funny ? I also found ACTION which was ...documentation change (in other PTF). -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl S±d Rejonowy dla m. st. Warszawy XII Wydzia³ Gospodarczy Krajowego Rejestru S±dowego, nr rejestru przedsiêbiorców KRS 025237 NIP: 526-021-50-88 Wed³ug stanu na dzieñ 01.01.2008 r. kapita³ zak³adowy BRE Banku SA wynosi 118.642.672 z³ote i zosta³ w ca³o¶ci wp³acony. -- 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: action in UK33496
Programs can write to SYSPRINT as long as the blksize is compatible with LRECL so if an installation previoulsy hardcoded a valid blksize instead of using a system determined blksize then no action is required. This is one of those annoying actions we spend too much time researching only to learn we can ignore it. It is a shame when one IBMer could not put sufficient information in the HOLD data causing thousands of us to go hunt down the APAR. On Sun, 20 Apr 2008 05:00:13 -0500, Big Iron [EMAIL PROTECTED] wrote: Since the blocksize that would have been used before this PTF was not the System Defined Blocksize, then some installations may have already adjusted their procedures to be compatible with the previous incorrect behaviour. They may now need to take some action to deal with the change in behaviour introduced by this PTF. In other cases, similar (or even more drastic) changes are classified as documentation change which can cause grief when people assume that applying those PTFs will not require changes to existing production applications. Also, the information contained on the HOLD may not always be sufficient to understand all the implications of applying the maintenance and it may sometimes be necessary to examine the APAR/PTF text. Bill On Sat, 19 Apr 2008 21:12:13 +0200, R.S. [EMAIL PROTECTED] wrote: HOLD(UK33496) SYS FMID(HCI6500) REASON(ACTION) DATE(08037) COMMENT (If the SYSPRINT file is being written to a data set, please note that a System Defined Blocksize will be allocated if no BLKSIZE is defined or a BLKSIZE of 0 is defined on the DD card. My humble questions: 1. Is it really ACTION to perform ? 2. Isn't the behaviour obvious and expected ? If yes, then why to mention it under any HOLD type ? 3. Is it funny ? I also found ACTION which was ...documentation change (in other PTF). -- Radoslaw Skorupka Lodz, Poland -- -- 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: action in UK33496
On Sun, 20 Apr 2008 09:51:55 -0500, Kenneth E Tomiak wrote: Programs can write to SYSPRINT as long as the blksize is compatible with LRECL so if an installation previoulsy hardcoded a valid blksize instead of using a system determined blksize then no action is required. This is one of those annoying actions we spend too much time researching only to learn we can ignore it. It is a shame when one IBMer could not put sufficient information in the HOLD data causing thousands of us to go hunt down the APAR. Several years ago, I was hit by something similar. In Rexx, I had done: RC = BPXWDYN( 'allocate dd(SYSPRINT) recfm(V,B) lrecl(137) path(...)...' ) ... omitting BLKSIZE. I always assume the OS knows best. In fact, it was not the OS, but a subsequent EXECIO that set a usable BLKSIZE. But a customer rightly reported that EXECIO was thwarting the proper operation of SDB (as in PK59467/UK33496), so IBM removed the setting of BLKSIZE from EXECIO. So, what did SDB select for a subsystem data set with recfm(V,B) lrecl(137)? 80! IBM recommended that I specify BLKSIZE at allocation; an ironic consequence of SDB. SDB has been fixed by APAR (although) IBM support cautioned me that the value of 80 was documented, and if another customer complained they'd be required to break it again. It's regrettable that a rudimentary SDB was not present in OS/360 from the beginning. It's a good enhancement, and customers should adopt the habit of relying on it, or reporting its unreliability. The OS knows best. -- 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
Re: action in UK33496
I remember back when a very fundamental utility changed to SDB by default. I believe it was IEBGENER itself. If we had HOLDDATA back then, I'm not sure how big a deal we made of it. In any case, one major application had an 'outage' because a particular job step had been counting on the historic default where output blocksize was equal to input blocksize. Their master file was required to be a certain blocksize. For years the offending utility step copied the file without specifying blocksize. Suddenly with SDB the output changed, and subsequent steps failed. I once had to explain to the author of a very silly CLIST why it suddenly failed to enter an expected (!) ERROR routine because underscore was no longer invalid in labels. I didn't feel very guilty about that one. What a dope. I remember reading about a new OP code being introduced on a processor. There was a note of caution that I found almost funny: the new OP code would not cause a problem for any program *unless* that program were depending on the OP code *not* to be valid. Where's my S0C1? I need my S0C1! After all these years in the business, I would not bet the farm on there being no such program. The HOLDDATA cited by Radoslaw falls short of sounding the proper alarm, but it's not misguided. Muted and vague, but not wrong. The most innocent of changes we implement can wreak havoc on applications we would not otherwise have met in a dark alley. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] R.S. [EMAIL PROTECTED] LTIBANK.COM.PLTo Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU action in UK33496 04/19/2008 12:12 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU HOLD(UK33496) SYS FMID(HCI6500) REASON(ACTION) DATE(08037) COMMENT (If the SYSPRINT file is being written to a data set, please note that a System Defined Blocksize will be allocated if no BLKSIZE is defined or a BLKSIZE of 0 is defined on the DD card. My humble questions: 1. Is it really ACTION to perform ? 2. Isn't the behaviour obvious and expected ? If yes, then why to mention it under any HOLD type ? 3. Is it funny ? I also found ACTION which was ...documentation change (in other PTF). -- Radoslaw Skorupka -- 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: action in UK33496
On Sun, 20 Apr 2008 18:11:45 -0700, Skip Robinson [EMAIL PROTECTED] wrote: ... There was a note of caution that I found almost funny: the new OP code would not cause a problem for any program *unless* that program were depending on the OP code *not* to be valid. Where's my S0C1? I need my S0C1! After all these years in the business, I would not bet the farm on there being no such program. ... I remember seeing such a program sometime within the last 15 years. I don't remember what character string used to create the S0C1, but I remember thinking that some day it would be a valid opcode and there was going to be some very unanticipated behavior in that program. Sheesh! Everybody knows you're supposed to EX and EX in such circumstances, not execute some clever word. You need a more intuitive, self-explanatory abend like S0C3 to aid your debugging. :-) Pat O'Keefe -- 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: action in UK33496
Dang, Patrick, how did I miss the connection? Once upon a time, JES2 undertook to manage a newfangled print gismo the same way they always had: start, stop, ship data, handle glitches, the whole enchilada. This newly bred puppy, the 3800, proved to be famously ill mannered. It not only laid waste to the surrounding landscape, it got its master in serious trouble with the whole neighborhood. At a time when 'FSS' was still just a euphemism for something vulgar, JES2 was desperate to impose some order on the 3800 chaos. For one particularly troublesome set of circumstances, a short term maneuver was proposed: 'throw up our programmatic hands and start over'. The problem was how to 'start over' in the middle of some very complex code? Someone noticed that there was already a robust error handling routine that got control in case of JES2 main task abend. This routine cleaned up the 3800 tangle and returned to a known and workable restart point. Trouble was, the error condition that required 'recovery' was often no more than a printer return code that JES2 didn't know what to do with. So the ingenious solution was to branch deliberately to a specific literal string containing a conspicuous 'error message'. The resulting S0C1 would be recognized as an intentional punt (US football term), normal recovery would be invoked, and life would go on. Unfortunately, somewhere between conception, testing, and actual release--come on, did nobody see this before PTF GA?--the intended literal got (re)rendered as an EBCDIC string whose hex beginning fatally resembled a decimal OP code. So instead of S0C1, JES2 took a S0C7, which the recovery routine was not expecting. JES2 died on the spot, and sysprogs all over the world scratched their heads in disbelief. Now that really was funny. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Patrick O'Keefe [EMAIL PROTECTED] AMU.NET To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: action in UK33496 04/20/2008 08:06 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU On Sun, 20 Apr 2008 18:11:45 -0700, Skip Robinson [EMAIL PROTECTED] wrote: ... There was a note of caution that I found almost funny: the new OP code would not cause a problem for any program *unless* that program were depending on the OP code *not* to be valid. Where's my S0C1? I need my S0C1! After all these years in the business, I would not bet the farm on there being no such program. ... I remember seeing such a program sometime within the last 15 years. I don't remember what character string used to create the S0C1, but I remember thinking that some day it would be a valid opcode and there was going to be some very unanticipated behavior in that program. Sheesh! Everybody knows you're supposed to EX and EX in such circumstances, not execute some clever word. You need a more intuitive, self-explanatory abend like S0C3 to aid your debugging. :-) Pat O'Keefe -- 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: action in UK33496
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Skip Robinson Dang, Patrick, how did I miss the connection? Once upon a time, JES2 undertook to manage a newfangled print gismo the same way they always had: start, stop, ship data, handle glitches, the whole enchilada. This newly bred puppy, the 3800, proved to be famously ill mannered. It not only laid waste to the surrounding landscape, it got its master in serious trouble with the whole neighborhood. At a time when 'FSS' was still just a euphemism for something vulgar, JES2 was desperate to impose some order on the 3800 chaos. For one particularly troublesome set of circumstances, a short term maneuver was proposed: 'throw up our programmatic hands and start over'. The problem was how to 'start over' in the middle of some very complex code? Someone noticed that there was already a robust error handling routine that got control in case of JES2 main task abend. This routine cleaned up the 3800 tangle and returned to a known and workable restart point. Trouble was, the error condition that required 'recovery' was often no more than a printer return code that JES2 didn't know what to do with. So the ingenious solution was to branch deliberately to a specific literal string containing a conspicuous 'error message'. The resulting S0C1 would be recognized as an intentional punt (US football term), normal recovery would be invoked, and life would go on. Unfortunately, somewhere between conception, testing, and actual release--come on, did nobody see this before PTF GA?--the intended literal got (re)rendered as an EBCDIC string whose hex beginning fatally resembled a decimal OP code. So instead of S0C1, JES2 took a S0C7, which the recovery routine was not expecting. JES2 died on the spot, and sysprogs all over the world scratched their heads in disbelief. Now that really was funny. Who'da thunk to _start_ a string with a null character? :-) -jc- -- 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
