Discussion:
What comes around, goes around...
(too old to reply)
KELLIE FITTON
2003-09-22 20:31:21 UTC
Permalink
Hello everyone,

is it possible to code a procedrual & gui cobol programs to perform an
automatic "Garbage Collection" on-the-fly? I would like to prevent any
memory leaks that could cause the system to become unstable. I am using
(large indexed files & sequential files & sort routines & sub-programs)
by microfocus Netexpress 3.1 compiler on windows 2000 platform.
thanks a lot for your kind help, Kellie.
Michael Mattias
2003-09-22 22:01:02 UTC
Permalink
Post by KELLIE FITTON
Hello everyone,
is it possible to code a procedrual & gui cobol programs to perform an
automatic "Garbage Collection" on-the-fly? I would like to prevent any
memory leaks that could cause the system to become unstable. I am using
(large indexed files & sequential files & sort routines & sub-programs)
by microfocus Netexpress 3.1 compiler on windows 2000 platform.
thanks a lot for your kind help, Kellie.
Assuming you are talking about a Windows environment, no.

Each Windows process owns and *jealously* guards all resources allocated to
that process until explictly released or the process ends. That is, to a
Windows process there is no such thing as 'garbage' to collect. (Or,
"Windows cannot know it's a leak: it assumes if the programmer allocated the
resource, the programmer wants the resource available")

If you do have memory leaks, it's because the program was not coded
correctly, whether that be your program or any third-party products used
(e.g., NetExpress runtime, print library, whatever).

If you can end the process and restart a new process 'where you left off'
that would do the trick, but far and away your best bet for reducing 'leaks'
is to code carefully to start with.

--
Michael Mattias
Tal Systems, Inc.
Racine WI
***@talsystems.com
James J. Gavan
2003-09-22 23:38:01 UTC
Permalink
Post by KELLIE FITTON
Hello everyone,
is it possible to code a procedrual & gui cobol programs to perform an
automatic "Garbage Collection" on-the-fly? I would like to prevent any
memory leaks that could cause the system to become unstable. I am using
(large indexed files & sequential files & sort routines & sub-programs)
by microfocus Netexpress 3.1 compiler on windows 2000 platform.
thanks a lot for your kind help, Kellie.
Well at long last you have got specific and told us you are using N/E V 3.1
- why didn't you do that with your first message <G>. You write about
'GUIs' so I'm assuming you are talking about Dialog Editor (visually design
'dialogs' and use GUI classes) as opposed to Dialog System (which is a
separate module but which does invoke M/F classes as necessary).

A bit of background so you know where you are at with Garbage Collection.
The COBOL Standards Committee (J4) first approved OO as an addition to
COBOL back in '93 as a draft.. Only three took up the cudgel , Hitachi
(only sold in Japan), IBM and Micro Focus. (Fujitsu followed a while later
so they were able to incorporate some additional information subsequently
'blessed' by J4).

The 'Standard' as set, specified general class structures but did not spell
out support for 'standard classes', GUIs or garbage collection. What you
have in N/E is the M/Fr own version of support classes subordinate to Base,
plus of course the classes for GUI support.

Where is J4 at the moment ? They approved a "Finalizer" document last
year which is the standard for getting rid of objects - garbage collection,
but as yet, to my knowledge is not part of any OO COBOL compiler. They are
also working currently on 'standard classes' (that's the 'bunch' you see in
N/E under Base, which also includes collections). Target date for J4
'Standard Classes' - last time I looked - 2006.

So for the moment without auto garbage collection, you have to go with the
N/E, "finalize", "deepfinalize", and "deepfinalizeWithDepth". Just as you
have your housekeeping routines to initiate classes or Dialogs, similarly I
have 'close down housekeeping'.

I'm working on the following at the moment, so let's use it as an example
:-

Class : Treevbus.cbl (TreeView Business Logic)
*>-------------------------------------------------------------
OBJECT-STORAGE SECTION.
*>-------------------------------------------------------------
01 os-CheeseDBI object reference value null.
01 os-CheeseFile object reference value null.
01 os-CountryFile object reference value null.
01 os-CurrentTvItem object reference value null.
01 os-Parent object reference value null.
01 os-Resource object reference value null.
01 os-Treeview object reference value null.
01 os-TvAncestor object reference value null.
01 os-TvPopup object reference value null.

01 os-CheeseDialog object reference value null.
01 os-CountryDialog object reference value null.
01 os-TvDialog object reference value null.

Note the os-Parent (Main Window) and os-Resource (Dialog Editor dll) are
NOT included in the following - the disappear with a 'STOP RUN'. :-

When I use 'PB-Exit" or "PB-Cancel" then I :-

invoke self "finalizeObjects"

*>-------------------------------------------------------
Method-id. "finalizeObjects".
*>-------------------------------------------------------
Local-storage section.
copy "sqlreslt.cpy" replacing ==(tag)== by ==01 ls==.
01 ls-object object reference.
Procedure Division.

set ls-object to os-CheeseDBI
perform FINALIZE-SINGLE
set ls-object to os-CheeseFile
perform CLOSE-FILE
set ls-object to os-CountryFile
perform CLOSE-FILE
set ls-object to os-CurrentTvItem
perform FINALIZE-SINGLE
set ls-object to os-Treeview
perform FINALIZE-SINGLE
set ls-object to os-TvAncestor
perform FINALIZE-SINGLE
set ls-object to os-TvPopup
perform FINALIZE-CLASS
set ls-object to os-CheeseDialog
perform FINALIZE-DIALOG-MENU.
set ls-object to os-CountryDialog
perform FINALIZE-DIALOG-MENU.
set ls-object to os-TvDialog
perform FINALIZE-DIALOG-MENU.
invoke self "finalize" returning self

EXIT METHOD.

copy "finalize.cpy".

End Method "finalizeObjects".
*>-------------------------------------------------------

The copy file included above :-

--------------------- finalize.cpy -------------------------

CLOSE-FILE.

if ls-object <> null
invoke ls-object "closeFile" returning ls-SqlResult
perform FINALIZE-SINGLE
End-if
.
FINALIZE-CLASS.

if ls-object <> null
invoke ls-object "finalizeObjects" returning ls-object
End-if
.
FINALIZE-COLLECTIONS.

if ls-object <> null
invoke ls-object "deepfinalize" returning ls-object
End-if
.
FINALIZE-DIALOG-MENU.

if ls-object <> null
invoke ls-object "hide"
invoke ls-object "finalizeObjects" returning ls-object
End-if
.

FINALIZE-SINGLE.

if ls-object <> null
invoke ls-object "finalize" returning ls-object
End-if
.

------------------------------------------------------------

Note that in some instances the 'finalize' is done within Treebus.cbl,
other times it is passed to the other classes which themselves have a
method "finalizeObjects", containing the 'finalize.cpy" file.

It isn't picture perfect, (leaving a few objects hanging around) but it
gets rid of the majority and avoids memory leaks.

Jimmy, Calgary AB
LX-i
2003-09-26 04:34:42 UTC
Permalink
Post by James J. Gavan
A bit of background so you know where you are at with Garbage Collection.
The COBOL Standards Committee (J4) first approved OO as an addition to
COBOL back in '93 as a draft.. Only three took up the cudgel , Hitachi
(only sold in Japan),
Actually, the Hitachi OO COBOL is part of the Unisys Programmer's
Workbench, and has a companion processor on the mainframe called OCOB.
:) All before J4 approved the 2002 standard...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ ***@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Loading...