Let me speak as a vendor here. There are two issues. You can tell the C/C++ compiler both the minimum hardware you intend to support and the most typical hardware you intend to run on. So it uses only instructions available on that minimum hardware and chooses instructions that work best on the typical hardware. We build our product "usually" ARCH(9) TUNE(10) -- that means we require a minimum of a z196 but run best on a BC/EC12. One of these years we will up that to ARCH(10) TUNE(11).
The wonderful thing about a compiled language is that we have the occasional POC or customer who is on a z9. No problem -- we just do a recompile and a special build for ARCH(7) TUNE(7). Any assembler routines in your product are a different matter. You can't "just reassemble ZS-2." So we always build all our (minimal number of) assembler routines ZS-5 (z9). You lose a lot of great instructions, but c'est la vie. (The C ARCH numbers are two behind the marketing numbers: a z13 is ARCH(11). The HLASM MACHINE numbers are four behind: a z13 is ZS-9.) The software checks and detects if it is compiled ARCH(9) but you are trying to run it on a z10, and exits gracefully, without ever getting into C code compiled for a z196. You also tell the C/C++ compiler and the binder the minimum level of LE to target. We tell the compiler TARG(LE,zOSV1R13) and it squawks if you try to use a function not available until later. At this moment I do not know what happens if you try to run on V1R12: I would hope that the LE runtime squawks, albeit probably in the most obscure way possible. If you had a vendor product problem in this regard then my guess is that it was carelessness on the vendor's part. Possibly an oops on IBM's part, but I think the vendor's part is more likely. We regression test on all of the levels of z/OS we claim to support. We do some hardware level testing, but not much, and have not had an unexpected problem with hardware levels -- or z/OS versions, for that matter. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Sunday, November 5, 2017 8:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C/C++ Runtime Library Just a thought. >From a vendor perspective I would think you would need a test in your process >to verify that the microcode/firmware and LE runtime libraries will work for >that shop. For example, if you use XYZ in C language but that support did not show up until z/OS V1.12. The shop installing the code is at z/OS 1.10. I would think that would cause an error for the customer. I had a case with a vendor product, where the developer used a cool new instruction. Unfortunately it was for a higher level of firmware than the CPU we were running on at the time. This caused an S0C4. This required a SEV1 immediate fix situation. I am not sure how much testing in the code that vendors need to do to support any level of hardware or software for their products. But I would think some would need to be done. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
