Re: DFTACTGRP(*NO) ACTGRP(*CALLER) was RE: More ILE 101

Buck,

My purpose in posting to this thread (which I'm starting to feel was a big
mistake) was to explain how actgrps work, so that people can understand
them and make informed choices.

I don't really want to get into a fight about which way is "the best way."
Every way has it's pros and cons, and every way is "the best way" in a
particular circumstance.

> Do you (would you) routinely reclaim a named activation group in production?

Yes.

> Under what circumstances would you not let it live for the life of the job?

Of the top of my head, I can't think of any circumstances where I would
want to use extra resources by keeping things activated for the life of a
job.  I suppose in a batch job where the job will end when the task is
completed I might keep things activated.


> My point is that most people don't take advantage of AGs: they are _forced_
> to pick one because the compiler insists on DFTACTGRP(*NO) if you use
> subprocedures.  If they go for the simplest solution, a named AG, they are
> pretty much emulating OPM (or trying to, anyway.)

The method that I mentioned (using *NEW when the program will end with
*INLR=*ON, named when program will end with *INLR=*OFF) is the one that
acts the most like an OPM situation.

Named does not free up resources when it ends, and therefore is very
different from an OPM activation.


> If there's a share, it'll be for the life of the job, just like the OPM
> program they are probably converting from.  I think there are very many
> more people in a mixed OPM/ILE environment than there are in ILE-only.

I doubt anyone is ILE-only.


> I'm dense, for sure.  I have never reclaimed an AG in production code.  My
> AGs live for the whole job.  I live in a mixed OPM/ILE environment.  I am
> extremely interested to understand the scenarios where one would reclaim an
> AG (because it's outside my experience and I'd really love to learn
> something new!)

Sigh... this is probably because of the way that I do things, but...
In my environment, I use something like the MVC paradigm.  A *PGM object
contains "view" and "controller" logic.  A *SRVPGM contains "model" logic.

The first call to my service program opens files & allocates other
resources (such as an SSL environment, memory from the heap for dynamic
arrays, etc, depending on the purpose of that particular srvpgm) and it
uses CEE4RAGE to register a procedure that will clean up those resources
when the activation group ends.

Therefore, since I'm using this paradigm, there are tons of resources
being used, objects being locked, etc. that don't get released until the
pactivation group ends. Since there will be many calls to the service
program, I don't want to close all of the files and free the resources
every time, that's horribly inefficient.

Now, we have various processes during the day that require users to exit a
given application.   For example, one of them is the daily "order cutoff"
procedure.  At this time, everyone must be out of the order-related
database files.  All of the orders that were filled that day are moved
into history files.  Per-day reports are run on the data.  Accounting
balances the books for that day.  Lots of things are done on this one days
worth of data, and all of these need to operate on the EXACT SAME set of
data.   So, we force everyone to get out of the files, that way we know
that the data we grab at this "cut-off" isn't going to change while the
programs are running.

However, if the people exit the programs and the resources aren't freed
up, then what?  They won't understand that they have to reclaim their
activation groups.  We could ask them to sign off the system completely,
but then they'll complain since there are many tasks that they can still
do while the cut-off procedure runs -- anything that doesn't use the order
files is allowed.

We do other forms of maintenance as well, such as doing a CHGPF when a
file is getting near it's record capacity.  What a nightmare that would be
if people who weren't using those files were locking them!

Not to mention the amount of main storage that would be kept in use,
degrading performance, because of all of this stuff remaining in memory!
We'd need more RAM for sure -- and possibly more disk space to handle
everyone leaving everything they've done for the day in memory.

Obviously, if a program is going to be called many times over and over
again, it makes sense to keep it in memory.  It performs much better, etc.

But, creating an activation group requires about 1/100th of a second.
(That's based on benchmark tests that I did a while back, they should
still be in the archives.)  When we're talking about a user running a
menu option interactively?  At the most, they're going to run that option
50 times a day.  That 1/100 of a second isn't really hurting anyone, is
it?

That being the case, it sure makes a lot more sense to free up the
resources, don't you think?

> We have a user-defined menu system, and I can't imagine how I would be able
> to get that done.  Sigh.

Do you normally have a lot of programs running behind a single menu
option?  We have a few options that run a lot of different programs, and
for those it's hard to convert them.   But, 90% of the time a menu option
here will run 3 or fewer programs, and one of them will be a simple CL
program.   It makes sense to convert those 3 programs at once so that
there's no OPM/ILE conflict.

> ps - another good thread!

I disagree.  We've discussed this exact same thing at least twice before,
and any time a thread is rehashed, it's not good.

This is perhaps worse because we're not just explaining how things work,
but we're telling people how to use them.  That's never a good idea,
because invariably it will create a conflict between different people who
happen to prefer different styles of coding.   It's not reasonable to
expect every application or every programmer to do things the same way.

The way that I choose to use activation groups is heavily dependant on the
way that my programs work.  If your programs work differently, you'll
almost certainly use them differently.  That's the way that it SHOULD be.

The important thing is that when a programmer makes his decisions about
how to do things, he understands the issues at hand so that he can make
the choice properly.