Re: Virtual Storage Manager - LDA.

[Colin Paice]

What Ive done in the past is

Allocate and reuse chunks 0-32KB,32KB- 64 KB,  64KB-128KB
if req < 32KB then use p32KBblock
else if req < 64LB then use p64kbBlock
else if req < 128KB then use p128KBblock

else
/* request is over 128KB *.
Allocate it ...

Afterwards

if req > 128KB then free block.

If you need multiple blocks create a quick cell... do not free a block...
just chain it to the free chain for that block size.

please feel free to contact me offline for more info
Colin


On Wed, 8 Mar 2023 at 19:06, Mike Schwab  wrote:

> Well, the obvious solution is to always allocate an area for the
> maximum size.  For small items use parts of one or more large areas,
> for large items use and release a separate area.
>
> On Wed, Mar 8, 2023 at 8:04 AM Massimo Biancucci 
> wrote:
> >
> > Hi,
> >
> > my LE options include RPTSTG and the output confirmed to me there are no
> > issues with ALLOCATE and FREE.
> >
> > About the app itself, it's a monitor who receives a bunch of data into a
> > buffer from Db2 and spreads items into lots of single varying length
> chunks
> > within a tree.
> > The varying length (from few bytes to KBs) is the main reason because I
> > don't use an array. The time I wrote the application seemed to be a good
> > way to avoid memory waste.
> > At every iteration info about single nodes can be still present or not.
> If
> > yes, I have to refresh data, if not I've to logically delete the node.
> > From time to time a garbage collector releases the useless nodes.
> >
> > The main problem is the communication buffer that DB2 sometimes asks me
> to
> > increase (even if it's really huge, more than 100MB and I can't know the
> > maximum needed size).
> > These big chunks tend to fill the memory with a lot of wasted space.
> > Probably I have to rethink the way I allocate and free such a buffer.
> > I read about the AREA and it seems to me it's not the right tool for it.
> >
> > Regards.
> > Max
> >
> >
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > Privo
> > di virus.www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > Il giorno mer 8 mar 2023 alle ore 13:52 Steve Smith 
> ha
> > scritto:
> >
> > > Have you looked at the documentation for RPTSTG?  Have you tried the
> > > process described?
> > >
> > > sas
> > >
> > >
> > > On Wed, Mar 8, 2023 at 5:31 AM Massimo Biancucci 
> > > 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.
> > > >
> > > >
> > >
> > > --
> > > 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
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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

Re: Virtual Storage Manager - LDA.

[Mike Schwab]

Well, the obvious solution is to always allocate an area for the
maximum size.  For small items use parts of one or more large areas,
for large items use and release a separate area.

On Wed, Mar 8, 2023 at 8:04 AM Massimo Biancucci  wrote:
>
> Hi,
>
> my LE options include RPTSTG and the output confirmed to me there are no
> issues with ALLOCATE and FREE.
>
> About the app itself, it's a monitor who receives a bunch of data into a
> buffer from Db2 and spreads items into lots of single varying length chunks
> within a tree.
> The varying length (from few bytes to KBs) is the main reason because I
> don't use an array. The time I wrote the application seemed to be a good
> way to avoid memory waste.
> At every iteration info about single nodes can be still present or not. If
> yes, I have to refresh data, if not I've to logically delete the node.
> From time to time a garbage collector releases the useless nodes.
>
> The main problem is the communication buffer that DB2 sometimes asks me to
> increase (even if it's really huge, more than 100MB and I can't know the
> maximum needed size).
> These big chunks tend to fill the memory with a lot of wasted space.
> Probably I have to rethink the way I allocate and free such a buffer.
> I read about the AREA and it seems to me it's not the right tool for it.
>
> Regards.
> Max
>
>
>
> 
> Privo
> di virus.www.avast.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Il giorno mer 8 mar 2023 alle ore 13:52 Steve Smith  ha
> scritto:
>
> > Have you looked at the documentation for RPTSTG?  Have you tried the
> > process described?
> >
> > sas
> >
> >
> > On Wed, Mar 8, 2023 at 5:31 AM Massimo Biancucci 
> > 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.
> > >
> > >
> >
> > --
> > 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



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Virtual Storage Manager - LDA.

[Massimo Biancucci]

Hi,

my LE options include RPTSTG and the output confirmed to me there are no
issues with ALLOCATE and FREE.

About the app itself, it's a monitor who receives a bunch of data into a
buffer from Db2 and spreads items into lots of single varying length chunks
within a tree.
The varying length (from few bytes to KBs) is the main reason because I
don't use an array. The time I wrote the application seemed to be a good
way to avoid memory waste.
At every iteration info about single nodes can be still present or not. If
yes, I have to refresh data, if not I've to logically delete the node.
>From time to time a garbage collector releases the useless nodes.

The main problem is the communication buffer that DB2 sometimes asks me to
increase (even if it's really huge, more than 100MB and I can't know the
maximum needed size).
These big chunks tend to fill the memory with a lot of wasted space.
Probably I have to rethink the way I allocate and free such a buffer.
I read about the AREA and it seems to me it's not the right tool for it.

Regards.
Max




Privo
di virus.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno mer 8 mar 2023 alle ore 13:52 Steve Smith  ha
scritto:

> Have you looked at the documentation for RPTSTG?  Have you tried the
> process described?
>
> sas
>
>
> On Wed, Mar 8, 2023 at 5:31 AM Massimo Biancucci 
> 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.
> >
> >
>
> --
> 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

Re: Virtual Storage Manager - LDA.

[Steve Smith]

Have you looked at the documentation for RPTSTG?  Have you tried the
process described?

sas


On Wed, Mar 8, 2023 at 5:31 AM Massimo Biancucci  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.
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Virtual Storage Manager - LDA.

[Robert Prins]

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

Re: Virtual Storage Manager - LDA.

[Massimo Biancucci]

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

Re: Virtual Storage Manager - LDA.

[Seymour J Metz]

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

Re: Virtual Storage Manager - LDA.

[Rob Scott]

If you are z/OS 2.5, you can use the "L" action on the "JM" (Job Memory) screen 
in SDSF (JM action available on DA, AS or AD panels).

This will show you each block if memory for a specific subpool+key combination 
in any address space (assuming you have SAF authority to the SDSF resource that 
protects it).

Under the covers, SDSF schedules an SRB into the ASID and that uses VSMLIST.

Also note that the SDSF "AS" panel contains bird's eye view of Private and 
EPrivate storage usage of all ASIDs thanks to the rather handy LDAX control 
block (many thanks to whoever implemented that at Poughkeepsie).

Rob Scott
Rocket Software.


From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Saturday, 4 March 2023, 09:13
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Virtual Storage Manager - LDA.

EXTERNAL EMAIL





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




Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Virtual Storage Manager - LDA.

[Peter Relson]

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

Re: Virtual Storage Manager - LDA.

[Massimo Biancucci]

Thanks to everybody for the feedback.

As I said before, the problem is that using PLI verbs program sometimes
runs out of memory.
At every FREE I flag the block with a timestamp and, at dump time, lots of
blocks logically freed are physically in the dump.
So, in theory I've free blocks to reuse (as you said PLI use heap or
similar to alloc bigger blocks to use at purpose) but I run out of memory.

I've to be very sure of my finding.
Best regards.
Max

Il giorno ven 3 mar 2023 alle ore 23:36 Seymour J Metz  ha
scritto:

> We are in violent agreement.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Steve Smith 
> Sent: Friday, March 3, 2023 4:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Virtual Storage Manager - LDA.
>
> If you'd stick to the heap, which is much more efficient, you can request
> storage usage reports with quite a bit of detail.
>
> sas
>
> On Fri, Mar 3, 2023 at 2:37 PM Seymour J Metz  wrote:
>
> > I doubt that you will get what you need that way. PL/I subaloocates
> > storage withing big blocks, and doing your own GETMAIN/STORAGE instead of
> > using native PL/I support may make matters worse.
> >
> > MVS also suballocates storage, and I know of no GUPI to run the chains
> > with proper serialization and give the free/allocated counts.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Massimo Biancucci [mad4...@gmail.com]
> > Sent: Friday, March 3, 2023 2:43 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Virtual Storage Manager - LDA.
> >
> > Hi everybody,
> >
> > I've a PLI program who does ALLOCATE and FREE of some based areas in
> order
> > to build and manage a dynamic tree.
> >
> > I'm debugging a problem where it runs out of memory.
> > To control how much memory it's using I refer to LDA.
> > To be sure I changed the ALLOC and FREE with explicit (via a ASM module)
> to
> > STORAGE OBTAIN and RELEASE.
> >
> > Here is the question:
> > I display the LDA structure before and after freeing some areas (few KB,
> > anyway more than zero) and I see no immediate difference.
> > Is the information in LDA updated by VSM with any delay ?
> >
> > Thanks a lot in advance.
> > Max
> >
> > --
> > 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
>
>
> --
> 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

Re: Virtual Storage Manager - LDA.

[Seymour J Metz]

We are in violent agreement.


From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Friday, March 3, 2023 4:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Virtual Storage Manager - LDA.

If you'd stick to the heap, which is much more efficient, you can request
storage usage reports with quite a bit of detail.

sas

On Fri, Mar 3, 2023 at 2:37 PM Seymour J Metz  wrote:

> I doubt that you will get what you need that way. PL/I subaloocates
> storage withing big blocks, and doing your own GETMAIN/STORAGE instead of
> using native PL/I support may make matters worse.
>
> MVS also suballocates storage, and I know of no GUPI to run the chains
> with proper serialization and give the free/allocated counts.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Massimo Biancucci [mad4...@gmail.com]
> Sent: Friday, March 3, 2023 2:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Virtual Storage Manager - LDA.
>
> Hi everybody,
>
> I've a PLI program who does ALLOCATE and FREE of some based areas in order
> to build and manage a dynamic tree.
>
> I'm debugging a problem where it runs out of memory.
> To control how much memory it's using I refer to LDA.
> To be sure I changed the ALLOC and FREE with explicit (via a ASM module) to
> STORAGE OBTAIN and RELEASE.
>
> Here is the question:
> I display the LDA structure before and after freeing some areas (few KB,
> anyway more than zero) and I see no immediate difference.
> Is the information in LDA updated by VSM with any delay ?
>
> Thanks a lot in advance.
> Max
>
> --
> 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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Virtual Storage Manager - LDA.

[David Crayford]

On 4/3/23 05:45, Steve Smith wrote:

If you'd stick to the heap, which is much more efficient, you can request
storage usage reports with quite a bit of detail.


+1. And if you can also diagnose the heap using tools like Fault 
Analyzer and good old IPCS.




sas

On Fri, Mar 3, 2023 at 2:37 PM Seymour J Metz  wrote:


I doubt that you will get what you need that way. PL/I subaloocates
storage withing big blocks, and doing your own GETMAIN/STORAGE instead of
using native PL/I support may make matters worse.

MVS also suballocates storage, and I know of no GUPI to run the chains
with proper serialization and give the free/allocated counts.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
of Massimo Biancucci [mad4...@gmail.com]
Sent: Friday, March 3, 2023 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Virtual Storage Manager - LDA.

Hi everybody,

I've a PLI program who does ALLOCATE and FREE of some based areas in order
to build and manage a dynamic tree.

I'm debugging a problem where it runs out of memory.
To control how much memory it's using I refer to LDA.
To be sure I changed the ALLOC and FREE with explicit (via a ASM module) to
STORAGE OBTAIN and RELEASE.

Here is the question:
I display the LDA structure before and after freeing some areas (few KB,
anyway more than zero) and I see no immediate difference.
Is the information in LDA updated by VSM with any delay ?

Thanks a lot in advance.
Max

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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Virtual Storage Manager - LDA.

[Steve Smith]

If you'd stick to the heap, which is much more efficient, you can request
storage usage reports with quite a bit of detail.

sas

On Fri, Mar 3, 2023 at 2:37 PM Seymour J Metz  wrote:

> I doubt that you will get what you need that way. PL/I subaloocates
> storage withing big blocks, and doing your own GETMAIN/STORAGE instead of
> using native PL/I support may make matters worse.
>
> MVS also suballocates storage, and I know of no GUPI to run the chains
> with proper serialization and give the free/allocated counts.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Massimo Biancucci [mad4...@gmail.com]
> Sent: Friday, March 3, 2023 2:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Virtual Storage Manager - LDA.
>
> Hi everybody,
>
> I've a PLI program who does ALLOCATE and FREE of some based areas in order
> to build and manage a dynamic tree.
>
> I'm debugging a problem where it runs out of memory.
> To control how much memory it's using I refer to LDA.
> To be sure I changed the ALLOC and FREE with explicit (via a ASM module) to
> STORAGE OBTAIN and RELEASE.
>
> Here is the question:
> I display the LDA structure before and after freeing some areas (few KB,
> anyway more than zero) and I see no immediate difference.
> Is the information in LDA updated by VSM with any delay ?
>
> Thanks a lot in advance.
> Max
>
> --
> 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

Re: Virtual Storage Manager - LDA.

[Seymour J Metz]

I doubt that you will get what you need that way. PL/I subaloocates storage 
withing big blocks, and doing your own GETMAIN/STORAGE instead of using native 
PL/I support may make matters worse.

MVS also suballocates storage, and I know of no GUPI to run the chains with 
proper serialization and give the free/allocated counts.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Massimo Biancucci [mad4...@gmail.com]
Sent: Friday, March 3, 2023 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Virtual Storage Manager - LDA.

Hi everybody,

I've a PLI program who does ALLOCATE and FREE of some based areas in order
to build and manage a dynamic tree.

I'm debugging a problem where it runs out of memory.
To control how much memory it's using I refer to LDA.
To be sure I changed the ALLOC and FREE with explicit (via a ASM module) to
STORAGE OBTAIN and RELEASE.

Here is the question:
I display the LDA structure before and after freeing some areas (few KB,
anyway more than zero) and I see no immediate difference.
Is the information in LDA updated by VSM with any delay ?

Thanks a lot in advance.
Max

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

Virtual Storage Manager - LDA.

[Massimo Biancucci]

Hi everybody,

I've a PLI program who does ALLOCATE and FREE of some based areas in order
to build and manage a dynamic tree.

I'm debugging a problem where it runs out of memory.
To control how much memory it's using I refer to LDA.
To be sure I changed the ALLOC and FREE with explicit (via a ASM module) to
STORAGE OBTAIN and RELEASE.

Here is the question:
I display the LDA structure before and after freeing some areas (few KB,
anyway more than zero) and I see no immediate difference.
Is the information in LDA updated by VSM with any delay ?

Thanks a lot in advance.
Max

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN