Re: SYSSTATE (was Abend 052-512)
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
Re: SYSSTATE (was Abend 052-512)
If you are writing code for only your own shop, this version of SYSSTATE is pretty handy, as it keeps up with your system: SYSSTATE OSREL=SYSSTATE,ARCHLVL=OSREL For software to be distributed elsewhere, then don't do that; unless you're willing to bet all targets are always equal or greater than your z/OS level. sas On Mon, Feb 11, 2019 at 11:02 AM Peter Relson wrote: > (Everyone should do this) > > Help the poor macros out. Tell them via SYSSTATE OSREL and ARCHLVL what > the macros are allowed to assume. > Unless you like lousy code. > > The XM services were written when non-stacking PCs were the only thing > available and the interface for non-stacking PC requires various hoops to > be jumped through. But those PC's were changed to stacking many releases > ago (z/OS 1.6). > > For the most part we try not to assume things about what release you might > be running your code on, and thus the default remains to expand the way it > originally did. But you almost always know better. Share that information. > Unless you like extra STM, ESAR, SSAR, LM in your expansions. At a > minimum, pick the oldest release your code might run on. If that oldest > release is older than z/OS 1.6, perhaps you could consider changing your > business model. > > 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 > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SYSSTATE (was Abend 052-512)
(Everyone should do this) Help the poor macros out. Tell them via SYSSTATE OSREL and ARCHLVL what the macros are allowed to assume. Unless you like lousy code. The XM services were written when non-stacking PCs were the only thing available and the interface for non-stacking PC requires various hoops to be jumped through. But those PC's were changed to stacking many releases ago (z/OS 1.6). For the most part we try not to assume things about what release you might be running your code on, and thus the default remains to expand the way it originally did. But you almost always know better. Share that information. Unless you like extra STM, ESAR, SSAR, LM in your expansions. At a minimum, pick the oldest release your code might run on. If that oldest release is older than z/OS 1.6, perhaps you could consider changing your business model. 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
