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
