Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
And when somebody would specify large buffers, then the compiler would cause a large paging spike due to initializing a couple of meg(?) of storage to x'00'. With today's memory-rich environment, is this still an issue? IHMO, it should never be necessary to initialize neither large buffers nor large arrays. It is not really complex logic that is needed to keep track to what extent the area has been filled with data. You only need to initialize a pointer or counter or both. Won't heat up paging. Note that do not say initializaion is not needed, it of course is. I only say you don't need to initialize large areas which you possibly even don't fully use. -- Peter Hunkeler Credit Suisse -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Have to chime in on this one: The ONLY way to find all of the programs that make erroneous assumptions about the initial contents of acquired storage is to test with the IgvInitGetmain DIAG trap enabled. I repeat, it's the ONLY way! I agree wholeheartedly. And I am not talking about bad code or bad programmers. Things can get overlooked at the nth change to a program. But, so far IBM has not documented that facility. IMHO, APAR OA27291 provided an appropriate opportunity for them to do so. Unfortunately, that opportunity was missed. :-( I agree wholeheartedly, too! I have done quite a bit of fighting to even be allowed to do the first test with the traps enabled. Common reaction was: If it's not documented, we cannot turn it on! Don't know if it is due to language or due to bits, but it appears very hard for a sysprog to understand *why* the getmain traps are the only way to test and be reasonably safe. It took me a long document with detailed explanations and 'translations' of control block content, and after that there were still questions. And I am NOT patient to begin with! And, yet there is no DOCUMENTED or SUPPORTED way for IBM's customers to find and fix these erroneous programs! And I shudder to think that an area that wasn't cleared contains data that can be interpreted as numbers that are used to calculate debt, for instance. The program will end with cc=0, with no one the wiser. Might add to the worldwide financial crisis! We have 20+ year old programs running. How can we determine if the programmer coded them correctly? Same here. A RACF exit was running for 25 years and had never caused a problem. In preparation for IPLing with the traps active, I had checked all our 'usermods' (i.e. exits), and that one stood out as a) having an unbalanced number of getmains and freemains (why?) and b) the part with only the getmain just *felt* suspicious. We had decided to deinstall that exit on my gut feeling but my colleague forgot. The first IPL failed with about 20 dumps in that exit because it was accessing PSA that was now made x''. (And it has done that for 25+ years.) So, I don't think there is a 'good way' to determine if things were coded correctly. But checking to see if every getmain has a corresponding freemain and every getmained area is cleared is fairly easy, in my opinion. *Then* it needs a closer look *why* an areas wasn't cleared (might be intentionally if it'S a buffer, for instance). The ultimate arbiter is the diag trap, though! And it makes it *a lot* easier to see that we're talking about uninitialized storage! Those x'FF' are really hard to miss. How long will this mode remain supported? One of my arguments was the allowuserkeycsa trap.I have predicted that there will be a health check in the near future (say 1.11) that checks for the new behaviour and issues a warning. Depending on how fast user key csa is made to abend every time, the 1.10 behaviour will probably follow it. Remember the 64-bit mode migration? Arguably, this VSM change should have been handled more like Vsm AllowUserKeyCsa was. Put out the option with default as 'no change' and eventually change the default. That more deliberate approach probably wouldn't have ruffled so many feathers... Well, I don't think IBM expected so many vendors to fail. Given what Jim has explained before, IBM fixed part of their own bugs (but IBM System Test has been running with the traps on forever!). Now, did I mention that Omegamon for DB2 (now Tivoli-something-or-other)had three different abends, too, when we tested? Oh, and the common sysprog/customer reaction will probably be the same as here: Why should *WE* test IBM/vendorX/vendorY code? (anyone have a good counterargument for that one?) Not to mention the fight that you have every time you report a problem caused by the traps. And before you're able to get up a system properly, you cannot even test your inhouse code! Best regards, Barbara -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
On Thu, 5 Feb 2009 22:41:41 -0800 Edward Jaffe edja...@phoenixsoftware.com wrote: :Binyamin Dissen wrote: : I wonder if VSM is smart enough to recognize that a paged out page is all zero : and to just mark it as not assigned yet so that a page fault will not require : a page in. :I seriously doubt VSM is the least bit aware of the contents of the :pages. But perhaps it should be. Or detect a page fault for an unassigned page when a MVCL(E) is being issued and if the entire page is being set to zero just update the registers and let it try again? : Of course, the application program can use PGSER RELEASE to :zero a page and release any frame/slot it might occupy. No page in (or :out) required. Like first reference. Great for those that know what they are doing. I coded that in a project where a wrap around LDS log was being used and rarely more than X old records were examined. Did a PGSER after hardening the pages. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
On Thu, Feb 5, 2009 at 4:54 PM, Tom Marchant m42tom-ibmm...@yahoo.comwrote: ..snip To single out this one class of error as inexcusable or bad programming is absurd. That's my opinion. ..snip It's absurd to RTFM before you code a macro? Any ISV product that has this problem would make me wonder about what other simple rules were ignored or what other data areas were used that should not have been, etc. It's not absurd to expect a product to be written to IBM standards. Yes, all code will have bugs, that a guarantee, but ones that were caused by not reading about a macro before coding it or using a data area that IBM has clearly marked as reserved etc are inexcusable. As I've said, I understand the need for IBM's fix since there is a lot of home grown assembler applications that maybe were written without complete understanding of what was being used, but an ISV product that a company charges companies for, should follow the book. Guy Gardoit z/OS Systems Programming -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
On Thu, 5 Feb 2009 11:02:42 -0700, Roach, Dennis (N-GHG) dennis.ro...@lmco.com wrote: I never knew about the 4096 or 8192 rules. I had always been taught that the ONLY time storage is cleared is when RSM assigns a real page to a virtual page that is not already backed by one in aux storage. I don't think your rule is not one that a programmer can make use of, as it does not provide a way to know when RSM will take that action. The 4096+page boundary or = 8192 rule is one a programmer can use, and in fact describes the cases that lead to your statement. If you have any other GETMAIN or STORAGE OBTAIN, then you have no guarantee that a new page was assigned, and thus no guarantee of zeroed storage. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe Guy Gardoit wrote: For the life of me, I can't understand why this is such a surprise or problem. How many bad programmers were-there/are-there anyway? Sorry, but one who breaks the rules, end ups broken. Even good programmers make mistakes. That's why we have testing. What's needed are test tools to help detect problems early, before newly-developed programs are used in production environments. Thanks to Jim Mulder's efforts, the IgvInitGetMain DIAG trap is just such a tool. It has been available since OS/390 V2R6 and has been disclosed to IBM and ISV development organizations for many, many years. In that light, there is very little excuse (IMHO) for 21st-century program product code to have problems related to uninitialized GETMAINed storage. (I just know Sam Knutson will adopt the Prodigal Son approach and praise developers that waited until 2009 to *finally* fix their broken code. But, I digress...) OTOH, customers have not had the luxury of this tooling. There are a few tech-savvy sysprogs that have enabled this and other undocumented DIAG traps based on information they received at SHARE, IBM-MAIN, or other avenues (include Barabara Nitz in this category). But, the rest of the user community is completely unaware that such tooling is available. Their exits and applications are at risk and they have no way of testing them. This ignorance, and the fall-out we'll be feeling from it for some time to come, could have been avoided. IMHO, IBM should move to document these tools ASAP! This thread should also reinforce the notion, If you want it done right, do it yourself. IOW, if you want GETMAINed storage to be clean, then clean it yourself, every time you GETMAIN. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown On Fri, 6 Feb 2009 07:53:03 -0600, Chase, John wrote: snip This thread should also reinforce the notion, If you want it done right, do it yourself. IOW, if you want GETMAINed storage to be clean, then clean it yourself, every time you GETMAIN. -jc- I generally agree. However, IIRC, the PL/I compiler did this type of operation long ago. And when somebody would specify large buffers, then the compiler would cause a large paging spike due to initializing a couple of meg(?) of storage to x'00'. BICR the OS/VS COBOL compiler did that, too. Then along came VS/COBOL-II which didn't, unless the WSCLEAR option was specified or tailored in the installation defaults. Now we have LE, which provides STORAGE(xx,...). Institutionalized habits, good or bad, are nearly impossible to change, especially when a permanent crutch is provided. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
This performance issue is what was fixed in LE at some point. IBM did have a well documented option that would make it work like it used to. Dennis Roach GHG Corporation Lockheed Marten Mission Services FDOC Contract 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Voice: (281) 336-5027 Cell:(713) 591-1059 Fax: (281) 336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John McKown Sent: Friday, February 06, 2009 8:35 AM I generally agree. However, IIRC, the PL/I compiler did this type of operation long ago. And when somebody would specify large buffers, then the compiler would cause a large paging spike due to initializing a couple of meg(?) of storage to x'00'. -- John -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
To single out this one class of error as inexcusable or bad programming is absurd. That's my opinion. Of course, you're entitled to your opinion. But, not initialising is the worst mistake a programmer can make! The first thing I was taught, in the early 1970's, was always ensure your data structures are initialised. - Too busy driving to stop for gas! -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Vernooy, C.P. - SPLXM wrote: What worries me is the fact that the fix sets default processing to UseZosV1R9Rules(Yes). You don't have to do anything to remain in the safe pre-1.10 mode, so many customers will probably overlook this 1.10 enhancement. The pre-1.10 mode is not safe--just a little different. And, programs that seem to continue to work using the post-1.10 mode are not safe either. When programs erroneously expect zeros, in cases where such zeroing is not guaranteed, avoidance of abend depends entirely on luck. Any subtle change in the calling environment's storage allocation can cause them to fail. The only way to locate these programs is to use the IgvInitGetMain DIAG trap! I also wish the default had been UseZosV1R9Rules(No). But, when customers get upset, and IBM executives--who fancy themselves experts in risk assessment--get involved, things usually go this way. There is ample recent precedent at IBM for undocumented options, that become documented options, that default to the old behavior and eventually go the other way. Examples: IosProtCaptUcb which became CaptUcb NO which became CaptUcb YES, IgvNoUserKeyCsa which became Vsm AllowUserKeyCsa YES which became Vsm AllowUserKeyCsa NO. There are some pending ones like AsnReuse which became ReusAsid NO which will hopefully become ReusAsid YES in a future release and CbLoc Virtual24(IHALCCA,IHAPCCA) which will hopefully become CbLoc Virtual31(IHALCCA,IHAPCCA) in a future release. Arguably, this VSM change should have been handled more like Vsm AllowUserKeyCsa was. Put out the option with default as 'no change' and eventually change the default. That more deliberate approach probably wouldn't have ruffled so many feathers... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
On Fri, 6 Feb 2009 07:53:03 -0600, Chase, John jch...@ussco.com wrote: snip This thread should also reinforce the notion, If you want it done right, do it yourself. IOW, if you want GETMAINed storage to be clean, then clean it yourself, every time you GETMAIN. -jc- I generally agree. However, IIRC, the PL/I compiler did this type of operation long ago. And when somebody would specify large buffers, then the compiler would cause a large paging spike due to initializing a couple of meg(?) of storage to x'00'. -- John -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
This thread should also reinforce the notion, If you want it done right, do it yourself. IOW, if you want GETMAINed storage to be clean, then clean it yourself, every time you GETMAIN. 100% in agreement. The first programme I wrote (1971 -- High School) was in FORTRAN, and we learned about DO Loops and ARRAYs on the same day. We learned about DO Loops, because initialisation was the first thing we were taught to do. And, it was a loop that was used to do it. It was also the first lines of code invoked by the programme. - Too busy driving to stop for gas! -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
I generally agree. However, IIRC, the PL/I compiler did this type of operation long ago. And when somebody would specify large buffers, then the compiler would cause a large paging spike due to initializing a couple of meg(?) of storage to x'00'. With today's memory-rich environment, is this still an issue? And, what is the business risk of a few extra page ins versus corrupted/invalid data. I don't believe there's a Visine for that! - Too busy driving to stop for gas! -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
FWIW...the z/OS R10 Migration book has been recently refreshed and is available on the z/OS R10 bookshelves. The reason I mention this, is because we added a migration action for OA27291. There's some good information in there also, I daresay. (Here's a link to the BOOK: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/E0Z2M161/CCONTENTS?SHELF=EZ2ZO10LDN=GA22-7499-14DT=20090122142947 ). -Marna WALLE z/OS System Build and Install -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Assumptions about the state of uninitialized storage can bite the best of us. Last year we ran into a problem with the Cobol code generated by the SQL Coprocessor using Enterprise Cobol 3.3 under DB2 V8. In the SQL---PLIST it was generating the following FILLER area: 02 SQL---STMT-NUMPIC S9(9) COMP-5. 02 FILLER PIC X(20). Apparently the FILLER area is used by DB2 to store some bit switches and its logic assumes that initially the FILLER contains x'00'. *Usually* this is true, but we ran into some very weird application abends in an IMS MPR. . It turned out that we were a bit behind in our Cobol maintenance. After the maintenance was applied the generated code changed to: 02 SQL---STMT-NUMPIC S9(9) COMP-5. 02 FILLER PIC X(20) VALUE IS X'' In my experience this is the first time that a programmer's protest that It's not my fault! turned out to be true. :-) -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
For the archives http://www.ibm.com/support/docview.wss?uid=isg1OA27291 OA27291 is closed with some good information included in the APAR text. Thanks, Sam Knutson This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Knutson, Sam wrote: http://www.ibm.com/support/docview.wss?uid=isg1OA27291 OA27291 is closed with some good information included in the APAR text. Hopefully, people understand that this APAR doesn't fix the failing programs. They still make erroneous assumptions about the initial contents of the storage they acquire and are at risk of failing with our without UseZosV1R9Rules(Yes) coded. And, there are also other programs that make erroneous assumptions about initial storage contents that still seem to work most of the time, even with the new z/OS 1.10 VSM behaviors. The ONLY way to find all of the programs that make erroneous assumptions about the initial contents of acquired storage is to test with the IgvInitGetmain DIAG trap enabled. I repeat, it's the ONLY way! But, so far IBM has not documented that facility. IMHO, APAR OA27291 provided an appropriate opportunity for them to do so. Unfortunately, that opportunity was missed. :-( So, we're no further along with this than we were before. There are hundreds, maybe even thousands, of programs making erroneous assumptions about the initial contents of acquired storage. These programs are coded improperly and are exposed to what might appear to be spurious or unrepeatable abends. Those that are APF authorized might even represent potential exposures to the system! And, yet there is no DOCUMENTED or SUPPORTED way for IBM's customers to find and fix these erroneous programs! :o -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
I never knew about the 4096 or 8192 rules. I had always been taught that the ONLY time storage is cleared is when RSM assigns a real page to a virtual page that is not already backed by one in aux storage. Otherwise, the page contains whatever residual is in real or aux storage. I have never found this rule to fail. Bottom line - it is the programmers responsibility initialize storage as needed. Changes in LE have bit us in C++ and PL/I code in this area in the past. Dennis Roach GHG Corporation Lockheed Marten Mission Services FDOC Contract 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Voice: (281) 336-5027 Cell:(713) 591-1059 Fax: (281) 336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Thursday, February 05, 2009 11:06 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10 Knutson, Sam wrote: http://www.ibm.com/support/docview.wss?uid=isg1OA27291 OA27291 is closed with some good information included in the APAR text. Hopefully, people understand that this APAR doesn't fix the failing programs. They still make erroneous assumptions about the initial contents of the storage they acquire and are at risk of failing with our without UseZosV1R9Rules(Yes) coded. And, there are also other programs that make erroneous assumptions about initial storage contents that still seem to work most of the time, even with the new z/OS 1.10 VSM behaviors. The ONLY way to find all of the programs that make erroneous assumptions about the initial contents of acquired storage is to test with the IgvInitGetmain DIAG trap enabled. I repeat, it's the ONLY way! But, so far IBM has not documented that facility. IMHO, APAR OA27291 provided an appropriate opportunity for them to do so. Unfortunately, that opportunity was missed. :-( So, we're no further along with this than we were before. There are hundreds, maybe even thousands, of programs making erroneous assumptions about the initial contents of acquired storage. These programs are coded improperly and are exposed to what might appear to be spurious or unrepeatable abends. Those that are APF authorized might even represent potential exposures to the system! And, yet there is no DOCUMENTED or SUPPORTED way for IBM's customers to find and fix these erroneous programs! :o -- Edward E Jaffe Phoenix Software International, Inc -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
On Thu, Feb 5, 2009 at 1:02 PM, Roach, Dennis (N-GHG) dennis.ro...@lmco.com wrote: ...snip Bottom line - *it is the programmers responsibility initialize storage as needed.* Changes in LE have bit us in C++ and PL/I code in this area in the past. ...snip For the life of me, I can't understand why this is such a surprise or problem. How many bad programmers were-there/are-there anyway? Sorry, but one who breaks the rules, end ups broken. Guy Gardoit z/OS Systems Programming -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Guy, While your analysis is correct, that does not help the user that goes to a new release and suddenly has things blowing up. It is not always a case of a bad programmer, it can just be a case of forgetting to init and it never caused a problem in the past. I agree with Ed that IBM should have made a bigger point about this change and the importance to the user to run with these debugging options turned on. Christopher Y. Blaicher Senior Software Developer Austin Development Lab phone: 512.340.6154 moble: 512.627.3803 fax: 512.340.6647 10431 Morado Circle Austin, TX 78759 BMC Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Guy Gardoit Sent: Thursday, February 05, 2009 12:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10 On Thu, Feb 5, 2009 at 1:02 PM, Roach, Dennis (N-GHG) dennis.ro...@lmco.com wrote: ...snip Bottom line - *it is the programmers responsibility initialize storage as needed.* Changes in LE have bit us in C++ and PL/I code in this area in the past. ...snip For the life of me, I can't understand why this is such a surprise or problem. How many bad programmers were-there/are-there anyway? Sorry, but one who breaks the rules, end ups broken. Guy Gardoit z/OS Systems Programming -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
How many of the programs that run in your installation were written by you? We have 20+ year old programs running. How can we determine if the programmer coded them correctly? Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Guy Gardoit Sent: Thursday, February 05, 2009 1:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10 On Thu, Feb 5, 2009 at 1:02 PM, Roach, Dennis (N-GHG) dennis.ro...@lmco.com wrote: ...snip Bottom line - *it is the programmers responsibility initialize storage as needed.* Changes in LE have bit us in C++ and PL/I code in this area in the past. ...snip For the life of me, I can't understand why this is such a surprise or problem. How many bad programmers were-there/are-there anyway? Sorry, but one who breaks the rules, end ups broken. Guy Gardoit z/OS Systems Programming -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
On Thu, 5 Feb 2009 13:39:32 -0500, Guy Gardoit ggard...@gmail.com wrote: For the life of me, I can't understand why this is such a surprise or problem. How many bad programmers were-there/are-there anyway? Sorry, but one who breaks the rules, end ups broken. Guy Gardoit z/OS Systems Programming I'll admit that I am one of the ones who would have made this mistake. I don't know why, but I __always__ thought that the storage returned via GETMAIN or STORAGE OBTAIN was guaranteed to be x'00'. Now, I might not have gotten caught because my normal coding technique for this sort of think is to assemble an initialization area in my code, do the GETMAIN, then MVC[L] my initialized area to the GETMAIN'd area. -- John -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
For the life of me, I can't understand why this is such a surprise or problem. I agree! In 1976, I was taught, whether getmain, malloc, or whatever the memory allocation method was, to always initialise, unless the function specifically stated it would do it. That was my first year university programming courses. When in doubt, assume it's not initialised. How many bad programmers were-there/are-there anyway? Sadly, too many to count on fingers and toes. And, unfortunately, they're not restricted to mickey-soft. If you allocated it, initialise it. If you allocated, de-allocate it when you're done! If you open it, close it. If you ENQ it, DEQUEU it. Basic, but missed! Too many times!!! - Too busy driving to stop for gas! -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Just as a side note, I remember learning long ago to always initialize static areas, for example: use DC instead of DS wherever possible (same equivalents for all languages). It follows that the rule same rule would be wise for dynamic storage. Seemed simple enough at the time. I do understand though why IBM had to come up with this, IMO, very generous fix. Guy Gardoit z/OS Systems Programming On Thu, Feb 5, 2009 at 1:57 PM, Ted MacNEIL eamacn...@yahoo.ca wrote: For the life of me, I can't understand why this is such a surprise or problem. I agree! In 1976, I was taught, whether getmain, malloc, or whatever the memory allocation method was, to always initialise, unless the function specifically stated it would do it. That was my first year university programming courses. When in doubt, assume it's not initialised. How many bad programmers were-there/are-there anyway? Sadly, too many to count on fingers and toes. And, unfortunately, they're not restricted to mickey-soft. If you allocated it, initialise it. If you allocated, de-allocate it when you're done! If you open it, close it. If you ENQ it, DEQUEU it. Basic, but missed! Too many times!!! - Too busy driving to stop for gas! -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
How many of the programs that run in your installation were written by you? Non sequitor! We have 20+ year old programs running. How can we determine if the programmer coded them correctly? Probably more likely than today's code. At the risk of sounding like an old f*rt, we were more careful then, than what I've seen, lately. These days, programmers debug by friction! Of course, when I went to school, it was in the dead of winter, and it was uphill in both directions. I don't blame the programmers, so much as I blame their teachers. - Too busy driving to stop for gas! -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
It is not always a case of a bad programmer, it can just be a case of forgetting to init and it never caused a problem in the past. Well slap me rosey! I don't see the difference between bad programming, and forgetting to init! - Too busy driving to stop for gas! -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
We installed a new release of CA/TMS. Tape processing checked out, regression testing was good, we went into production. Within a few days we had a broken PL/I program and TMS had to be the problem because the code has worked without change for years. We IPLd the old release and it did work. Set a slip for where it was abending in the new release. The bad reg was pointing to a module that had been loaded into CSA. The address on the new release had not been getmained. The address was being passed as the last parameter of the list and documented as optional. No check was being made in the code for the absence of the parameter. BTW, the module in CSA in the old system was a TMS module. On the other hand, people make use of bugs in compilers. We still have an old FORTRAN compiler because of code that relies on a bug with the handling of common. Both of these are errors, the latter a known and accepted risk. It's the ones like the first that scare me. What is the code doing with the bad data? Where is that darn source from 20+ years ago? Dennis Roach GHG Corporation Lockheed Marten Mission Services FDOC Contract 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Voice: (281) 336-5027 Cell:(713) 591-1059 Fax: (281) 336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Blaicher, Chris Guy, While your analysis is correct, that does not help the user that goes to a new release and suddenly has things blowing up. It is not always a case of a bad programmer, it can just be a case of forgetting to init and it never caused a problem in the past. I agree with Ed that IBM should have made a bigger point about this change and the importance to the user to run with these debugging options turned on. Christopher Y. Blaicher Senior Software Developer Austin Development Lab BMC Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Guy Gardoit On Thu, Feb 5, 2009 at 1:02 PM, Roach, Dennis (N-GHG) dennis.ro...@lmco.com wrote: ...snip Bottom line - *it is the programmers responsibility initialize storage as needed.* Changes in LE have bit us in C++ and PL/I code in this area in the past. ...snip For the life of me, I can't understand why this is such a surprise or problem. How many bad programmers were-there/are-there anyway? Sorry, but one who breaks the rules, end ups broken. Guy Gardoit z/OS Systems Programming -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Just as a side note, I remember learning long ago to always initialize static areas Again, basic. Again, I agree. And, I can't understand the defensive stants, of those who don't/won't believe that basic programming is wrong! Forgetting to init is inexcusable! - Too busy driving to stop for gas! -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
I don't think that anyone is defending bad programming practices, but not all of us have the luxury of knowing what every program running on our production systems is doing. Some were written long ago, some by vendors, and some by just bad programmers. As a systems person I have to make sure that programs that ran yesterday can run today without any changes to them. Business is business and changes cost , so even if the code was poorly written, if it is running now it better run tomorrow. Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, February 05, 2009 2:45 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10 Just as a side note, I remember learning long ago to always initialize static areas Again, basic. Again, I agree. And, I can't understand the defensive stants, of those who don't/won't believe that basic programming is wrong! Forgetting to init is inexcusable! - Too busy driving to stop for gas! -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
On Thu, 5 Feb 2009 19:44:51 +, Ted MacNEIL eamacn...@yahoo.ca wrote: Just as a side note, I remember learning long ago to always initialize static areas Again, basic. Again, I agree. And, I can't understand the defensive stants, of those who don't/won't believe that basic programming is wrong! Forgetting to init is inexcusable! ... I seem to be in a different universe than Ted is. I haven't met these infallible programmers. Those I've met have been known to use a DS when they meant DC, or miscalculate a length, or just plain forget. It happens whether or not it is excusable. As far as I know, Ed et al. were not talking about something that would make up for the mistakes; they were talking about something that would find and expose those mistakes. For the life of me I can't think of anything wrong with that. Pat O'Keefe -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Guy Gardoit wrote: For the life of me, I can't understand why this is such a surprise or problem. How many bad programmers were-there/are-there anyway? Sorry, but one who breaks the rules, end ups broken. Even good programmers make mistakes. That's why we have testing. What's needed are test tools to help detect problems early, before newly-developed programs are used in production environments. Thanks to Jim Mulder's efforts, the IgvInitGetMain DIAG trap is just such a tool. It has been available since OS/390 V2R6 and has been disclosed to IBM and ISV development organizations for many, many years. In that light, there is very little excuse (IMHO) for 21st-century program product code to have problems related to uninitialized GETMAINed storage. (I just know Sam Knutson will adopt the Prodigal Son approach and praise developers that waited until 2009 to *finally* fix their broken code. But, I digress...) OTOH, customers have not had the luxury of this tooling. There are a few tech-savvy sysprogs that have enabled this and other undocumented DIAG traps based on information they received at SHARE, IBM-MAIN, or other avenues (include Barabara Nitz in this category). But, the rest of the user community is completely unaware that such tooling is available. Their exits and applications are at risk and they have no way of testing them. This ignorance, and the fall-out we'll be feeling from it for some time to come, could have been avoided. IMHO, IBM should move to document these tools ASAP! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Ted MacNEIL wrote: I don't see the difference between bad programming, and forgetting to init! Good programmers design thoughtful, elegant algorithms and well organized programs. Bad programmers write poorly designed algorithms and disorganized programs. Both good and bad programmers can make mistakes at implementation time. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Roach, Dennis (N-GHG) wrote: On the other hand, people make use of bugs in compilers. We still have an old FORTRAN compiler because of code that relies on a bug with the handling of common. Anything interesting? The only thing I can recall that might apply is the ability to initialize with a BLOCK DATA, and then call that as a function or subroutine. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
On Thu, 5 Feb 2009 13:39:32 -0500, Guy Gardoit wrote: On Thu, Feb 5, 2009 at 1:02 PM, Roach, Dennis wrote: Bottom line - *it is the programmers responsibility initialize storage as needed.* Changes in LE have bit us in C++ and PL/I code in this area in the past. Of course, along with many other things. For the life of me, I can't understand why this is such a surprise or problem. How many bad programmers were-there/are-there anyway? Sorry, but one who breaks the rules, end ups broken. Programs rarely do exactly what is expected of them when they are first written. That is the purpose of testing. The traps that Ed is advocating are just another part of testing. The fact is that until code is tested, you can never be certain what it will do. When it comes to correctness of code, my vote doesn't count. Your vote doesn't count. Only one vote counts, and that is the computer's. When I first got started in this business in 1970 as an applications programmer, my boss had nearly everyone complete a training program before they startred on real work. As far as I know, I was the only one who was not given that assignment, so I can't provide details about the assignment. I do know that it involved card input and that the data on the cards was to be validated and processed. When the new programmer thought that the program was finished, the boss would give them an object deck to use as input. Errors in code do not, IMO, mean that the programmer is a bad programmer. *Every* significant program was written with errors. That is why we test. Thorough testing is not easy, but it is important. To single out this one class of error as inexcusable or bad programming is absurd. That's my opinion. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
On Thu, 5 Feb 2009 11:02:42 -0700 Roach, Dennis (N-GHG) dennis.ro...@lmco.com wrote: :I never knew about the 4096 or 8192 rules. I had always been taught that :the ONLY time storage is cleared is when RSM assigns a real page to a :virtual page that is not already backed by one in aux storage. :Otherwise, the page contains whatever residual is in real or aux :storage. I have never found this rule to fail. 4096+ BNDRY=PAGE virtual was always cleared. It prevented the need to force slot assignments for pages that may never be needed via a big MVCL to clear the area. I wonder if VSM is smart enough to recognize that a paged out page is all zero and to just mark it as not assigned yet so that a page fault will not require a page in. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Binyamin Dissen wrote: I wonder if VSM is smart enough to recognize that a paged out page is all zero and to just mark it as not assigned yet so that a page fault will not require a page in. I seriously doubt VSM is the least bit aware of the contents of the pages. Of course, the application program can use PGSER RELEASE to zero a page and release any frame/slot it might occupy. No page in (or out) required. Like first reference. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Edward Jaffe edja...@phoenixsoftware.com wrote in message news:498b1c64.1030...@phoenixsoftware.com... Knutson, Sam wrote: http://www.ibm.com/support/docview.wss?uid=isg1OA27291 OA27291 is closed with some good information included in the APAR text. Hopefully, people understand that this APAR doesn't fix the failing programs. They still make erroneous assumptions about the initial contents of the storage they acquire and are at risk of failing with our without UseZosV1R9Rules(Yes) coded. What worries me is the fact that the fix sets default processing to UseZosV1R9Rules(Yes). You don't have to do anything to remain in the safe pre-1.10 mode, so many customers will probably overlook this 1.10 enhancement. How long will this mode remain supported (imbed and replicate's toleration lifetime has ended too)? When will we have to go to 1.10 mode? IBM will want to end duplicate code paths at some moment (like SECP). The advantages are clear and will become more pressing with growing DB2 etc. systems, that will benefit more and more from the consolidated DQE's. ISV's might be tempted to request keeping UseZosV1R9Rules(Yes), i.e. remove the UseZosV1R9Rules(No), in stead of solving their problems quickly. I had rather seen the default UseZosV1R9Rules(No) and the (Yes) value optional, so you will see it any time you scan your parmlib with z/OS upgrades. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Roland here you go: ZEBB PTF E320ATBA Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Roland Schiradin Sent: Thursday, December 11, 2008 6:02 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10 Jon, could you post the ISV/Software and the ptf? The bad program caused an overlay in another vendor's code, so I had to determine what caused the overlay. Once I determined who caused the overlay it was up to the vendor to fix it, but it was not a trivial task. -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Ed Jaffe wrote If this behavior isn't documented, then what difference does it make? A program that depends on this behavior is no different than one that depended on undocumented alignment properties from pre-z/OS 1.10 GETMAIN behavior. What you wrote is certainly true. But it was exactly this situation that is OA27291. It was all about programs that relied on z/OS not changing some undocumented behavior. Probably this reliance was on the unintentional side, but you never know.. Peter Relson z/OS Core Technology Design -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Not only that, but CICS is developed--and I assume tested--in Hursley. I suspect they, as well as Bvblingen, San Jose, Rochester, Perth, Raleigh, Rome and other labs play from a different rule book than do the folks in POK. Not really different in this regard. The word about dirty getmain was propagated to every system test organization within IBM z, and it is expected that they use it (sometimes they'll use it periodically -- it is a fact that dirty getmain has on occasion hidden a problem that running without dirty getmain would have encountered). Our standard position with respect to ISVs is that if they encounter an IBM problem due to their use of dirty getmain, we will try to fix it. The CICS situation that Jim Mulder mentioned is, I hope, more the exception than the rule. Clearly if problems do not get fixed, then you will be turning off dirty getmain as you can't do your own work if on an unstable system, and thus not getting any of the testing benefit that dirty getmain can provide. Please note also that dirty getmain does not try to be omniscient. It is a fact (but not a documented promise) that the first getmain done under a job for a user-region subpool will get 0's, simply because of the free region done between jobs. Dirty getmain may not note that and may dirty it. A program that relied on that behavior would technically be correct but would not work with dirty getmain active. We tend to try to remove that reliance just so that other programs can use dirty getmain, We want the system to be usable with dirty getmain active, we just cannot guarantee it. If there were the notion of here is something for your sandbox system, please let us know if you find some problem, but we cannot promise to take an APAR to fix it, is that something that would work for you? Many of the DIAGxx traps would fall into that categorization. This notion is, sort of, the agreement we have with the ISVs. I'm not speaking legal-ese because I don't know how. Peter Relson z/OS Core Technology Design -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Peter Relson wrote: Our standard position with respect to ISVs is that if they encounter an IBM problem due to their use of dirty getmain, we will try to fix it. The CICS situation that Jim Mulder mentioned is, I hope, more the exception than the rule. Clearly if problems do not get fixed, then you will be turning off dirty getmain as you can't do your own work if on an unstable system, and thus not getting any of the testing benefit that dirty getmain can provide. I have an IBM program product (PSF V3) that won't work with IgvInitGetmain active. I reported the bug years ago and they didn't take my complaint seriously. So, I resolved that we would no longer spend money on PSF upgrades until some incompatibility forced us to. (So far, so good on that front.) I honestly don't know if they ever fixed this problem in later releases. Based solely on their attitude toward my request, I would guess not. But, stranger things have happened. Please note also that dirty getmain does not try to be omniscient. It is a fact (but not a documented promise) that the first getmain done under a job for a user-region subpool will get 0's, simply because of the free region done between jobs. If this behavior isn't documented, then what difference does it make? A program that depends on this behavior is no different than one that depended on undocumented alignment properties from pre-z/OS 1.10 GETMAIN behavior. Dirty getmain may not note that and may dirty it. A program that relied on that behavior would technically be correct but would not work with dirty getmain active. We tend to try to remove that reliance just so that other programs can use dirty getmain, We want the system to be usable with dirty getmain active, we just cannot guarantee it. If there were the notion of here is something for your sandbox system, please let us know if you find some problem, but we cannot promise to take an APAR to fix it, is that something that would work for you? Many of the DIAGxx traps would fall into that categorization. This notion is, sort of, the agreement we have with the ISVs. I'm not speaking legal-ese because I don't know how. As Jim noted earlier, the TRAPS for dirty IARST64 and dirty IATCP64, implemented via: IarCp64InitFree, IarCp64InitGet, IarCp64Trailer, IarSt64InitFree, IarSt64InitGet, IarSt64Trailer, are documented to customers in http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e290/27.6. All that's needed is for IgvInitGetmain, IgvInitFreemain, and IgvInitCpool to be added to the list. -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
In 4a25f3adc7d4cd4388704e36280459c308f9f...@mddp-exch-003.aeth.aetna.com, on 12/09/2008 at 07:30 AM, Veilleux, Jon L veilleu...@aetna.com said: Jim, as I stated in our problem record, the change to GETMAIN caused us downtime which is unacceptable in a business environment. IMHO, poor programming caused the outage, and your enterprise is far more at risk from that than it is from changes to undocumented interfaces. This scenario reminds me of the wailing and gnashing of teeth when programs that were working fine[1] under OS/360 started taking S0C4's under OS/VS1 and OS/VS2. Also, did you go to a new z/OS release without doing regression testing? and not all source code is available for us to determine if there will be a problem That is an even worse risk; what happens when changes in the law require changes to the programs for which you don't have source code? Any change to the way a major interface works SHOULD be documented whether the developer thinks that it will cause a problem or not. There I agree. [1] Sometimes with undetected incorrect output. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
In of6f28edcb.889430cf-on8525751c.004f270c-8525751c.0050f...@us.ibm.com, on 12/11/2008 at 09:44 AM, Peter Relson rel...@us.ibm.com said: Please note also that dirty getmain does not try to be omniscient. It is a fact (but not a documented promise) that the first getmain done under a job for a user-region subpool will get 0's, simply because of the free region done between jobs. Dirty getmain may not note that and may dirty it. A program that relied on that behavior would technically be correct If it's relying on inference from observed behavior rather than on documentation, then it's debatable whether it is correct. I miss the old concept of the compiler setting uninitialized words to parity errors, something that is not feasible on current architectures. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Shmuel wrote: IMHO, poor programming caused the outage, and your enterprise is far more at risk from that than it is from changes to undocumented interfaces. This scenario reminds me of the wailing and gnashing of teeth when programs that were working fine[1] under OS/360 started taking S0C4's under OS/VS1 and OS/VS2. Also, did you go to a new z/OS release without doing regression testing? You are right that the root cause is bad programming. The vendor has since resolved the problem by rewriting their code. My main complaint was that the change was undocumented (so I spent a lot of time debugging it) not that GETMAIN changed. By the way, this happened during an ESP so, yes, we were doing regression testing. As far as source code, acquisitions don't always come with compliant programmers and source code. Jon Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
My main complaint was that the change was undocumented I don't know whether the change is documented, but it was disclosed to vendors at the TDM. IMO you shouldn't have spent any time trying to debug vendor code. Bob Shannon Rocket Software -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
The bad program caused an overlay in another vendor's code, so I had to determine what caused the overlay. Once I determined who caused the overlay it was up to the vendor to fix it, but it was not a trivial task. Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bob Shannon Sent: Thursday, December 11, 2008 3:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10 My main complaint was that the change was undocumented I don't know whether the change is documented, but it was disclosed to vendors at the TDM. IMO you shouldn't have spent any time trying to debug vendor code. Bob Shannon Rocket Software -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
On Thu, 11 Dec 2008 15:14:52 -0500, Bob Shannon bshan...@rocketsoftware.com wrote: My main complaint was that the change was undocumented I don't know whether the change is documented, but it was disclosed to vendors at the TDM. IMO you shouldn't have spent any time trying to debug vendor code. Not all vendors participate - especially small ones who's software isn't perceived to have operating system dependencies. That doesn't mean their software nor support is bad. I guess you could argue that a shop shouldn't use that sort of vendor's software... but that is a different thread. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Jon, could you post the ISV/Software and the ptf? The bad program caused an overlay in another vendor's code, so I had to determine what caused the overlay. Once I determined who caused the overlay it was up to the vendor to fix it, but it was not a trivial task. -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Ed Jaffe wrote And, if IBM, ISV, and customer in-house developers would use IgvInitGetmain and IgvInitFreemain on their test/development systems--as we do--nobody would have experienced this issue to begin with. Of course, it's hard to fault someone for not using an undocumented feature. These TRAPs have been around since OS/390 V2R6. They work. Perhaps it's time they were documented, too! IBM does use these traps. Many ISVs do. ISVs have been made aware of the trap options a long time ago, and also were made aware of the z/OS 1.10 algorithm change. If there was a problem with an ISV application (as I believe was Jon V's case, but I could be mistaken), you should consider targeting the finger pointing towards that ISV. It is precisely to allow ISVs to test and verify and fix their code in advance of a release (and thus protect the customer from running into the problems) that we make these disclosures. Customer applications are the innocent victims here as there is no mechanism for alerting the customers ahead of time. Customer concern over the testability of their own applications is the impetus for providing the APAR. GETMAIN has documented for a long time exactly under what circumstances a program may assume that the storage it obtains is zero. As Jim Mulder wrote, none of this behavior has changed. Perhaps the posters think they know just when it is with z/OS 1.10 that storage might not be 0 where it might have been 0 on earlier releases. I'd guess that unless they have thought long and hard about it, their thought is wrong. Peter Relson z/OS Core Technology Design -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Peter Relson wrote: Ed Jaffe wrote And, if IBM, ISV, and customer in-house developers would use IgvInitGetmain and IgvInitFreemain on their test/development systems--as we do--nobody would have experienced this issue to begin with. Of course, it's hard to fault someone for not using an undocumented feature. These TRAPs have been around since OS/390 V2R6. They work. Perhaps it's time they were documented, too! IBM does use these traps. Many ISVs do. ISVs have been made aware of the trap options a long time ago, and also were made aware of the z/OS 1.10 algorithm change. IBM is a large company, with many development and testing organizations--some large, some small. Some of them use these traps. Others don't. Jim will attest that I, more than probably any other ISV or customer, have been sacrificing the stability of my systems *for years* in an effort to help IBM fix issues uncovered by IgvInitGetmain and other similar TRAPs. Why? So we can run with them 24x7, of course! I have suffered through damaged HSM control data sets and other corrupted files, PSF abends, TCP/IP and VTAM issues, RMF problems, JES problems, systems that won't IPL or crash shortly after IPL, and dozens of subtle and bizarre behaviors that eventually led to a discovery of IBM-written programs making assumptions about things being zero: storage, access registers, high halves, you name it. IBM did not discover these things because they did not run with the TRAPs enabled. I make an effort to report things I know are related to DIAG traps through Jim. But, many of the issues looked like ordinary bugs until research proved otherwise. These were reported via ETR. I can tell you that, in almost every case, Level 2 and change team had never heard of these TRAPs! I know that Marna Walle has been a great help in getting more IBM testing organizations to use various TRAPs. The last time we exchanged notes about what she was recommending, IgvInitGetmain was definitely *not* on her list! I realize this is an evolving space. And, it's always possible that things have changed enough, since I last asked, that your blanket statement IBM does use these traps is now accurate. But, knowing IBM as I do, I have my doubts. Case in point: If IBM was religiously using IgvInitGetmain on their test and development systems, the issue with the CICS DFHPD640 dump formatter Jim mentioned yesterday would almost certainly have been discovered by someone at IBM and not by an ISV. If there was a problem with an ISV application (as I believe was Jon V's case, but I could be mistaken), you should consider targeting the finger pointing towards that ISV. It is precisely to allow ISVs to test and verify and fix their code in advance of a release (and thus protect the customer from running into the problems) that we make these disclosures. Agreed. Customer applications are the innocent victims here as there is no mechanism for alerting the customers ahead of time. Customer concern over the testability of their own applications is the impetus for providing the APAR. But, if IgvInitGetmain and similar traps were documented and the system reliably worked with them enabled, at last some customers would use them to help ensure that their in-house applications also had no dependency on storage being cleared by the operating system. All developers will, from time to time, accidentally depend on undocumented behaviors. Any tool that helps you detect such exposures is a good thing. GETMAIN has documented for a long time exactly under what circumstances a program may assume that the storage it obtains is zero. As Jim Mulder wrote, none of this behavior has changed. Perhaps the posters think they know just when it is with z/OS 1.10 that storage might not be 0 where it might have been 0 on earlier releases. I'd guess that unless they have thought long and hard about it, their thought is wrong. Agreed. -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
On Tue, 9 Dec 2008 07:30:32 -0800, Edward Jaffe wrote: And, if IBM, ISV, and customer in-house developers would use IgvInitGetmain and IgvInitFreemain on their test/development systems--as we do--nobody would have experienced this issue to begin with. Of course, it's hard to fault someone for not using an undocumented feature. These TRAPs have been around since OS/390 V2R6. They work. Perhaps it's time they were documented, too! What are we on this list allowed to know about what the IgvInit* traps do? Realistically, the most one could expect is that at GETMAIN/FREEMAIN (or newer counterparts?) random, unpredictable data would be written over the affected storage with the intent of causing program checks. Unrealistically, one might wish that additionally each GETMAIN should allocate a separate page which would be read-protected until it was written, and that each FREEMAIN would immediately read and write protect any entirely freed page. -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Edward Jaffe wrote: I have suffered through damaged HSM control data sets and other corrupted files, PSF abends, TCP/IP and VTAM issues, RMF problems, JES problems, systems that won't IPL or crash shortly after IPL, and dozens of subtle and bizarre behaviors that eventually led to a discovery of IBM-written programs making assumptions about things being zero: storage, access registers, high halves, you name it. IBM did not discover these things because they did not run with the TRAPs enabled. I just looked back to see the last time I had major issues with z/OS choking with various TRAPs enabled. It was almost exactly two years ago when I first brought up z/OS 1.8. With the same standard suite of DIAG traps enabled under z/OS 1.8 that were enabled under z/OS 1.7, I end up with a completely unstable system where RMF abended, TCP/IP applications hung, z/OS UNIX processes got canceled, etc. My emailed comment to Jim Mulder was, Obviously, there are still many, many, development organizations within IBM that don't or won't enable a few simple DIAG TRAPs while developing their code. Obviously, we can't use them either if our systems fall over when they're enabled. :-( I opened the following PMRs to address the new failures. Act Record Customer ID Sev Resp Updated Status Abstract _ 1051171216223 User 12/18/06 Open IPL-time abends in z/OS UNIX _ 1051271216223 User 12/18/06 Open Abend0C4 ARCMDSUV+22C2 _ 1050971216223 IBM 12/18/06 Open Abend0C1 Monitor I The worst of these turned out to be an error in RSM, probably exposed by CsvRentProtect, fixed by APAR OA19409. [snip] I know that Marna Walle has been a great help in getting more IBM testing organizations to use various TRAPs. The last time we exchanged notes about what she was recommending, IgvInitGetmain was definitely *not* on her list! I was wrong about this. Marna has two lists she sens to Poughkeepsie testing organizations: a minimum list, which must always be present, and a recommended list, a superset of the minimum list, with settings are that good, but difficult to keep on. IgvInitGetmain is on her recommended list. You go, Girl! :-) -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Paul Gilmartin wrote: What are we on this list allowed to know about what the IgvInit* traps do? WE on this list? YOU are an ISV. Thus, you should already know all about what these, and dozens of other, TRAPs do. They should already be enabled on the systems where you develop and test your products. -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
What are we on this list allowed to know about what the IgvInit* traps do? Realistically, the most one could expect is that at GETMAIN/FREEMAIN (or newer counterparts?) random, unpredictable data would be written over the affected storage with the intent of causing program checks. Since programmimg is generally constrained by reality, they do pretty much what you have described, except that the data is not really unpredictable or random. A byte value of either x'4F' or x'FF' is used (chosen base on a bit in the TOD clock), or the STGINIT parameter can be used to specify the byte value to be used. This applies to GETMAIN, FREEMAIN, and STORAGE. Newer IAR* counterparts for 64-bit virtual storage in z/OS 1.10 have some similar functions, and since these services were new, we did not have to worry about effects on old programs, so those new TRAPS are documented in the DIAGxx section of the z/OS 1.10 Initialization and Tuning Reference. I have no objection to you on the list knowing exactly what it does. However, I find it easier to describe what it does in code rather than in prose. /* TITLE: Dirtys the storage if trap is enabled. */ DirtyStg: ;/* @D4A*/ IF VswkDget /* If trap is enabled, and we passed filtering @D4A*/ VSWKRC = AllOk THEN /* and storage was obtained @PCM*/ IF VSWKACTS (2 * PageSize) /* and size is less than 2 pages @PCC*/ ¬(VSWKACTS = PageSize /* and not.. at least 1 page @D4A*/ (VSWKGADR '0FFF'X) = 0) THEN /* on a page boundary @PCC*/ DO; /* Trap enabled and size OK @D4A*/ VswkAllZero = Off; /* If we dirty the storage, it will not be all zero @D4A*/ NoTouch = Off; /* Assume OK to touch@D4A*/ IF ¬SPTTFIX ¬SPTTDREF THEN /* If pageable storage @D4A*/ DO; /* Pageable storage @D4A*/ STNSM(SYSMASK,'FF'X); /* Obtain PSW system mask@D4A*/ IF ¬(IOMASK EXTMASK) THEN /* If IGVVSMRT is disabled @D4A*/ DO; /* IGVVSMRT is disabled @LAA*/ TPROT(VswkGAdr-I256C,0); /* Test first byte@LAA*/ IF ¬CCMask(8) THEN /* If page is not valid @LAA*/ NoTouch = On;/* IGVVSMRT cannot touch the obtained storage@D4A*/ TPROT((VswkGAdr + VswkActS - 1)-I256C,0); /* Test last byte @LAA*/ IF ¬CCMask(8) THEN /* If page is not valid @LAA*/ NoTouch = On;/* IGVVSMRT cannot touch the obtained storage@LAA*/ END; /* IGVVSMRT is disabled @LAA*/ END; /* Pageable storage @D4A*/ IF ¬NoTouch THEN /* If OK to touch storage@D4A*/ DO; /* Dirty the storage @D4A*/ VswkAnticipatedAbendRetryAddr= Addr(DirtyStgAbendRetry); /* Set retry address @LBM*/ RFY (RSADDR,RSLEN,RTADDR,RTLEN) RSTD; /*@D4A*/ IF DgnbStgInitSpec THEN /* If STGINIT was specified @D4A*/ RSLEN=FIXED_OF(DgnbStgInitVal); /*@D4A*/ ELSE /* STGINIT not specified @D4A*/ DO; /* STGINIT not specified @D4A*/ VswkAbendAnticipated = On; /* Abend is anticipated @LBA*/ GEN NoRefs NoSets OptAcross Flows(DirtyStgAbendRetry) Code(DS 0H);/* Recovery flow @LBA*/ STCK(STCKAREA); /* Get TOD clock @D4A*/ VswkAbendAnticipated = Off;/* Abend not anticipated @LBA*/ IF ODDSEC THEN/* If an odd second @D4A*/ RSLEN=FIXED_OF(AllBits); /* @D4A*/ ELSE /* Even second@D4A*/ RSLEN=FIXED_OF(AddressBits); /* @D4A*/ END;/* STGINIT not specified @D4A*/ SLL(RSLEN,LENGTH(BIT_OF(RSLEN))-LENGTH(BIT_OF(AllBits)));/* Shift to pad position@D4A*/ RTADDR=VSWKGADR; /* Target address @D4A*/ RTLEN=VSWKACTS; /* Length @D4A*/ VswkAbendAnticipated = On; /* Abend is anticipated @LAA*/ GEN NoRefs NoSets OptAcross Flows(DirtyStgAbendRetry) Code(DS 0H); /* Recovery flow @LAA*/
Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
I realize this is an evolving space. And, it's always possible that things have changed enough, since I last asked, that your blanket statement IBM does use these traps is now accurate. But, knowing IBM as I do, I have my doubts. Case in point: If IBM was religiously using IgvInitGetmain on their test and development systems, the issue with the CICS DFHPD640 dump formatter Jim mentioned yesterday would almost certainly have been discovered by someone at IBM and not by an ISV. In particular, IPCS-related code tends to be adept at avoiding being tested with the traps. Since such code does not require authorization, and can be run on any supported release via STEPLIB/TSOLIB, it tends to get done on what you might call a development system. But since development is our business, we consider those to be production systems, and the systems programming and operations is contracted out to IBM Global Services, and so we don't activate the traps on those systems. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Jim Mulder wrote: In particular, IPCS-related code tends to be adept at avoiding being tested with the traps. Since such code does not require authorization, and can be run on any supported release via STEPLIB/TSOLIB, it tends to get done on what you might call a development system. But since development is our business, we consider those to be production systems, and the systems programming and operations is contracted out to IBM Global Services, and so we don't activate the traps on those systems. Wonderful. :-( Not only that, but CICS is developed--and I assume tested--in Hursley. I suspect they, as well as Bvblingen, San Jose, Rochester, Perth, Raleigh, Rome and other labs play from a different rule book than do the folks in POK. -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Not only that, but CICS is developed--and I assume tested--in Hursley. I suspect they, as well as Bvblingen, San Jose, Rochester, Perth, Raleigh, Rome and other labs play from a different rule book than do the folks in POK. I don't know much about what goes on test-wise in Hursley. We do run CICS workloads with traps active as part of z/OS testing in POK. But we look at the dumps on a production system running on a pokey old z800 which does not have traps active. The lead system tester in Raleigh (Lenny Cain) for VTAM and TCP/IP used to be the system test team leader in POK for MVS, and he has been using the traps for a long time. San Jose MVS system testing also uses traps AFAIK. And some products from other labs are used (RMF, for example) in POK test test environments with traps active, even if we are not explicitly trying to test them. So we do have fairly wide test coverage now. And as a result, the small number of problems related to the VSM changes that we found during z/OS 1.10 testing tended to be of the unwarranted assumption about boundary alignment nature, and not unwarranted assumption about residual storage contents. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
Outsourcing system stability (was: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10)
On Wed, 10 Dec 2008 13:49:19 -0500, Jim Mulder [EMAIL PROTECTED] wrote: ... ...we consider those to be production systems, and the systems programming and operations is contracted out to IBM Global Services, and so we don't activate the traps on those systems. While not stated, I suspect IGS would see running with the traps as a threat to the system integrity. Production work running into unexpected residual data in storage or unexpected alignment is nothing the out-sourcer - an application problem. But problems as the ones Ed described in his experience with early 1.8 with the traps turned on? Those would count against the out-sourcer's up-time. This is another mark against out-sourcing that I had not thought of before. It will take IBM longer to find and fix serious but subtle bugs in the operating system. I assume many customers, not just ISVs, have been willing to cope with lowered system integrity on non-critical systems in order to help IBM debug problems. (I know that's the case in shops I've worked.) It is probably harder to get an out-sourcer to agree with this. Or, more likely, the customer would have to pay for that lessened system integrity. It certainly would have to pay for the extra work the out-sourced operations and system programming staff would have to do when problems surface. This bodes ill for the future. 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Jim Mulder wrote: There is one incorrect thing in the APAR text - VSM development (and as designer and developer for this change, that includes me) has *not* at this time decided to restore the pre-release 1.10 behavior as the default to prevent impact to the unsuspecting program or user. The APAR will create a DIAGxx TRAPS NAME(NameToBeDetermined) which will be documented and, if specified, will cause VSM to revert to the pre-release 1.10 behavior, exactly the same way as the undocumented NUCLABEL ENABLE(IGVGPVTN) mentioned in the APAR description. The lesson here is that, if a change has been observed to cause unexpected surprise wrong behaviors in some IBM components during testing, then similar problems should be expected after deployment. A documented fall-back Chicken Switch should be provided. I think the proposed, documented DIAG TRAP is a great way to go. The reason the change to GETMAIN Behavior in z/OS 1.10 is undocumented is that there is no documentation to change. GETMAIN in z/OS 1.10 continues to behave as documented. All previously documented rules of GETMAIN continue to apply to z/OS 1.10. And, if IBM, ISV, and customer in-house developers would use IgvInitGetmain and IgvInitFreemain on their test/development systems--as we do--nobody would have experienced this issue to begin with. Of course, it's hard to fault someone for not using an undocumented feature. These TRAPs have been around since OS/390 V2R6. They work. Perhaps it's time they were documented, too! -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 12/09/2008 10:30:32 AM: Jim Mulder wrote: The lesson here is that, if a change has been observed to cause unexpected surprise wrong behaviors in some IBM components during testing, then similar problems should be expected after deployment. A documented fall-back Chicken Switch should be provided. I think the proposed, documented DIAG TRAP is a great way to go. None of the wrong behaviors in some IBM components were unexpected or surprising. They were the kinds of things I anticipated. And I expected some similar problems after deployment. That is why there was an undocumented fall-back Chicken Switch provided, designed so that a documented TRAPS could be added for 2 lines of code if subsequent experience dictated. So far, the number of problems that I have heard about has been less that I anticipated. However, some of the ESP customers have requested a documented switch and so the APAR will be providing that. I discussed the issue of documenting vs. not documenting the switch with a number of people during development, and there was no strong consensus at that time (although there are some pretty strong opinions now),so I decided to not document initially, with the option to reevaluate after further experience. And, if IBM, ISV, and customer in-house developers would use IgvInitGetmain and IgvInitFreemain on their test/development systems--as we do--nobody would have experienced this issue to begin with. Of course, it's hard to fault someone for not using an undocumented feature. These TRAPs have been around since OS/390 V2R6. They work. Perhaps it's time they were documented, too! I have considered that many times over the years since OS/390 V2R6, and considered it again for z/OS V1R10. That would have been a convenient time, since the TRAPS keyword was being added to the documentation for the first time (with a small subset of the trap names being documented). And then just a few months ago, an ISV using IgvInitGetmain encountered a problem with the CICS's IPCS VERBEXIT. CICS development has estimated that a complete fix for this in all the dump formatters is probably well over a thousand lines of code given that the DFHPD640 load module comprises circa 200 modules. So the plan is to not fix this in the service stream, and instead try to prioritize it into the development plan. Now, if IgvInitGetmain was formally documented, would CICS had as much flexibilty in deciding how do deal with this? I don't know, but that is an example of the kind of thing that has to be considered when deciding when to document some of the TRAPS. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Jim, as I stated in our problem record, the change to GETMAIN caused us downtime which is unacceptable in a business environment. Even though the interface to GETMAIN didn't change and, if programmers correctly initialized their workareas there wouldn't be a problem, the REALITY is that not all programmers initialize their storage, and not all source code is available for us to determine if there will be a problem (and to fix it if there is), I don't dispute any of the above. I have been specializing in problem diagnosis on MVS for almost 30 years, and am quite familiar with the realities of many classes of program bugs, including uninitialized storage. And while I am not aware of us losing any of the source code of MVS, we have had plenty of issues with trying to locate source code for old testcases and tools. so we, and many other installations will not be able to go forward with this change. Based on my experience so far, I think that many installations will not be able. is an exageration. However, that is only my opinion, and most certainly not a fact, and I will not be shocked if subsequent experience proves otherwise. Given the downtime consequences and the time required to diagnose the problem your installation encountered, your opinion is understandable, and only time will tell the extent to which either opinion proves to be correct. From a business standpoint, the dangers far outweigh the benefits. One instance of downtime in our production environment would cost too many dollars and would require us to back off the upgrade. Having no experience in being responsible for your production environment (or anyone else's), I am not qualified to offer an opinion on this subject. Any change to the way a major interface works SHOULD be documented whether the developer thinks that it will cause a problem or not. There is a lot of old code still running in production and installations need to know when things change. As I have said in another post, the developer did in fact think that this change would cause some latent program defects to become immediate problems, and that did not affect the question of documentation. The documentation issue is, where should we document a change to undocumented behavior, and what exactly should we say about it? It has been suggested that the Migration book would be an appropriate place to say something, and we are working on that. Exactly what to say remains problematic. I spent over two weeks of very intense debugging on this problem. In the interest of finding a silver lining for that cloud, consider that the problem you encountered was a program running in key 0 interpreting residual storage contents as an address, and overlaying key 0 storage. Consider the possibility that a malicious unauthorized program could find a way to arrange things so that the residual storage contained an address of something interesting in such a way that the resulting overlay would allow the malicious program to circumvent your installation's security controls. In that case you may have spent two very productive weeks uncovering a system integrity exposure so that it could be fixed. I am not saying this in jest. We take these things very seriously. That could have been avoided if we had been informed of the change at the T3. That was an unintentional oversight. We made a presentation to the ISVs who attended the Spring 2008 Technical Disclosure Meeting, and in my dotage, I confused that with IBM Level 2 education and T3. The Level 2 folks understandably shared your discontent. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Hi, OA2729 is a very interesting APAR and one that early adopters of z/OS 1.10 probably want to be aware of. DIAGxx option NUCLABEL ENABLE|DISABLE(IGVGPVTN) provides an immediate option for relief. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 (cell) 301.996.1318 Think big, act bold, start simple, grow fast... APAR Identifier .. OA27291 Last Changed 08/12/08 ABEND0C4 OR VARIOUS OTHER ABENDS, OVERLAYS, OR UNEXPLAINED PROBLEMS IN Z/OS R1.10 WHEN STORAGE NOT CLEARED ON GETMAIN Symptom .. AB ABEND0C4 Status ... OPEN Severity ... 1 Date Closed . Component .. 5752SC1CH Duplicate of Reported Release . 750 Fixed Release Component Name 5752 VIRT STOR Special Notice Current Target Date ..09/01/31 Flags SCP ... Platform Status Detail: DESIGN/CODE - APAR solution is being designed and coded. PE PTF List: PTF List: Parent APAR: Child APAR list: ERROR DESCRIPTION: A change was made in Virtual Storage Manager in z/OS r1.10 HBB7750 which results in different behavior when storage is getmained for user private subpools both below and above the line. This change can have a very negative effect in some cases. The following have changed: 1. Getmained storage which was previously cleared to binary zeros may not be cleared now. Programs which were counting on this without clearing the storage before use may exhibit unexpected behaviors. Depending on the contents of the uncleared storage and how it is used, this might result in abend0Cx, overlay of storage, or a variety of other problems. 2. Storage is now allocated from the bottom of the page up rather than the top of the page down. Programs that depended on the previous method for allocating storage may be adversely affected. 3. Newly gotten DQEs are merged with adjacent DQEs of the same subpool and key which are owned by the same task. Programs may be affected if they depend on the previous way DQEs were allocated, which is: A new DQE is obtained for each user private subpool getmain. The size is rounded up to the next full page size for any getmain which is not a full page increment. Also, those examining VSMDATA associated with problem diagnosis or other activities for which the previous pattern of DQE allocation is expected may be impacted because no conclusion can be drawn about a getmain size by the DQE size, FQE size, or DQE/FQE pattern because merging of DQEs hides these clues. Despite possible problems as a result of this change, there are certain environments, such as DB2 address spaces, which may benefit from the way VSM works in r1.10. DB2 or other applications which have previously experienced performance impact from getmain and freemain taking a relatively long time because DQE chains have become extremely long which may benefit from merge DQEs resulting in shorter chains. The potential performance enhancement as a result of merging DQEs may not be significant in those environments which do not typically have extremely long DQE chains for user private subpools. The fix to this APAR will restore the pre-release 1.10 behavior as the default to prevent impact to the unsuspecting program or user. A new DIAGxx trap will be documented by which those environments which will benefit from the new means of allocating storage for user private subpools can easily implement it -- and knowingly be aware of the possible impact to other programs. LOCAL FIX: To reset the r1.10 getmain behavior back to that used in previous releases until the PTF for this APAR is available, the following should be inserted in the running DIAGxx member of parmlib: NUCLABEL ENABLE(IGVGPVTN) When you issue SET DIAG=xx DQE merging will no longer be done, which is the pre-r1.10 behavior. To re-enable DQE merging again, put the following in DIAGxx and issue SET DIAG=xx again. NUCLABEL DISABLE(IGVGPVTN) This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
The fix to this APAR will restore the pre-release 1.10 behavior as the default to prevent impact to the unsuspecting program or user. A new DIAGxx trap will be documented by which those environments which will benefit from the new means of allocating storage for user private subpools can easily implement it -- and knowingly be aware of the possible impact to other programs. There is one incorrect thing in the APAR text - VSM development (and as designer and developer for this change, that includes me) has *not* at this time decided to restore the pre-release 1.10 behavior as the default to prevent impact to the unsuspecting program or user. The APAR will create a DIAGxx TRAPS NAME(NameToBeDetermined) which will be documented and, if specified, will cause VSM to revert to the pre-release 1.10 behavior, exactly the same way as the undocumented NUCLABEL ENABLE(IGVGPVTN) mentioned in the APAR description. The reason the change to GETMAIN Behavior in z/OS 1.10 is undocumented is that there is no documentation to change. GETMAIN in z/OS 1.10 continues to behave as documented. All previously documented rules of GETMAIN continue to apply to z/OS 1.10. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
