On Wed, 27 Aug 2025 12:44:17 +0000, Peter Relson <[email protected]> wrote:
><snip> >Given that there is no LOC=64 option for GETMAIN, >I was thinking that maybe what I can do is alter the >meaning of LOC=RES, at least for when an executable >is running on MVS/380. ></snip> > >I (and IBM) would consider that incompatible and thus unacceptable. Incompatible with what? >But what's the point? The point is to have a documented way to at least potentially get storage above 4 GiB. > You cannot now (and never will be able to) I wouldn't so confidently predict the future. That would depend on market forces, which you may not be able to fully predict. > use GETMAIN to get storage above 2G. IBM only controls their implementation of GETMAIN, not 3rd parties. I can exactly create a GETMAIN that obtains storage above 4 GiB. >If your program, wherever it resides in storage, wishes > to get storage above 2G, it is fully capable of doing so > via IARV64 (or IARST64 or IARCP64). That mechanism is undocumented, so I cannot and will not use that. > It does not need a re-interpretation of LOC=RES. For some definition of "need". My "needs", or at least "wants", differ from IBM. I can use GETMAIN with LOC=64 and add some meaning to some unused bits. I could reinterpret LOC=RES, for a program running AM64. Or IBM could document how IARV64 resolves into a system call. Or some other mechanism could be agreed upon. I was floating the LOC=RES suggestion, to avoid IBM using the unused bits in GETMAIN for some other purpose. BFN. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
