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
