On Fri, Jun 7, 2019 at 11:24 AM Charles Mills <charl...@mcn.org> wrote:
> > Why is FIX=LONG unnecessary? > > Because SP 223 is already/always fixed? > Ah, yes. I am going not so slowly crazy (co-worker is bothering me wanting unnecessary changes to some production backups -- why on Friday I don't know -- he's bored too.). I am not sure I really want to use 223 because it is key 0 fetch protected. So I will need to either go key 0 to do some moves, or use something like MVCK, MVCSK, or MVCOS. All of which would require me to put key 0 into the PKM. Which I don't see any easy way to do (No SETPKM function that I can see). Instead, I might just go with a "weird" subpool like 230 (private high, user key, not fetch protected). Or, as usual, I am probably over thinking this because the program doesn't really interface with any other user code. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: Friday, June 7, 2019 9:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: dumb STORAGE OBTAIN question. > > On Fri, Jun 7, 2019 at 10:45 AM Charles Mills <charl...@mcn.org> wrote: > > > My WAG is that FIX=LONG is totally unnecessary. I would omit FIX=LONG to > > avoid any possibility of a problem. That would moot your FIX=LONG > question. > > > > Why is FIX=LONG unnecessary? I will be passing the real address to z/VM via > DIAG x'08' (virtual console function) so I need the storage address to be > valid for a while. I am debating with myself on FIX=LONG vs SHORT. And, > yes, the code does a SYSEVENT DONTSWAP to keep the address space swapped in > so that the real address doesn't change. > > Oh, I wasn't clear. I am doing the STORAGE OBTAIN,FIX=LONG to avoid doing > the PGSER functions entirely. > > > > > > > Charles > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of John McKown > > Sent: Friday, June 7, 2019 6:33 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: dumb STORAGE OBTAIN question. > > > > I know this is a dumb question in that the answer should obviously be "no > > problem". I am messing around with rewriting MVSCPMCD. It currently does > > PGFIX & PGFREE to fix and free the areas being communicated to VM as > > required for the DIAGNOSE (Hypervisor call) instruction. I was rewriting > > the code to use PGSER instead, when it occurred to me that this is only > 8K > > of real memory. So fixing it for the entire duration of the program > really > > shouldn't be a problem. This led me to decide to use FIX=LONG on the > > STORAGE OBTAIN. After a short discussion with Tom (original author), > where > > he mentioned not using subpool 0, I was wondering why not just use > subpool > > 223, which is Fixed, Private Storage, ELSQA, owned by the TCB issuing the > > request. So I am asking if my assumption that using FIX=LONG on the > STORAGE > > OBTAIN is not necessary, but it doesn't hurt either. I am also assuming > > that taking 8K out of ELSQA while the program runs is also a "no > problem". > > > > -- > > This is clearly another case of too many mad scientists, and not enough > > hunchbacks. > > > > > > Maranatha! <>< > > John McKown > > > > ---------------------------------------------------------------------- > > 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 > > > > > -- > This is clearly another case of too many mad scientists, and not enough > hunchbacks. > > > Maranatha! <>< > John McKown > > ---------------------------------------------------------------------- > 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 > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
