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'FFFFFFFF'. (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 -- Psssst! 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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
