I just tried wto from rmode64 It’s not that complicated if the service requires 31 bit and you are in rmode64
Just bassm to it the storage macro is available in rmode64 to get the parms 31 bit I had 64 bit parm used storage to get a 31 bit address moved to 64 bit address to 31 bit and called it from 64 bit Joe Reichman On Tue, Aug 5, 2025 at 10:38 PM James Mulder <[email protected]> wrote: > The documentation for the STORAGE macro says: > > RMODE: For LINKAGE=SVC and LINKAGE=SYSTEM, includes 64-bit > > Jim Mulder > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Jon Perryman > Sent: Tuesday, August 5, 2025 8:45 PM > To: [email protected] > Subject: Re: RMODE64 services > > On Tue, 5 Aug 2025 12:56:02 +0000, Peter Relson <[email protected]> wrote: > > >Sorry, but very wrong! > >If RMODE 64 is not mentioned, then you are expected NOT to invoke the > service from a program above 2G. > > We loved IBM DOC because it was always consistent. It's sad IBM DOC has > become inconsistent. We still have 24-bit requirements listed from when > AMODE 31 was added to each service. It allowed us to remove 24-bit > compatibility code when a service became 31-bit compatible. > > I'm not asking it to be changed but doc is changed for AMODE 64 but they > don't add 64-bit requirements. I only bring it up because it's a terrible > inconsistency for IBM. > > > 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. > > By this logic, we can't use STORAGE OBTAIN in an RMODE 64 load module > because there's no mention of RMODE as a requirement. How about CSRC4RG1 > where it says AMODE 64-bit addressing mode and All input addresses must be > valid 64-bit addresses but doesn't mention RMODE. I'm sure I could find > additional inconsistencies. For instance, I suspect that ATTACHX might > allow RMODE 64 but prove a negative. > > So the new DOC philosophy is to state the lifting of a requirement in the > requirements section and assume that everyone knows about unlisted > requirements. While I see this in the Linux world, I didn't expect it in > z/OS. > > >Might an RMODE 64 invocation work? Yes. > > I'm guessing it's rare for a service (e.g. SVC, PC, SSI, ...) to be called > from an RMODE 64 load module. Literals and STORAGE OBTAIN would be above > the bar thus requiring full AMODE 64 compatibility. > > Many TSO services (e.g. ISPLINK & ISPEXEC) don't mention AMODE nor RMODE. > In fact, they don't state any requirements Many of these services use the > functions you mention. > > >If you want to risk it (and put your customers at such risk), that cannot > be stopped. > > It's doubtful that vendors are directly with RMODE 64. More likely are > risks associated to their codes use of RMODE 64. > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
