My preferred term is 'programming error'
Cliff McNeill
> Date: Thu, 10 Oct 2013 17:33:04 -0400
> From: [email protected]
> Subject: Re: How diagnose potential memory leaks with LE?
> To: [email protected]
>
> Ditto. I think they like 'leak' because they have no decent tools (in too
> many cases, not all!) to diagnose it. I see teams do things like "Run this
> for a week and see if it runs out of memory", rather than "Run it for 1M
> iterations, measure memory before, during, and after". What, they think
> that after six days, it's going to say "Ooh, I think I'll use more memory
> all of a sudden"??? (Yes, that COULD conceivably happen, but a
> day/week/month/year/decade are almost equivalent if you have no clue what
> might cause it; if you declare victory after a week, it might have been
> *about* to occur...)
>
>
> On Thu, Oct 10, 2013 at 5:25 PM, Charles Mills <[email protected]> wrote:
>
> > Gee, I agree with John. I must be having a mellow day.
> >
> > Seriously, I don't think "leak" absolves blame. If you had a water leak it
> > would definitely be a fault, not a "situation." "Leak" seems to perfectly
> > characterize what happens: the region has lots of free memory, the program
> > runs for a while, and now the free storage has mysteriously disappeared.
> > Where did it go? It leaked.
> >
> > The LE manuals use the term "storage leak problems."
> >
> > Of course, it's not really a storage or memory problem at all. It is a
> > "failure to free" error. Memory is fine; the problem is the absence of free
> > or delete instructions. Except for the fact that "memory leak" is an
> > established term that most folks agree on and recognize, I would support
> > the
> > terminology "failure to free" error.
> >
> > Charles
> >
> > -----Original Message-----
> > From: IBM Mainframe Discussion List [mailto:[email protected]] On
> > Behalf Of John Gilmore
> > Sent: Thursday, October 10, 2013 11:57 AM
> > To: [email protected]
> > Subject: Re: How diagnose potential memory leaks with LE?
> >
> > Barry Merrill wrote:
> >
> > <begin extract>
> > 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???
> > <end extract/>
> >
> > and I strongly agree that the use of euphemisms for what are in fact errors
> > is undesirable.
> >
> > In this case, however, the use of 'leak' instead of 'error' is a very old
> > practice. The phrase 'storage leak' has been used at least since the 1970s
> > to characterize situations in which dynamically allocated [usually] heap
> > storage is incompletely freed at the end of its use, so that the total
> > amount of this storage available gradually diminishes, leaks away, until
> > processing can no longer continue or performance deteriorates
> > spectacularly.
> >
> > Here, I think, some loss in precision would attend using a generic term
> > like
> > 'storage error' instead of the traditional one.
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to [email protected] with the message: INFO IBM-MAIN
> >
>
>
>
> --
> zMan -- "I've got a mainframe and I'm not afraid to use it"
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
