Steve Smith wrote: >SYSSTATE OSREL=SYSSTATE,ARCHLVL=OSREL I agree with Steve. That is what we use for code applicable to the new z/OS release. At least for the cases where we know that the code will be running on that release (an exception being such MIGLIB things as IPCS-related parts that might run on an earlier release)
z/OS 2.3 introduced the concept of OSREL=MIGLIB which you might think of as the oldest in-full-support release at the time of GA of the release (which was z/OS 2.1 as of z/OS 2.3 GA). Anyway, the mild caveat is that these work if you have only one release in play. A lot of customers (especially during migration) have multiple releases in play. A point: if you invoke z/OS macros, you should expect to provide addressability to static storage (such as where a LTORG might put something). Relative branch might get rid of the need for inlined data, but (even with the immediates) does not intend to get rid of the need for static data. Over time, some macros will "move up" to something more current (even "relative branch" is more current that most defaults) even without a SYSSTATE specification (in particular when not doing so would be more costly than doing so). But my view is that we would not move up to "fully current" because we still want you to be able to compile with the "new release's macros" but run on older (but supported) releases, and typically more releases than are under full support. So for example, a macro might well move up to "assume z/Architecture" but likely not "assume zEC12 instructions" (which are part of the z/OS 2.3 Architecture Level Set) or usually not even "z10" instructions (the z/OS 2.2 ALS) or "z9" instructions. There are likely exceptions, but that's the general thought. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
