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
