Re: I hate Activation Groups....

["John Taylor" <john.taylor@xxxxxxxxxxxxxxx>]

----- Original Message -----
From: "Jim Langston" <jimlangston@conexfreight.com>

> Doesn't' this go back to Paul Jackson's answer?  Although the
> terms are different (activated instead of call and created).

Sorry, I don't recall seeing Paul's response. However, the terms are
important because a program can be called many times, but only activated
once within a given activation group. And it's during the activation --not
the call-- that the symbols are resolved.

> So, if I understand this correctly, the sign on is running in the
> default activation group.  The job runs the CL program which loads
> the Service program in the activation group Dave.  The CL then
> deletes the activation group Dave.  When the CL is run a second time
> the system sees it already loaded the service program, and uses it's
> pointer which is now pointing into la-la land because the activation
> group was deleted.

Yes.

> You are deleting the Activation group from memory, but you are not
> letting the system know that the service program is no longer loaded.
> If there was some mechanism to let the system know that the service
> program has been unloaded, then the system would re-load it again when
> the second call was made to the CL.

There is a mechanism - delete the activation group that contains the CL pgm.
Of course, you can't do that in this case because it's running in the
default AG. As others have mentioned, the real issue here is that it's just
a bad application design. If there is a valid reason for the service program
to run in it's own AG, then the CL pgm should have been created by
specifying a *NEW AG. A named activation group would also work, but would
require a call to CEETREC in order to clean up the AG itself, because the CL
is at the top of the call stack. QILE would be a bad idea because there may
be other programs running in it.


John Taylor
Canada



+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---