RE: activation groups and rclrsc

> From: Jim Horn
> 
> In the future we will try to move to the AG *new/*caller approach.  In our
> system, often a program that is on a menu is also called by another
> program,
> so it is hard to determine which programs are indeed *new. Don't know how
> much of a problem it is to have several programs running in a *new AG if
> they are only called a few times.  (pgma calls pgmb calls pgmc all in *new
> AG's because we don't necessarily know which one will be called first)

In general, the approach should work fine.  What will happen is that you'll
have a couple of AGs, but the creation time for an AG is measured in
fractions of a second, so it's not an issue for menu calls.  It typically
only adds up when you call a program repeatedly.

There is another issue, and I hesitate to bring it up because it can muddy
the waters, but here goes.  When a program is called in an activation group
and does not set on *INLR, then subsequent calls to that program will leave
the variables in the same state.  This is often a very good thing, because
it allows you to do things like one-time initializations and the like.
However, it can also be used to pass information between programs.  For
example, PGMA can call SRVPGM1 and store a variable.  Later PGMB can call
SRVPGM1 and get that variable.  This is really great for "session level"
information such as user preferences.

The problem comes when PGMB uses ACTGRP *NEW.  In that case, the data in
PGMA is in one activation group and is not accessible to the second
activation group that was started by PGMB.  And until you get that straight
in your mind, it can be a BEAR to debug.


> I started on the S34 in 1980 and have brought the systems I started back
> then forward to the present.  Adapting them the some of the current things
> we want to do is a challenge.

Yes it is.  Monolithic programming styles in the 80s don't translate
particularly well to the newer capabilities of modern machines.  But with
some foresight, you can get there.

Joe