-----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: Monday, August 28, 2006 7:08 AM To: IBM-MAIN@BAMA.UA.EDU Subject: IBM's "rights" (was Head's Up - zIIP issue OA17458/UA28419) <snip> >Roland's technique is very reasonable considering that for many >decades you did not provide any of us with an alternative. Thank you >for finally providing SYSSTATE_OSREL. Did anyone ever ask for this sort of thing before you did via a formal mechanism? You're certainly far less likely to get what you want if you don't ask for it (not that asking for it will necessarily get it for you) <snip>
Peter, there seems to be a problem w/in IBM these days now that the old guard has been retired or otherwise pushed out. Somebody has managed to shred the IBM Internal Software Development Standard Manual that I had to work to back at STL when I was working as a contractor on AI products. As a result, you come along and make a statement that just makes me think back to a certain cartoon with the caption of "Bummer of a birthmark, Hal" (Far Side). But back to STL days for me: One of the problems that we had was that IBM internally did NOT follow their own rules for SPLEVEL. It seems that the declarative macros flatly ignored this and so a certain product, during pre-release (prior to BETA) crashed a system because the expansion by an ESA (SP3) system was LARGER than for an XA (SP2). The PROBLEM was, we had just been moved from Palo Alto to STL, lost our 3084 XA machine and were using a guest MVS/SP3.1.3 system (under VM). We had to change our code to KNOW when it was actually XA and when it was SP3.1.3. Notice, this was IBM internal development having this problem. Then, you come along and state that IBM can change anything they want at any time relative to field names and their contents (that was what you said, wasn't it?). Well, when it is specifically stated as part of a programming interface, there is a problem and then this violates the old standards manual (which at that time, we had to get a blessing from someone in NY to do different). In fact, some of those things could not be touched until or unless we had a VERSION change. Next, looking at the disclosure meetings with the ISVs, blind siding them only causes IBM problems because IBM customers WON'T upgrade the OS when the products they depend on can't run at that new level. Lastly, changing such a thing with a PTF so that ISV products break generally causes a CRITSIT. Perhaps you might want to re-think your attitude. Maybe you might want to go talk with Bob and John for a few minutes (assuming they are still with IBM, which AFAIK, they are). Later, Steve Thompson ---------------------------------------------------------------------- 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
