History of SPLEVEL, in case anyone cares. SPLEVEL was not intended to have anything to do with the release/version designation such as "SP 1" or "SP 2" or "SP 3". But the values made it seem like it might. And our documentation and commentary contributed (maybe completely caused) the confusion.
Coincidentally, the very first time that it was created, was for MVS/XA which happened to be SP2.1.0. They decided that the initial value ("default", if you will) should be 1, so the "next" value was 2. The "next time" this happened ended up being SP3.1.0. Sigh. A value of 3. The "next time" was SP3.2.0 (value of 4). But oops: before we shipped the release, it morphed to SP4.1.0. Then the owners of SPLEVEL continued to compound the problem and updated it for release 5 and changed it again for OS/390 (though in release 2, not release 1), even though there were no macros that needed that sort of differentiation. It was certainly true that the intent of SPLEVEL was to ask for an expansion of an otherwise-incompatible executable macro that could be executed on a previous release. And the way that was implemented was to keep (and rename) the 'old macro' and have the 'new macro' route control to the 'old one' when SPLEVEL indicated it needed to do so. These 'old macros' still exist! ATTACH7, ESTAE7, SETFRR7, SETLOCK7 are examples. The reason for the incompatibilities was usually architectural (4-byte pointers rather than 3, for example) but occasionally structural (lock restructure, which resulted in SETLOCK8), Without this approach (and without the old macros) there was no way to compile with "new macros" and get expansions that worked on "old releases". The introduction of SYSSTATE and a (admittedly too loosely recognized and/or enforced) requirement that "if you just recompile without changing keywords or environment, your expansion should continue to work on the release you coded it for" put full control in the hands of the coder. If they wanted an expansion that worked for release X, they could do so by coding only parameters that were supported by release X. And they could dual- (or multi-) path their code using the CVT feature bits as needed. And of course it's that last point that can lead to dire consequences when we screwed up by having the "z/OS 1.7 feature bit" on within the zIIP PTF for z/OS 1.6 (that PTF also known informally but definitely not officially as z/OS 1.6.1). It's pretty obvious that if you are misled by the feature bit and go down a path that is supposed to be for "release X+1" but you are really on release X or earlier, various bad things can happen. Among them: You try to use a service that doesn't exist. If you're lucky, the branch-entry or PC entry will blow up and cause no further harm You try to use a "new option" on a service which doesn't support that option on this release. If you're lucky, the service will report that you're trying to do something it doesn't understand and reject your call You use some new field in a control block that is beyond the end of the control block that existed for release 8. If you're lucky, you blow up because the storage out there isn't allocated. More likely, if you're semi-lucky, you get 0's and do no harm; Quite likely, you're not lucky at all, you get some "random" value which causes your program to misbehave. Obviously the "misbehavior" can result whether the new field is within or beyond the bounds of the "old release's" control block. And obviously "misbehave" is a very nice way of saying "might cause catastrophic damage". I'm curious what other cases you have thought of. Any thoughts? The reason I ask is that sometimes there are options in implementation. One choice might lead to "need to dual-path your code". Another might not (usually this is a more expensive choice, but can sometimes be worth it). The better we understand things when we make these choices, the better our choice-making is likely to be. 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