If you run a windows app using visual studio debugger you will see all code run in 64 bits
On Thu, Aug 7, 2025 at 8:30 AM Tom Harper < [email protected]> 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. > > 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. > > Tom Harper > > Phoenix Software International > > > > > On 8/5/2025 5:56 AM, Peter Relson wrote: > > <snip>I repeat, RMODE is irrelevant unless specifically mentioned in the > doc. The OP said it was not mentioned in WTO, therefore RMODE is > irrelevant!</snip> > > Sorry, but very wrong! > > If RMODE 64 is not mentioned, then you are expected NOT to invoke the > service from a program above 2G.This is the same as: if AMODE 64 is not > mentioned, then you are expected NOT to invoke the service in AMODE 64. It > is similar to: if data above the bar is not mentioned as valid even if > AMODE 64 is valid then you are expected NOT to use data above the bar. > > Might an RMODE 64 invocation work? Yes. Fairly likely if the service is > SVC-entered or PC-entered, not as likely if it is branch-entered.Might an > RMODE 64 invocation stop working (i.e., break) at any point in the future > (including. albeit unlikely, in service)? Yes > > Even in the cases where it appears to "work", not everything might be as > desired (such as diagnostic data about the return address of a caller > within a log or trace or message) > > If you want to risk it (and put your customers at such risk), that > cannot be stopped. > > <snip>The only 2 services that are documented as RMODE64 are load and > synch > > </snip>That is not correct (i.e., it is incomplete)For example, GETMAIN > documents: > > | RMODE: | For SVC-entry, includes 64-bit | > > > > > > Peter Relson > > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > -------------------------------------------------------------------------------- > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system > into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. > > ---------------------------------------------------------------------- > 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
