>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.
I cannot speak for development outside of Poughkeepsie. We have always known our responsibility for compatibility. And yes we have screwed up on occasion. I believe such occasions have been rare. I wonder what you think the "rules for SPLEVEL" were. >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?). No, that is not at all what I said. Nor would I ever make any such statement about the contents of fields or about *removing* field names. My ONLY statement was about adding a field that is 100% compatible except for the fact that someone was using the presence or absence of that field to think that meant something about the release of the macro library which it did not. >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. What "blindsiding" are you referring to? We disclose everything that we think is or even might be relevant and we have tried for decades to get the vendors to tell us what their dependencies are on undocumented things so that we can do a better job. We appear to be making some headway there, but the result will never be any better than the information we get. >Perhaps you might want to re-think your attitude. You ought to re-read my appends. You are way off base. I can guarantee you that no one thinks more about compatibility than I do. 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
