BTW: we had a weird but not uncommon situation just in the last few days,
where a memory leak of only 32 bytes (allocated some 500 times) lead to
a short-on-storage termination of an address space of 512 MB.
This was due to the following allocation pattern:
there were some large areas allocated in the 960 kB range, and the LE
settings
for heap extent size was 1 MB. The 960 kB areas were freed, but as in
the same
extent there was also a 32 byte area which was not freed, the whole 1 MB
area
was kept. This was done 500 or more times; the whole storage was
occupied with 1 MB extents, but this did not harm, because the 960 KB
requests
could still be honored with the existing 1 MB extents and the free space
in them.
But then suddenly (due to an insurance contract of another kind which
had another
allocation pattern), there was a request for a 2 MB area, and the whole
address
space crashed.
Of course, there was a solution: reducing the LE heap extent size to 4
k. This way
the 32 byte memory leak was not able to do such damage, because now the
960 kB areas were alone in their extent, and so the 960 kb extents were
freed and not kept.
But this is only a temporary solution - of course, the memory leak has
to be fixed.
Kind regards
Bernd
Am 10.10.2013 21:14, schrieb Gord Tomlin:
On 2013-10-10 14:08, Barry Merrill wrote:
Is there really a reason to call a z/OS MEMORY ERROR a LEAK???
It's an ERROR. I know the Open Systems guys love to hide behind
words that make it NOT seem to be their error, but why us???
Barry
Another term I recall being used in the mainframe environment is
"storage creep". Neither that nor "memory leak" adequately indicates
that the fault lies with the programmer. However flawed the term may
be, memory leak is a well known and widely used term, and its meaning
is generally understood correctly.
Most readers would infer that "memory error" indicated that the
(hardware) memory had a fault, not that memory was left allocated when
it should not have been.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
----------------------------------------------------------------------
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
