On Wed, 6 Aug 2025 12:24:13 +0000, Peter Relson <[email protected]> wrote:
>><snip>I fear I won't make it.</snip> >AMODE/RMODE, changing the initiator would be wholly incompatible. That will >never happen. ROTFLOL. Let's forget that Paul's request is the definition of insanity and realize he comes from Unix. We should be asking Paul "what he believes is the benefit of supporting 64-bit initiator parms" when IBM gave us the LLGT (load logical thirty-one bit) instruction to simplify AMODE 64 compatibility (replace L with LLGT). Going back to "definition of insanity", Paul is asking every customer, vendor & IBM to commit to changing every program using parms passed by the initiator and to formulate a migration plan where system A and B in the same sysplex run different initiator parm definitions. Even Unix is not this insane with the exception of converting Python2 to Python3. >><snip>Looking at 2.5 WTO I don't see any qualifications about the location of >>control parameters other than in the primary address space, which would imply >>above the BAR is OK.</snip> By qualifications, Paul means restrictions. For decades with AMODE 31, we relied on restriction "rmode 24" to tell us parms must be below the line (with a couple of exceptions). Peter is telling us the opposite is true for AMODE 64. Always assume below the bar parms as an unstated requirement unless RMODE 64 ALLOWED is stated as a requirement. >><snip>However, there is a general restriction "A program running in AMODE 64 >>should >>not call a service with data, parameters, or parameter addresses that are >>higher than 2 gigabytes, unless the individual service description indicates >>that it is allowed."</snip> "unstated" restriction. >What is true (and, unfortunately, no one in IBM ever felt it worth the $$ to >address) >is that there was never an effort made (and likely never will be) to have all >the services document their AMODE, RMODE It's too late now but it would have been $0 to always say RMODE 31 restriction when AMODE 64 was added to a service. At least then we could have asked if this is a doc error. >><snip>joyous day when all services are supported in the >>highest available AMODE/RMDE (still 64 by then?),</snip> No one cares if "all services" support 64-bit. Actually, the "joyous" day came when IBM simplified AMODE/RMODE 64. Replacing L with the LLGT instruction. RMODE=SPLIT. 64-bit support for important services. And more. Unlike 24-bit storage constraint relief, 31-bit storage contraint relief only requires moving the big stuff and making programs tolerate 64-bit where needed. >><snip>I fear I won't make it.</snip> No one cares about being fully 64-bit compliant. In fact, we still have 24-bit code running today. >><snip>Isn't Linux already there?</snip> ROTFLOL. Show us z/OS "system programs" and we'll show you Linux application programs. Look no farther than DB2 for z/OS versus Linux. There's a huge difference between z/OS PC routines and Linux TCP. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
