What is still missing is a reason why someone should want to do this sort of check. Only with that information could one answer a question such as "should we also check CVTVEF?". Checking CVTVEF will tell you if the vector extension facility is present *and* that that operating system is prepared for you to use it. Seeing CVTVEF on will tell you that you are on a suitable machine with a suitable operating system; seeing it off provides no information about the machine itself. If you are looking "may I use this facility" then you should be looking at the facility bit for that facility and/or the operating system bit for that facility.
Of course some of the architecture levels will no longer be associated with supported releases once z/OS 2.1 is the last supported release. Charles Mills has a reason. But part of that reason is that he's running in an environment that he cannot control (and hence cannot set a reasonable recovery environment to accomplish the functionality that he was challenged to provide). He asked for a specific value. Such a value might be reasonable for the operating system to provide. I'm actually curious if you can tell at runtime what C/C++ ARCH level was this module compiled at. Otherwise, why would you want to know what the ARCH level would be if you were to compile "now". Perhaps this is instead a piece of data provided by the module itself, in which case it could provide "something else" (such as the machine generation number) to correlate to some new operating-system-provided field. What are you actually trying to accomplish with the tests of the facility bits to determine machine? I wouldn't expect that a customer would need to be told what machine they are using. Are you bringing in different levels of your product at runtime based on which machine you find you are running on? If you are, for z/OS 2.2 and up you might check out the IEFOPZxx support that was mentioned in the z/OS 2.2 announce and that is expected to be available on or about December 10 (documentation will not be available until the general availability, but this has been disclosed to ISVs). - Long displacement facility is viewed to be part of z900 (as Jim Mulder indicated). - LD High Performance is part of z990. - Extended immediate - z9 - General Instruction Extension - z10 - Decimal Floating Point - z9 - Decimal Floating Point High Performance - z10 - High word (etc) - z196 -- note that the 4 facilities are all represented by a single bit, so it would be foolish to test them all individually - Execution hint - zEC12. Same bit as miscellaneous instructions extension. Load and trap - not part of any architecture, just another name for this bit - Transactional execution - zEC12 - Vector Extension Facility - z13 - DFP Packed - z13 - Load store on cond 2 - z13 - CTEND But as I had mentioned you will not find the transactional execution facility bit (or the CVTTX bit) on if running z/OS under VM. So what are you accomplishing with a test of this bit to indicate some machine? And the same might be asked for some of the others. The bits (sometimes coupled with an operating system bit) are in general intended to be used to answer "is this facility available for my use?". Jim mentioned the "virtual architecture level". There is such a value in the SCPINFO. Its architectural definition might be enhanced in the future to provide the "sort of" information that is being asked for. I say "sort of" because its value range starts at one for z196 (and it will likely never "skip values" in order to get up to "n" for "machine generation n". Currently, VAL+10 = machine generation. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
