> the invocation asked to free location 0 for length of x'01000000' and that > properly got 378-1C.
I was following this guidance in the documentation: If you specify R,LV=(0) you cannot specify the SP parameter. You must specify the subpool in register 0; the high-order byte must contain the subpool number and the low-order three bytes must contain the length unless you are requesting a subpool release. On a subpool release, the low-order three bytes must contain zeros. Aha! That guidance is specific to R and not to RU! When I code R, the code assembles as 105 FREEMAIN R,A=(1),LV=(0) 107+ LA 1,0(0,1) LOAD AREA ADDRESS 108+ SVC 10 ISSUE FREEMAIN SVC And the S378 (of course) goes away. (Not sure why that LA is in there. They don't trust me to get A=(1) right?) The S378 problem unsurprisingly becomes a S0C4 problem, as I apparently have given away all of LE's storage. I started a separate thread for that. I guess the good news in there is that my subpool release must have worked spectacularly well. Thanks @Peter and @Jim for your help (as always). Charles On Sat, 31 Aug 2024 12:53:52 +0000, Peter Relson <rel...@us.ibm.com> wrote: ><snip> > FREEMAIN A=(1),LV=(0) > 12,*** IHB001 MODE OPERAND REQ'D-NOT SPECIFIED > > So it would seem that you actually most have done something like FREEMAIN > RU,A=(1),LV=(0) ></snip> > >If Jim is right, then the invocation asked to free location 0 for length of >x'01000000' and that properly got 378-1C. >That input matches the explanation for 378-1C. > >I hope there is no use of LE and C writeable static in this address space. >That uses subpool 1 and it would be unlikely to be a good idea to free the >whole subpool in such a case. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN