>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
