Barry Maybe I am strange - but I welcome the new stricter approach to the SYSSTATE by IBM macros.
Anything that can flag up a potential problem in my code due to my lack of care of the declared environment seems very useful to me. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Barry Merrill Sent: 16 December 2011 15:20 To: IBM-MAIN@bama.ua.edu Subject: z/OS 1.13 ASCENV incompatible change in Assembler Change 29.280 -z/OS 1.13 ASM ERROR when assembling ASMTAPEE/MXGTMNT: ASMTAPEE "YOU SPECIFIED ASCENV=AR OR ANY ON THE SYSSTATE MACRO. Dec 15, 2011 THE OPEN MACRO SUPPORTS ONLY ASCENV=P." But there is NO NEED to ASM a new load module under 1.13; your currently executing MXGTMNT module works just fine! -This IBM note (migration guide) is the ONLY clue of the incompatible change, which impacts OPEN/CLOSE macros, but doesn't mention any by name: DFSMSdfp: Accommodate 64-bit & AR mode rules enforcement in DFSMS macros; required if you have code that invokes DFSMS macros (but not all!). Before z/OS V1R13, many DFSMS macros that did not support 64-bit or AR mode did not react to being invoked in 64-bit or AR mode, and generated code that might have been invalid in 64-bit or AR mode. Starting with z/OS V1R13, these macros are changed to issue an assembly-time message and suppress expansion if they are invoked in 64-bit or AR mode." -But as noted above, you didn't really need to ASM. Now, from MXG's "asmguy", his comments on this change: Nothing is going to happen to an existing site using MXGTMNT and in fact the modification I have to make for this does not result in any change to the executable code. The SYSSTATE macro is an assembler directive - it sets a flag that tells any macros that support AR mode (Access Register, used for cross memory access) to use their AR mode compatible expansion. Macros that don't have an AR mode expansion used to ignore this because they had nothing to do, and it's always the coder's responsibility to make sure that when those non-AR compatible macros are executed, that the system is not in AR mode. This is similar to switching back and forth from 24-bit to 31-bit mode: some macros can't tolerate 31-bit mode. Nothing has really changed though; it is still the coders responsibility to make sure the system is not in AR mode and macros that can't tolerate AR mode still can't, except now IBM is requiring the coder to explicitly set SYSSTATE to indicate to the assembler that the system is not in AR mode. Of course this is all very silly because the assembler can't know ahead of time that the system is or isn't in AR mode. So regardless of whether or not SYSSTATE is coded this way the system still could be in AR mode, OPEN/CLOSE will still expand the same way, and if the system really is in AR mode OPEN/CLOSE will abend when executed. So the bottom line is that nothing has changed except our need to do something for no reason at all. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
