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), so we, and many other installations will not be able to go forward with this change. 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. 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. I spent over two weeks of very intense debugging on this problem. That could have been avoided if we had been informed of the change at the T3. Jon
Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jim Mulder Sent: Monday, December 08, 2008 6:49 PM To: [email protected] Subject: 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 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
