>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))
It would be nice to be able to answer "yes". Everything we do, and likely everything you do, is based on a business decision. Would you prefer we spend time working on that versus providing function that you can't accomplish on your own? >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. We have tried, largely unsuccessfully, to get from ISVs a list of services most important to them in this regard, so that a prioritized list could guide any implementation effort. I presume you are talking about entry in AMODE 64 but not data above 2G. The cost of having many services (especially older ones) support data above 2G is generally deemed to be too high for the value. >The main "gotchas" are macro expansions that have not yet been updated to >use grande instructions when SYSSTATE AMODE64=YES is in effect. Anything that takes the approach of accepting an AMODE 64 caller while assuming that data is below 2G cannot then compatibly be expanded to accept AMODE 64 with data above 2G. It could do so only by the user indicating some new option and possibly going to a new entry point. For example, suppose the existing service uses only the low half of register 1 to address the parameter list. Then suppose the service accepts an AMODE 64 caller only by changing the macro's instructions that chain through a control structure to locate the SVC number or PC number. It is now possible that the service is entered with register 1 high half containing garbage. That is OK until the target routine might want to code "if caller is AMODE 64 then use 64-bit register 1". It can't do so compatibly. The caller would need to indicate "you may use 64-bit address" and we would probably do something similar to what some DFSMS services did, in setting register 1 to some value that could not logically be a parameter list address, and putting the parameter list address into some other register. The target routine would check if register 1 is the special value to determine where to get the parameter list address. Thus we tend to be quite conservative about this sort of change, to avoid locking ourselves into an implementation. If we have left the service "not AMODE 64" then it would be compatible to implement "if AMODE 64, then the parameterlist and/or data can be above 2G". Are we all that likely to enhance our older services to support data above the bar? Not in most cases. But it's hard to know for sure. 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
