My motivation for MY text in the original post was simply to alert IBM-MAIN subscribers of the incompatible change in the assembler in z/OS 1.13 that our users, who presumably HAD read the Migration Guide, had encountered, and
after my search of the IBM-Main archives found no prior cites of ASCENV. My asmguy's explains his comments that I chose to include in my post: "I wasn't really complaining about anything, I was just explaining (in my perhaps less than elegant way) that the change required does not modify the code and therefore does not require reassembly for someone already running MXGTMNT. This type of thing affects us more directly than those who only distribute load modules and/or object code. For them the customer would never see this and it is merely an internal annoyance, for us it means a new ML. (ML=Maintenance Level of MXGTMNT because MXG IS 100% SOURCE CODE). While I agree I can't defend either of the practices he states I will still maintain that regardless of whether or not the assembler is told that the system is not in AR mode during OPEN/CLOSE it still could be (due to some coding error or assumption that the assemble can't know) and if it is OPEN/CLOSE will still abend and nothing has been prevented or avoided. I personally would prefer a warning like "You've specified that the system is in AR mode and this macro does not support that... are you sure this is correct?" While this warning would still be best eliminated, it doesn't require an immediate new source code member replacement for someone who is just trying to assemble MXGTMNT" Merrilly Christmas, Barry Merrill -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Peter Relson Sent: Monday, December 19, 2011 7:11 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS 1.13 ASCENV incompatible change in Assembler While it is admittedly unpleasant to have the system start enforcing requirements that it has documented, and I'll grant that we don't often make such runtime enforcement changes, here we are talking about assembly where it should be fairly easy to address, and might well help avoid a problem (as might happen if your ARs or register high halves contained some unexpected value) I'm curious whether the complaint is: -- My SYSSTATE does not represent my actual ASC environment or AMODE (or ARCHLVL or OSREL for that matter, although ARCHLVL and OSREL are not relevant to the macro changes being discussed) yet I expect macros to generate proper code that I can rely on working and continuing to work -- My SYSSTATE does represent my actual environment and I am invoking a service in an environment it is documented not to support but that I expect to work and continue to work -- Something else Aside from the annoyance, would anyone really defend either of those first two practices? FWIW, it was probably already mentioned that this information was conveyed to ISVs and is present in the migration guide. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- 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
