Besides all the things that Bill mentioned, which as far as I see can
be activated by LE run time options, there is one additional technique
which requires some input into the ENV string (environment), which is
also a runtime parameter; you can replace the normal LE heap manager
by the so called
Here's the link I failed to include, the suggested reading:
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceeam00/clsthp.htm
An overview, but, for the willing reader, follow the references and go as deep
as you want.
LE can report on storage used, and storage (like
Bill,thanks for your answer. I concur with everything you wrote. I don't know
what they intended to do with this if it was available. I doubt they want to do
their own storage management. I seem to remember they talked about "statistics"
or "bookkeeping", but I'll have to ask for more details.
I've documented this some time ago for my own use and
for the use of a customer of mine, and it is not very complicated.
But I don't recall the details at the moment.
I wrote a routine, too, that writes a report of all allocated areas,
if you give one valid address to it; that is possible,
There is some evidence that the "control information" is stored in the heap
itself (see the Usage Notes for "CEEFRST—Free heap storage") and by
implication associated directly with the storage allocated. However, it is not
documented, and working it out through inspection would be pointless
As far as memory (storage) references go, "Above" and "Below" can easily be
perceived and defended either way, although *I* would usually take "Above"
to mean higher addresses (cf. "above-the-line'). By context, I guess the
opposite was meant, probably by projection of a dump or most memory
On Fri, 22 Jul 2016 11:59:33 -0500, Victor Gil wrote:
>No, subtract 8-16 bytes from the area address to get to the header...
>
>I guess my usage of the words "top" and "ABOVE" could be misleading - this is
>how we were drawing memory maps back in the 70s, so that they grow DOWN from
>the
No, subtract 8-16 bytes from the area address to get to the header...
I guess my usage of the words "top" and "ABOVE" could be misleading - this is
how we were drawing memory maps back in the 70s, so that they grow DOWN from
the staring location
On Fri, 22 Jul 2016 08:53:54 -0500, Victor Gil wrote:
>I am guessing the length may be stored somewhere in the vicinity of the area
>top address, say within 8-16 bytes ABOVE it.
>
So to get to it you just add the length of the area to the address of the area?
>At least this is how CICS handles
I am guessing the length may be stored somewhere in the vicinity of the area
top address, say within 8-16 bytes ABOVE it.
At least this is how CICS handles GETMAIN requests which also don't require
length on the FREEMAINs.
Of course, if the convention is not documented it may change at any
> I very much doubt it.
Yeah, me too. But I thought I might be missing something and better ask.
>I'm curious; what will you do with this info if it is available?
I'm asking because I have been asked by our middle war guys. Our applications
are required to use our own middle ware service
On Wed, 20 Jul 2016 19:34:21 -0400, Tony Harminc wrote:
>On 20 July 2016 at 16:14, Peter Hunkeler wrote:
>
>> Is there an interface or any other documented way to get the length of an
>> area at a given address?
>
>I very much doubt it. I don't see anything in the LE Vendor Interfaces
>book.
>
On 20 July 2016 at 16:14, Peter Hunkeler wrote:
> When using LE service CEEGTST to allocate a piece of heap storage, the length
> is provided by the caller of the service and the address of the storage is
> returned by the service. To free that storage CEEFRST is called. Only the
When using LE service CEEGTST to allocate a piece of heap storage, the length
is provided by the caller of the service and the address of the storage is
returned by the service. To free that storage CEEFRST is called. Only the
addressof the area, as returned by CEEGTST, has to be passed to the
14 matches
Mail list logo