This was the best way to detect the level of operating system at assembly time.
So I was able to assemble at the highest level and run it on "several" older
version. Also this works for several years (+10 or even more).
Well checking the runtime wouldn't assemble clean if running on older version.
AIF (NOT D'CVTH7720).SPLVL31S
TM CVTOSLV5,CVTH7720 z/OS R7?
JZ SPLVL31S no, jump
Wlll look at the SYSSTATE TEST as this sounds to be a very good idea
Roland
-----Original Message-----
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson
Sent: Saturday, August 26, 2006 10:05 PM
To: [email protected]
Subject: Re: Head's Up - zIIP issue OA17458/UA28419
I can only say "I am astonished" that someone would code based
on the presence of a field name. We have every right to define
fields in any level of macros that are convenient.
This will almost certainly not be changed.
For what it's worth, you can probably use
SYSSTATE_OSREL, created via SYSSTATE TEST as of z/OS 1.8 (and
shipped also into JBB77S9 and JBB772S) to indicate the release
of the macro.
If SYSSTATE_OSREL has no value, then your old check will
probably work (no guarantees). If it has a value, then consider
using it.
This issue really has nothing do with the APAR, which is hiper,
and refers to the fact that the bit CVTZOS_010700 / CVTZOS_V1R7
/ CVTH7720 (they're all the same bit) is incorreclty on, so
any runtime determination looking for "am I on z/OS 1.7 or
later" would be misled.
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
