Really? You violate interface requirements and then worry about problems 
that ensue? 

You are supposed to issue SYSSTATE AMODE64=YES to indicate that you are 
AMODE 64 if invoking z/OS macros. Period. Is this new news to anyone? It 
has been this way ever since AMODE64 was supported in any fashion (20 
years or so).

If you violate the requirements of issuing z/OS macros (and calling 
services) then you get what you get. I  have no sympathy.

In my opinion, the OP is likely mistaken. There has been no change to the 
ESTAEX macro (and thus likely no change to its expansion regardless of 
what SYSSTATE you might or might not have set). I write "likely" only 
because there could be some underlying macro that changed. I do hope that 
the OP's code, in AMODE 64 but not indicating so, has made sure that the 
high half of reg 14 is 0 to avoid unpredictable and unpleasant results. 
Perhaps the OP could post his exact invocation and (ideally) the 
expansions in 2.3 and 2.4.

As to Charles M's point, AMODE ANY as defined for z/OS does NOT include 
64. It is for 24 or 31. 
Yes you could theoretically write code that runs in either AMODE 31 or 64. 
That is generally not a great practice if for no other reason than that 
linkage requirements differ. Capping to AMODE 64 is usually a better 
approach.  As to what do you specify if you do have code that is AMODE 31 
or 64? You might have to dual-path, you might specify AMODE64=YES. You 
certainly don't specify AMODE64=NO. That must be pretty obvious (otherwise 
you don't get things done like clearing of high halves of registers). 
SYSSTATE is about assembly-time checking. Differences needed at runtime 
are left to you.  An analog is ASCENV. Although undocumented, a value of 
"ANY" is allowed which is treated the same as ASCENV=AR -- the expansion 
is "safe" if you are in AR mode, causing no (or only little) harm if in 
primary (unnecessarily setting ARs, for example).  I was young when I 
implemented that over 30 years ago and didn't have the influence to say 
"no" to those who wanted an "ANY" option even if it did nothing unique.

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

Reply via email to