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 [email protected] with the message: INFO IBM-MAIN
