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
