IMHO that is a very useful way to think about and organize the available instructions. The reference to the architecture level table in the z/OS Planning guide is most helpful.
Merging that organization with the HLASM OPTABLE outputs might also be of some use, though I suspect there may be some overlap in the different sets represented (HW vs SW). Thank you. Peter From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Peter Relson Sent: Wednesday, May 15, 2024 10:28 AM To: [email protected] Subject: Re: Instructions by Machine 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://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/3.1.0?topic=system-identifying-server-requirements__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!M-D-ycXX5K7Z-0gaeNo727lLb-FpcNwHcZhrQOY_zK8xZPKIYNiChNsJtpdEmteOydR6KdjmNepTQCIVXIeq$<https://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/3.1.0?topic=system-identifying-server-requirements__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!M-D-ycXX5K7Z-0gaeNo727lLb-FpcNwHcZhrQOY_zK8xZPKIYNiChNsJtpdEmteOydR6KdjmNepTQCIVXIeq$> 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 -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
