I use the HEAPCHK(ON,1,0,10,10) LE runtime option to find my memory
leaks. How is your instrumentation different? I assume you wrap
malloc()/free() calls?
On 9/08/2016 1:50 AM, Bernd Oppolzer wrote:
IMO there is no need to create additional heaps
to support dynamic tables in COBOL.
I did some research some days ago on the LE heap
implementation and found an old IBM presentation (from 2005) on
this topic called "Stacks and Heaps" (you will find it using
Google, the full title reads something like "Stacks are easy,
heaps are fun"). There are COBOL examples included, which
use the LE functions CEEGTST (get storage) and CEEFRST
(free storage) - I hope, I recall the names correctly.
Based on these functions (which are malloc and free, after all),
you could do all sorts of dynamic allocations from COBOL, using
the normal LE "user heap", which is sufficient, IMO.
BTW: I wrote some functions in the last few days, which dumps all
the allocated heap areas and - more interesting - they write reports,
how the heap has changed since the last call. This is very interesting
...
if you have a function that you think that does not free its heap areas
properly, you can call this heap report function before and after
this function call and find out by looking at the so called heap delta
listing.
If you are interested, feel free to contact me offline.
Kind regards
Bernd
Frank Swarbrick schrieb:
By "heap pool" are you referring to using CEECRHP to create
additional LE heaps? I am doing that upon creation of the first
"dynamic table" within a program. (Just using the defaults of 0 for
each of the CEECRHP parameters at the moment.) Are you thinking it
might make sense to use a separate heap for each table? I have no
idea what phi is (I took neither Greek nor higher mathematics), but
I'll take a look at it.
I personally would like COBOL to have most of those "collection
classes" you refer to. But I'm not sure how user friendly these ILCs
wrappers you refer to would be. Feel free to develop them, though!
:-) We don't have access to the C/C++ compiler, and thus I will not
be playing around with that.
Frank
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
