Peter Thanks I’m not writing RMODE64 code don’t see a reason to
I don’t know why Ed co. does cann’t believe the code is that large Thanks for the heads up about LE I believe the real reason for RMODE64 is Java > On Dec 22, 2020, at 8:57 AM, Peter Relson <rel...@us.ibm.com> wrote: > > Since z/OS 2.3 you have been able to identify modules as wanting to be > RMODE 64, via what Ed Jaffe mentioned (including RMODEX=64TRUE). > Just about the only thing that is guaranteed for an RMODE 64 module is > that your module will survive being undispatched and redispatched (such as > on a time slice). > > VERY FEW system services officially support invocation in RMODE 64. If > they don't say that they do, then do not assume that they do. In practice > services that are SVC-entered or PC-entered might well work enough for > your purposes (and I intentionally used the word "enough" because there > might be things that you do not notice that are not fully supported, > particularly with respect to diagnostic data). Things that are > branch-entered might "get there" but might well not "get back". Be careful > about referencing parameters that are within your module for a service > that does not document that it accepts parameter data above 2G. Any > service that has a "SAM31" (or SAM24) as part of its expansion will of > course not work in RMODE 64. Many things cannot be RMODE 64. including > IRBs, SRBs, recovery routines, retry points. All of these relate to there > being only a 4-byte area to capture the initial address. Obviously after > getting control you can branch elsewhere. For recovery routine retry, one > way to accomplish retrying to an area in an RMODE 64 module is to set up > 64-bit retry register 15 with the pointer-defined address of where you > "really want to go" and retry to CVTBSM0F. You might also need SETRP > RETRY15=YES so that your retry register 15 is honored. > > If your RMODE 64 module calls no services (and of course is AMODE 64) it > will work if correctly written. > > There has been no proven need for RMODE 64 for modules (despite the > abominable code bloat of some application approaches). Applications have > been moving their data above 2G for many years. > > The eventual intent is for LE to support your RMODE 64 modules via the LE > services that you can call. The LE services will pay attention to whether > the underlying system service supports RMODE 64 or not. I've lost track of > whether this is available or not, and, if not available, when it might be. > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
