On Fri, Jun 7, 2019 at 10:45 AM Charles Mills <[email protected]> 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:[email protected]] On > Behalf Of John McKown > Sent: Friday, June 7, 2019 6:33 AM > To: [email protected] > 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 [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN
