On 6/13/2016 10:12 AM, Andre Schoeman wrote:
Since the documentation for IEAMSCHD says that AMODE 64 is not supported,
you are taking a risk that your code might at any point stop behaving
properly. That is your choice, but it is your (and your users') risk. Is
there any plan to do so in the immediate future? Not that I know of. Would
any such plan be announced? Probably not.
I accept what the current state of the documentation says. However, when
z/OS is touted as 64-bit capable, shouldn't a continous effort be driven whereby
all invoked system system services eventually are AMODE(64) capable ??
(disregard the restricted location of certain control blocks for now .... I'm
merely referring to invoking a service whilst running in AMODE(64))
I have stated before (possibly in other forums -- certainly at TDMs)
that our approach is to try to help IBM and the z/OS community identify
existing system services that don't work for AMODE(64) callers. IBM has
only limited manpower to test z/OS services, so we test them for them by
invoking them in real-world AMODE(64) code.
That means we completely disregard documentation that states a service
requires 31-bit mode and rely solely on the results our own empirical
testing. (Of course, we limit AMODE(64) invocations to SVC and PC-based
services and never even try to invoke LINKAGE=BRANCH services in
AMODE(64) because we know that won't work.)
What we've discovered is that _nearly all_ SVC and PC-based services
work just fine so long as you pass the parameters below the bar. The
main "gotchas" are macro expansions that have not yet been updated to
use grande instructions when SYSSTATE AMODE64=YES is in effect. Usually,
all you must do is clear XGR 14,14 (or another register) before invoking.
Is it a risk? Of course! IBM is free to change these interfaces at any
time without warning and we're happily prepared to adapt our code as
necessary in the event the macro expansion changes or they choose to
support AMODE(64) callers in an incompatible way (hopefully on a release
boundary).
For us, improved performance, better code readability, and (hopefully)
fewer changes down the road when those services finally do "officially"
support AMODE(64) callers, are worth that risk. YM-AS-MV (Your Mileage
-- And Sensibilities -- May Vary).
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN