Re: the advantages of garbage collection

the classic example is C++...

We aren't talking C++, we are talking RPG. What information do you have as
it pertains to RPG?

the problem with this approach is what do you do if the driver CL module

never ends? It's function is to process requests from a data queue. By never
returning, the AG would not be reclaimed, and the job would eventually have
gigabytes of memory allocated.

The problem as I see it is that programming practices specific to other
types of environments are trying to be implemented into an environment that
has a fairly different fundamental infrastructure and zero fundamental need
to implement those types of practices. With RPG and data access I simply go
back to the well (i.e. DB2) if I need more water vs. trying to build
infrastructure to pass around an SQL result set.

Am I missing something here Steve?

Aaron Bartell
http://mowyourlawn.com

On Mon, Jun 23, 2008 at 8:42 AM, Steve Richter <stephenrichter@xxxxxxxxx>
wrote:

On Mon, Jun 23, 2008 at 9:10 AM, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:

The difference is the RPG has to handle the reference counting and object

cleanup ( dealloc once the object is no longer referenced. )

By that statement do you mean the RPG programmer has to keep track of

that

or the RPG runtime?

the classic example is C++ where the programmer has a ton of
facilities in the form of constructors, destructors, assignment
operator overloading, ... with which to manage memory allocations.
The programmer has to do the work of writing the code that keeps track
of the allocated memory. In that setting, the runtime cant manage the
memory your program allocates.

I guess the way I look at it is a piece of memory in
both languages would be put up for re-allocation once the scope had

expired

(i.e. local variables within a sub procedure, setting on *INLR, ending an
activation group). How are they different other than OS/400 has had this
"reclaiming of resources) for probably much longer than Java/C#? (which I
would also translate into it most likely being much more robust and
efficient)

I agree. Reclaiming the activation group can/does function like a GC.
You could use SQL CLI to write an RPG module that called an sql
procedure and converted the result set returned by that procedure into
a memory resident collection of tables. Then return that allocated
mass of data to a CL module caller in the same activation group. The
CL module then calls another RPG module in the same AG, passing
different data collections with SQL like instructions to join, select
and order them. The called RPG module executes the SQL like
instructions by reading the meta data in the collections which
describe the data ( table names, column names, column data types ).
That module returns a resulting collection which has been allocated in
the AG. etc, etc. When the CL driver module ends, the AG is
destroyed, and all the memory is reclaimed.

the problem with this approach is what do you do if the driver CL
module never ends? It's function is to process requests from a data
queue. By never returning, the AG would not be reclaimed, and the job
would eventually have gigabytes of memory allocated.

-Steve
--