In a separate thread, Mr. Ramaekers inquired as to how to determine if an instruction is present on a processor. I was frequently asked this when I worked for the Systems Architecture department at IBM, and there is no succinct reply ... because it's REALLY tricky.
In days of yore, one approach was to perform a test execution of the instruction and be tough enough to take a punch on the chin (i.e., be able to endure the ensuing operation exception if the instruction wasn't present). This was a bit of a hassle, as you had to establish some sort of recovery environment (e.g., a SPIE macro) to catch the program-interruption code 1 (PIC-0001, i.e., S-0C1 in z/OS speak). For reasons described below, this is no longer an adequate means of determining whether an instruction is present in a configuration. Take a look at the Summary-of-Instruction figures (toward the front of each chapter in the PoO that describes instructions ... Chapters 7-10, 14, and 18-25). In the 3rd sub-column of Characteristics column, you'll find symbols representing facilities that introduced instructions. If the field is blank, the instruction is present in all ESA/390 and z/Architecture machines; if the field contains "N", the instruction is new to z/Architecture; and if the field is "N3" the instruction is new to z/Architecture but retrofit to ESA/390. Any other code represents an instruction that was added to z/Architecture; depending on your configuration, such instructions may or may not be present in the configuration. Most of these facilities are summarized in the section "Additions to z/Architecture" beginning on page 1-7 of the latest PoO (SA22-7832-11). For each facility listed, there is a date when the facility first became generally available. Some clever folks at IBM compiled a table of which machine came out when, and attempted to identify corresponding facilities. For example, the transactional-execution (TX) facility was introduced in September, 2012, which corresponds with the zEC12. So if I'm running on a zEC12, I can axxume TX is available, right? Nope, this would be a wrong assumption for multiple reasons, as I describe below. z/Architecture introduced a kinder and gentler way of determining whether a facility was present in the system in the form of the STORE FACILITY LIST (STFL) instruction. However, STFL was itself under-designed in that (1) it is a privileged operation, (2), it stores its results at real location C8 hex (which cannot be inspected by applications running under some OSes like Linux), and (3) it can only indicate the presence 32 facilities. If you're running on a z9 or better, the ideal solution is STORE FACILITY LIST EXTENDED (STFLE) which suffers from none of the limitations of STFL. So, if I'm a tough guy who can take a punch on the chin (i.e., a PIC-0001 attempting to determine if an instruction is installed), what's the matter with that? If your program never executes in a virtual machine, you're may be okay (one final caveat later). However, if your program could ever run in a virtual machine, you may be subjected to a feature called live-guest relocation (LGR). LGR allows a program to begin execution on one physical processor, and then — for any number of reasons such as workload balancing, recovery, &c. — be dynamically dispatched on a different processor. These two processors don't necessarily have to have the same facilities installed! The STORE FACILITY LIST EXTENDED (STFLE) instruction is designed to account for the live-guest-relocation feature; STFLE will report as installed only the facilities that are common to both configurations. That is, STFLE dumbs down the response so that there are no surprises if you're dispatched on a different CPU. If you determine that an instruction is present using the punch-on-the-chin approach, you may be unpleasantly surprised if your program is redispatched on a different CPU that doesn't have the instruction. STFLE is also clever enough to correctly report the sub-facilities that are indicated by such multiple-function instructions that have query functions ... for example, the various message-security-assist (i.e. crypto) instructions. Some of these functions may not be available on newer machines (and some of them are hobbled due to export regulations). However, there is one last place where even knowing whether an instruction is installed may not be sufficient to exploit it. There are a few facilities such as the transactional-execution facility or guarded-storage facility that may be available (as indicated by STFLE), but require operating-system support to provide the facility to an application program. If an older OS does not enable such a facility (usually by means of a control register), then STFLE may indicate that it's installed, but attempted execution will result in an exception (often, a special-operation exception). For such facilities, the operating systems are responsible for providing some sort of indication that the facility is supported ... either in a bit in a commonly-accessible block or via a system call). Whew! Probably not what you wanted to hear ... but as I said, it's tricky.
