× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Tue, 11 Mar 2003, Mike McKinney wrote:
>
> Any danger in creating all RPGLE programs with DFTACTGRP(*NO) ACTGRP(*NEW)?
> We don't use activation groups and compile everything as CRTBNDRPG.  Could
> it be a potential memory problem?
>

What's a "memory problem"?  Are you asking if it uses more memory?  More
than what?  What am I to compare it to?   Using CRTDUPOBJ?  Using
DFTACTGRP(*YES)?  Using ACTGRP(QILE)?  Using named activation groups?

Nearly anything (aside from shutting off the computer) is a "potential
memory problem."  Compiling a program takes up disk space which, with the
single-level-store, is the same as using up memory.  Adding records to a
database uses up memory.  Not clearing messages from a message queue or
deleting spooled files from an output queue uses memory.  Anything can be
considered a "potential memory problem" in that light.

Certainly, each time you use CRTDUPOBJ to create a different copy of the
program you're using *significantly* more memory than simply creating
a new activation group -- the program is duplicated on disk, as well as
being re-activated!

But, let's look at it from the perspective of using *NEW as opposed to
the existing activation groups...

In one way, ACTGRP(*NEW) uses extra memory.   Each activation group ("AG")
uses a small amount of memory, and since ACTGRP(QILE) and DFTACTGRP(*YES)
force the program to run in pre-existing activation groups, they don't add
to the amount of memory in use.

However, I believe that in most cases ACTGRP(*NEW) will save memory
becauase it forces things to be cleaned up.   An AG does not use a lot of
memory by itself.  Certainly not when you take into account the amount of
memory shipped with computers today!    But, when a program using *NEW
ends, everything that it had loaded gets forcibly cleaned up.   For
example,if you called ALLOC in your program, and forget to call DEALLOC
for the memory you reserved, ACTGRP(*NEW) will force that memory to be
released when your program ends.   If you make the same mistake with QILE
or the default AG, that memory to remain allocated until you sign off.

Of course, ACTGRP(*NEW) allows recursion.   If your calling a program
recursively (i.e. the program calls itself, launching a new instance of
the program, which in turn calls itself again launching a 3rd instance,
repeated in a loop, etc) then you're probably going to use up
significantly more memory.  But -- this isn't going to happen by accident!
You have to decide that you've got a business problem that requires this
as a solution, and write the code to make it happen.

The big problem you're going to have if you start changing programs with
DFTACTGRP(*YES) to DFTACTGRP(*NO) ACTGRP(*NEW) isn't going to be with
memory usage, it's going to be with overrides (OVRDBF/OVRPRTF) and with
open files (usually, OPNQRYF) until you understand what you're doing.

Okay, I'll stop rambling now.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.