It's worse than that. Programs that do an ATTACH can test dynamically, but not programs that do a CALL to a routine in the same program object. The call needs to know whether to use XPLINK.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Paul Gilmartin <[email protected]> Sent: Saturday, August 9, 2025 9:41 PM To: [email protected] <[email protected]> Subject: Re: RMODE64 services External Message: Use Caution On Thu, 7 Aug 2025 08:35:07 -0400, Joseph Reichman wrote: >If you run a windows app using visual studio debugger you will see all code >run in 64 bits > Good example of courageous design. Look forward, not back. >On Thu, Aug 7, 2025 at 8:30 AM Tom Harper wrote: > >> I have a considerable amount of experience with this issue on z/OS (not >> other z operating systems). Since z/OS introduced 64-bit support nearly >> twenty-five years ago, it has gradually and ever so slowly been filling >> in the gaps. >> Is IBM in a quandary? For over a half century it has been true that (almost) IBM languages used a uniform call interface, that generated by the CALL macro and the initiator used the same interface so any program used as a job b step could equally be called as a subroutine. Suddenly there are two interfaces which must be supported: PLIST8=YES for support of data in any location, and PLIST8=NO for support of programs using the traditional interface. The choice can not be made statically as there is no way to discern ANODE of a subroutine at translation time. Dynamically, the decision can be made during execution by examining the AMODE of the called program object. The initiator *could* do that. The BPX1-BPX4- replication is a desperate accommodation. >> And one of the last gaps to fill in is RMODE(64). >> >> As others have pointed out, the documentation about RMODE(64) is >> somewhat lacking. >> >> There are a number of what I think are curious issues, like 64-bit latch >> support, which allows 64-bit parameters, and AMODE(64), but no RMODE(64) >> support. Like most services invoked via an instruction other than an SVC >> or a PC, support has not been added for returning to an RMODE(64) bit >> caller. I believe most of these could be changed with little effort and >> testing, but IBM has other priorities like AI and containers. And most >> services that do invoke via a PC or SVC do not document RMODE(64) >> support which means it is not supported. >> >> Others are more subtle, like not allowing SPLIT load modules to be >> loaded into ECSA and above the bar storage. Another is lack of 64-bit >> PC support using ETDEF. Recovery is another area where RMODE(64) bit >> support is lacking. IPCS does support 64-bit storage access, however >> awkwardly, but none of the IPCS services may be invoked in AMODE(64) nor >> RMODE(64). >> >> To address these issues, I have submitted a significant number of IBM >> "Ideas", and after getting some additional questions on them from >> clueless IBM responders, have finally had most of them with a status >> changed to "Future Consideration", the queen of vague terms. Still, I'm >> an optimistic person and have hope that these will be changed in future >> releases. >> >> At the last SHARE meeting at the closed IBM session, I did vigorously >> point out that their RMODE(64) support was sorely lacking. I could see >> them taking furious notes, but I'm too old to be intimidated. Hopefully >> the notes were to take back to their development teams. I pointed out >> that many of these could likely be resolved by changing a single >> instruction. >> >> At any rate, in the fullness of time, perhaps we will see some attention >> paid to this issue by IBM. >> >> So, if this issue interests you, go to the IBM "Ideas" portal and vote >> if you think these ideas should be considered. I personally believe that >> RMODE(64) support will enhance the value of z/OS going forward. The >> hardware people have done their job well. Let's hope the software side >> can finish the task at hand. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
