If you will have the storage fixed for a longer period of time than you would want a CONFIG STOR....,OFFLINE to be delayed, then you should specify LONG=YES. Similarly, in that case, you should use SYSEVENT TRANSWAP instead of SYSEVENT DONTSWAP to become nonswappable.
Note that specifying FIX=LONG on STORAGE OBTAIN does not FIX the storage. It is simply a hint to RSM that you intend to do a PGSER FIX, LONG=YES later, so that if RSM backs the page before that, it will try to use a frame that won't require the page to be moved when you subsequently do FIX it. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > 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". ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
