<snip> My favorite (not!) is MODESET which generates (IIRC) in-line data and a branch around it and a LOAD from storage. I know it is nothing but it just annoyed me so much that I created my own that uses LHI and no branch. </snip>
Did you ever mention that to anyone who might have been able to address your disfavor? I suspect not. Having our own MODESET macro, you'd be unhappy if MODESET ever chose to use any of the first 16 bits of its flag word, if you ever wanted to use whatever new option did so. And of course the macro was written years (decades?) before LHI was available and, until there was no chance of someone using that macro to run on an older system, changing to LHI would have been unacceptably incompatible. Most developers choose not to spend their time looking for "what did my predecessor do that works but could have been done better". So if there's any chance of it getting changed, you'd have to bring it to our attention. Would it have been done? Who knows. Will it be done? Maybe. I can at least say that we no longer feel there to be any impediment to unconditionally using anything in base z/Architecture (and of course the relative/immediate instruction set pre-dates that). We will not typically use by default instructions that correspond to a release's architecture level set, because a product might compile with the "new release macros" but run on an older release. But if dual-pathing were deemed worthwhile, the macro could rely on the SYSSTATE ARCHLVL value set by a program. Peter Relson z/OS Core Technology Design
