Massimo, Can you give some idea of the logic in the program?
You may be able to allocate the small areas inside an AREA variable (which allows you to zap them with a simple "AREA=EMPTY()" statement, rather than individual FREE statements, and the ALLOCNEXT() builtin generates very fast inline code to allocate chunks of storage inside an AREA variable. By using a sizeable AREA variable, you may prevent a lot of fragmentation of the heap. Look for https://ibm-z-software-portal.ideas.ibm.com/ideas/PLIVUE-I-61 & https://ibm-z-software-portal.ideas.ibm.com/ideas/PLIVUE-I-207 I had similar issues and requested these two enhancements/ Robert On Wed, 8 Mar 2023 at 10:31, Massimo Biancucci <mad4...@gmail.com> wrote: > Thanks to everybody for your support. > As usual I learnt a lot. > > The problem was (as usual business) between my seat and my keyboard. > The PLI FREE statement was not consistent with ALLOCATE. The size of the > area to be free was not correct. > I thought it was not so important and I was wrong. The manual states it > counts. > > Anyway my program suffers of HEAP fragmentation because of a mix of (lot) > small areas that I often need to allocate and free and (few) big areas that > I need to free and allocate rarely (root cause of the problem). > To trigger the issue I ran the program with a small region size, hopefully > with a bigger region I'll run ok. > It seems there's no way to ask PLI/LE for heap defrag. > > Best regards. > Max. > > > Il giorno dom 5 mar 2023 alle ore 22:07 Seymour J Metz <sme...@gmu.edu> ha > scritto: > > > VSMLIST is certainly the best way to test what z/OS has allocated in > large > > blocks, but I believe that the OP would be better served by using PL/I > > facilities to allocate and report the storage. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > ________________________________________ > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > > of Peter Relson [rel...@us.ibm.com] > > Sent: Saturday, March 4, 2023 9:13 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Virtual Storage Manager - LDA. > > > > Updates to the LDA are done synchronously with respect to the request. > > Fields such as LDALOAL, LDAHIAL, LDAELOAL, LDAEHIAL might be of interest > > depending on what you're doing (subpool and whether the virtual is above > or > > below 16M, in particular). I don't recall, but those might reflect > > allocation of anything within a given page rather than indicating the > exact > > number of bytes allocated. > > > > If you want details from a program, use VSMLIST. Or take a dump and look > > at one of the IPCS VSMDATA reports. > > And GTF tracing of getmain/freemain/storage requests is available to you. > > > > Peter Relson > > z/OS Core Technology Design > > > > > > ---------------------------------------------------------------------- > > 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 > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Robert AH Prins robert(a)prino(d)org The hitchhiking grandfather <https://prino.neocities.org/index.html> Some REXX code for use on z/OS <https://prino.neocities.org/zOS/zOS-Tools.html> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
