Attila,
Thanks for that pointer, when we changed KEEP to FREE (well not all, but this
one) our heap memory issues went away. Now my real question is why didn't the
Heap Segments get reused. Since our high water memory reached a much lower mark
after the change, it appears our application was n
Have you tried heappools?
One problem with storage managers is that you get fragmentation. By using
heap pools - so you get pools of say 2KB, 4KB, 16KB, 64KB etc you use a bit
more space overall, but the storage can be reused better.
Turn on heappools - look at the reports and it recommends new h
I had similar situations a lot of times at different customers' locations.
It always turned out that when the developers at the customer's site
telled me
that they returned all the storage requested to the heap, in fact they
didn't.
There was always a small area left which was not returned or f
I could understand fragmentation being any issue if we did not return all the
memory, but during each iteration we return all the application allocated
memory, so how can memory become fragmented?
--
For IBM-MAIN subscribe / sig
Sounds like your HEAP options are inappropriate for this application,
classic fragmentation ... e.g. set to KEEP and increment size is too
small. Check your CEE_RUNOPTS or there could be other LE config/exits
involved. Suggest you set disp=FREE and work out increment size.
HEAP(initial, increme
We are in a bit of a quandary here with some memory issues surrounding our
application. This is a multitasking LE C application running in 31 bit mode
that utilizes the IBM JSON and EZNOSQL Services. Some of the attributes are:
• z/OS V2.5 Operation System
• POSIX(OFF) - all tasks/s
