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.
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
