Keith, Most of what you are asking for is already available using AFI, ALFI, CFI, CLFI, LHI, LLILF, NOLF, OILF, and XILF.
It is not necessary to save anything in a GBLx array. It is just necessary to use the new instructions. I have raised the same issue on the z/VSE side. We need to have the system macros updated to make use of the machine instructions available in the minimum supported hardware architecture level for that release of the operating system. And yes, I know that doing so will create an issue for ISVs in that code assembled for operating system level n+1 may not run on operating system level n. So be it. I can live with that. John P. Baker -----Original Message----- From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On Behalf Of Keith E. Moe Sent: Sunday, August 22, 2010 5:34 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Suggestion for System Macros One of my pet peeves about many system macros is that some of them generate inline constants which they have to branch around. This not only generates an extra branch instruction which, while being unconditional, it's not a major slowdown in the pipeline, it means that the cache line has to be in both the instruction and data caches, even in reentrant code. I would like to see a system macro option that would cause these macros the save their "inline constants" in a GBLC array. This array would be used by a system "constant dump" macro which would generate the DCs for the accumulated constants. I'm not looking for the HLASM to generate them automatically like literals (many macros are now using literals anyway), but changes to the existing macros to do this. And, yes, if the user fails to code the "dump" macro or codes it where there is no addressability, I expect assembly errors. Keith E. Moe MAINVIEW for z/OS Support BMC Software, Inc.
