Just my 2 cents but this makes sense. A few years ago, my company (actually lead developer at the time and I) decided that we would "standardize" on supported versions of IBM operating systems. z/SO 2.2 had just gone 'end of life' and (per Peter's reference) required z10 hardware so that became our baseline. We set the zarch parameter in the HLASM configuration file and move on. That actually helped yesterday when I "accidentally" used an instruction (LFI) that isn't available until the z16. The assembler caught it, I changed my code and all is good for now. The only time we've checked (in the software) what hardware was available was back when 64 bit hardware was 'new'. Since some customers may have had 64 bit and others not, we created separate load modules for each environment and let a 'master' program decide which one to load.
At some point, we may decide to bump the architecture up in the HLASM config, but I'll probably be retired by then. *Mark Hammack* On Wed, May 15, 2024 at 9:28 AM Peter Relson <rel...@us.ibm.com> wrote: > Mike Shaw wrote > > <snip> > > This _gold_ for ISVs writing code that must execute on many different z > > models. > > </snip> > > Thanks to Dan and Yves for all the work. > For Dan's, I'd suggest (somehow) adding a "key" to the 2-character > facility names (I know most of them, but many might not, so it could be > helpful to have the "long name"). I couldn't see "which facility" in Yves' > table (and I think that's really important because even if it's on a > machine that doesn't mean you can use it on a given OS or even a given > environment for a given OS) > > I'm curious in exactly what way this information on a machine basis is a > lot of help. I certainly agree that it's nice to know what instructions you > are "free to use". And for that, having the information by facility is (to > me) most helpful. > > With or without the opcode table, you still likely need to pay attention > to architecture level set (which is not by machine, but rather by facility). > For z/OS, that is documented here: > https://www.ibm.com/docs/en/zos/3.1.0?topic=system-identifying-server-requirements > within Table 1. Minimum server levels and machine facilities that are > required for z/OS > > Most cases I would think would choose to limit their instructions to those > available in facilities known (by architecture level set) to be available > on all the releases you are choosing to support. And something done "if > available" would be checking the facility bit at run-time. Is anyone really > looking at "machine model" to determine availability of an instruction? > That would not ordinarily be a good idea. > > If I were creating this for z/OS, I'd like a table of "show me all the > instructions I know that I can use for each z/OS release" (with an > indicator, perhaps, of which were added since the previous release). That > gives you the direct way to see what you can rely upon being available, for > whichever you choose as your oldest release. Maybe that's just me. > > Peter Relson > z/OS Core Technology Design >
