The idea that someone would design an application that would allocate
some storage for each transaction, and then _not_ free it after
processing that transaction, when there are potentially "millions of
transactions" seems like a very poor design, IMHO. That also sounds
Is there an echo in the room? :) Different words, but that's what I was
saying. The question I was answering was, "(Why do something in your
application code that the system will do for you automatically?)" It would
be unsubstantiated understatement "because you should," but I may have
gotten carried away with my rant. Millions, thousands, hundreds... it all
adds up, and it all should be released when available. Good organization
such as your suggested approach is a fine start toward that end. How many
times have we said to ourselves, "Oh this program will never have to expand
to include <your choice of extensions>" but then been proven wrong? Think
scalable. Yes, the system *WILL* do it for you automatically, but only
under certain conditions and not necessarily as often as it should be done.
Back to the design you eluded to. Have you ever taken a perfectly good code
segment that has a once-per-day utility, and decided it needed to be moved
to a never-ending job? If you did that, and if it called a program that
called a program that called a SRVPGM procedure that allocated space that
was never released, would you catch it? What memory leakage will occur just
because someone decided it wasn't important to clean up since the system
will do it for you?
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"A closed mouth gathers no flies."
-- French Proverb
"A closed mouth gathers no feet."
-- American Proverb
midrange.com
