As a guy who has wrestled with this sort of question as a lead ISV developer let me share my viewpoint.
Yes, I agree with @Peter and @Mark's general approach: decide how early a release of z/OS (or z/VM or z/VSE, if that's your thing) you are going to support -- presumably the oldest release that IBM is willing to support -- and then require at a minimum the oldest architecture level that it supports. Don't worry every time you code; set the level in the assembler (or C or COBOL or PL/I!) options and let the assembler catch your errors. Once in a while you may want to consider a particular new instruction as you code; that's where these spreadsheets and tables come in very handy. The new instructions are all goodness and faster than their alternatives, but I doubt that using one particular new instruction is going to make a world of difference in the speed of your code. If it's in a tight loop that is executed millions of times then -- and only then -- it might be worth dual-pathing your code. Once upon a time I used to worry "but what if there is some prospect out there with a z900 and a checkbook?" Well, I suspect there ARE shops out there with z900's but this just in: they are in "we're getting off the mainframe" mode and aren't prospects for new ISV software. And if I am wrong and one DOES show up with a large check then you can re-code and create a custom build just for them. One advantage of compiled languages as opposed to HLASM: no need to re-code, just change the ARCH() option and re-build. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Hammack Sent: Wednesday, May 15, 2024 8:28 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Instructions by Machine Just my 2 cents but this makes sense. A few years ago, my company (actually lead developer at the time and I) decided that we would "standardize" on supported versions of IBM operating systems. z/SO 2.2 had just gone 'end of life' and (per Peter's reference) required z10 hardware so that became our baseline. We set the zarch parameter in the HLASM configuration file and move on. That actually helped yesterday when I "accidentally" used an instruction (LFI) that isn't available until the z16. The assembler caught it, I changed my code and all is good for now. The only time we've checked (in the software) what hardware was available was back when 64 bit hardware was 'new'. Since some customers may have had 64 bit and others not, we created separate load modules for each environment and let a 'master' program decide which one to load.
