I was kind of disappointed when IBM initially gave the list of services that
could be called from AMODE 64.(as long as the parameters were below the bar).
I mentioned that the hardware does all the work for a PC from a 64 bit caller,
so stating "support" really didn't require any code changes. All my PC
routines equally supported 64bit callers.

On Mon, 13 Jun 2016 10:48:54 -0700 Ed Jaffe <edja...@phoenixsoftware.com>
wrote:

:>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).

--
Binyamin Dissen <bdis...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to