Commonly Asked Questions About ILE Activation Groups
Written by Susan Gantner
Tuesday, 17 July 2007
What you don't know about activation groups can hurt you!
In my
teaching about ILE at conferences and in classes, the subject that tends to
generate the most questions is activation groups. In this article, I'll take a
look at the answers to some of the most commonly asked questions I've heard.
First, a very brief definition of activation groups may be in order as a
level set. An activation group is a logical grouping of programs and/or
procedures within a job. Perhaps the easiest way to envision them is to think of
them as smaller jobs nested inside the bigger "real" job. However, unlike with
"real" jobs, you can do program or procedure calls directly from one activation
group to another.
Activation groups have two primary purposes:
To
provide an easy way to clean up (reclaim) program storage and close files
associated with a specific group
To provide an ability to make shared resources (such as file overrides,
shared open data paths, and commitment control transactions) private to a
specific group if you want or need to do so
Q: Aren't all
my RPGLE programs ILE programs?
A: It depends on what options were
used when the RPGLE programs were compiled. If the RPGLE source members were
compiled with the Create RPG Module (CRTRPGMOD) command (which can be done via
option 15 if compiling from PDM), then the programs created from those *Module
objects are definitely ILE.
On the other hand, if the source was
compiled with the Create Bound RPG Program (CRTBNDRPG) command (which can be
done via option 14 if compiling from PDM), then it depends on the value of the
Default Activation Group (DFTACTGRP) parameter at the time of the compile. The
possible values for this parameter are *YES and *NO. *YES means that the program
will run in the special Default Activation Group that exists in every job for
the purpose of running non-ILE programs. But it affects more than just where the
program runs; it also means that the program will be created with options that
make it behave more like a non-ILE program than an ILE program. In other words,
DFTACTGRP(*YES) means it is a program created with an ILE-capable compiler, but
it is really not an ILE program and cannot take advantage of ILE facilities,
such as having subprocedures defined in it or calling procedures or functions
from a service program or running in an ILE activation group.
The
IBM-shipped default value for DFTACTGRP is *YES, so if no one has changed this
default on your system and the parameter wasn't changed at compile time, then
programs created with CRTBNDRPG are not true ILE programs.
By the way,
in case you use other ILE languages in your shop, the CRTBNDCL command also has
the DFTACTGRP option, but CRTBNDCBL and CRTBNDC do not. So all programs created
from source member types CBLLE or CLE are ILE, regardless of the way they were
compiled.
Q: Isn't QILE the default activation
group?
A: No. The use of the term "default" is unfortunate here
because it has different meanings. While it is true that QILE is the shipped
default value for the Activation Group parameter on many of the commands
that are used to create ILE programs, it is not the same thing as the special
activation group that exists in every job by default, which is called the
Default Activation Ggroup (often abbreviated, as I will do here, as DAG).
The DAG exists in every job and is also the starting place for all jobs.
By that, I mean that unless and until an ILE program that requests a different
activation group is called, all programs will run in the DAG. The DAG is the
only non-ILE activation group in any job. (Don't be surprised if you see two
DAGs when displaying the activation groups for a job. One is for system state
code only, so there is only one DAG that is usable for your application
programs.)
QILE, on the other hand, is simply the name of an ILE
activation group that IBM made up, and, as we all know, IBM likes to begin their
names with "Q." It is intended to be a generically named activation group for
ILE programs when the programmer doesn't specify a name but also doesn't want to
use *NEW.
QILE is the shipped default value on the CRTBNDRPG and CRTBNDCL
commands, but it will not appear if *YES is specified for DFTACTGRP. As of V5R3,
QILE is also the default for programs created with Create Program (CRTPGM) if
the entry module of the program is RPG, CL, or COBOL. The shipped default value
of *ENTMOD on the CRTPGM command says that the activation group value of *NEW
will be used for C programs, but for any of the other ILE languages, the value
will be QILE. Prior to V5R3, the default value on CRTPGM was *NEW. So many RPG
programs created prior to V5R3 may still have an activation group value of *NEW
by virtue of that default.
*NEW was found to be a bad choice for the
default value because it was inconsistent with the CRTBNDRPG command and because
it meant that too many programs were being created with *NEW. When overused,
*NEW can be a source of performance and program behaviour issues. When used
intentionally, *NEW is great, but when used by default, its effect is often
negative.
Q: Our production code uses the command
RCLACTGRP(*Eligible). What does this mean, and is it a good
idea?
A: Specifying *Eligible with the Reclaim Activation Group
(RCLACTGRP) command is never a good idea in production code. You can get
some indication of the danger that can arise from using the *Eligible option by
prompting the command in an emulation session. Normally, special values that are
allowed in a command are included on the prompt screen, but you'll find that
*Eligible is not listed. It is included in the help text (F1) behind the screen
because it is a valid option for the command, but its use is discouraged by not
showing it on the prompted command. Let's just say that when IBM first
introduced this option, it seemed like a good idea at the time....
Don't
misunderstand me: There is nothing at all wrong with using the RCLACTGRP
command. It is a great way to clean up programs, close files, etc. in a manner
similar to the old non-ILE RCLRSC command. However, it is best used by
specifying the activation group (e.g., QILE or your own name) rather than using
the generic *Eligible. Why? An ILE activation group is considered "eligible"
to be reclaimed if there is no program or procedure in that group currently in
the call stack of the job. The problem with using the generic *Eligible option
is that you can never be sure what groups are there, and it is far too easy to
reclaim some code that will be needed later in the job. Even if your own
home-grown applications use only one ILE activation group, IBM often creates
activation groups in the users' jobs, as do other software vendors whose
applications your users may have either now or in the future. So take the extra
time to include the specific activation group name you want to reclaim each time
to avoid problems.
I must confess that I do sometimes use
RCLACTGRP(*Eligible) in my own development jobs as a sort of quick and dirty way
to clean up the job between test runs of an application I'm developing. But I
never put it into a CL program that might at some point become included in a
production application.
Q: On our system, the default value for
the Activation Group parameter on the CRTPGM and the CRTBNDRPG (or CRTBNDCBL
and/or CRTBNDCL) commands has been changed to *CALLER. What group are our
programs running in? Is this a good idea?
A: It depends on whether
all the programs in your application have the *CALLER attribute or if one
or more "driver"-type programs use either a named activation group or *NEW. The
*CALLER attribute means the program will run in any activation group where it is
called.
If all the ILE programs in a job have *CALLER for the
activation group, then the ILE programs will run in the DAG (i.e., the job's
non-ILE activation group) because all jobs begin in the DAG. This practice can
cause some very bad problems in applications over time and should be avoided.
ILE programs should not, at least as a general rule, be run in the DAG.
The use of *CALLER by sub-programs that are always called by a program
that uses either a named activation group or a *NEW one is fine. By the way,
this technique was well-illustrated back in March
by Joe Pluta.
Q: Why doesn't my OPNQRYF command work with
my ILE program?
A: While there are a couple of scenarios that
could cause this, by far the most common one is that the CL program containing
the OPNQRYF is still a CLP member type and therefore is running in the DAG. Your
RPG program is running, as it should, in an ILE activation group, whether that's
a named activation group (e.g., QILE or a name of your own design) or *NEW. The
problem that has occurred here is one of scoping of the shared open data path
(ODP) used by the OPNQRYF command. The ODP created by the OPNQRYF is scoped to
(meaning it can only be seen by) the DAG. So programs running in the DAG will be
able to see the results, but those running in any other activation group will
not.
The best solution to this problem is definitely not to run
your ILE program in the DAG. While that option will solve this particular
problem, it will almost certainly cause other, more insidious problems over
time. There are two recommended solutions:
Solution 1: You can put your
OPNQRYF command in a CLLE source member and either bind it with the RPG that
runs in the ILE activation group or just create the CLLE program to run in the
same ILE activation group.
Solution 2: You can specify OPNSCOPE(*JOB) on
the OPNQRYF to ensure that the ILE program(s) running in different activation
groups from the CL can use the shared ODP created by OPNQRYF. In this case, your
CL program can remain a CLP running in the DAG.
Q: Can I mix ILE
and non-ILE programs in the same application?
A: Yes.
Technically, you can mix them. However, you will need to know much more about
the details of how ILE works and how to make it work the way you want it to.
That's the only way to have the two environments live happily ever after in the
same application.
If it is at all practical to do so, running all the
code for a particular application in an ILE activation group is the far easier
answer. The primary issues that arise from mixing program types are ones related
to scoping of file overrides, shared ODPs, and commitment transactions. The
OPNQRYF question above is just one common example of the kinds of issues that
arise. While those issues do have relatively simple solutions designed for the
purpose, you need to know that the issue exists in order to solve it. Scoping
parameters include not only OPNSCOPE, as mentioned above, but also Override
Scope (OVRSCOPE) and Commit Scope (CMTSCOPE). However, the shipped defaults for
the scoping parameters, which exist on many commands (such as OVRDBF, OPNDBF,
OPNQRYF, and STRCMTCTL) are set primarily for an all-ILE (or all-non-ILE)
environment. If all the programs, including CL, run in the same ILE activation
group, there are no scoping issues to worry about.
Questions, Questions, Questions
I hope this article has answered some of your
questions about activation groups, and perhaps it has even raised a few more
questions in your mind. Feel free to ask those other questions. I look forward
to exploring more topics related to developing ILE applications in future RPG
Developer articles. If there are specific aspects that you want to see
covered, let me know in the forum associated with this article.
(c)
System i Developer, LLC
SusanGantner’s career has spanned over 30 years in the field of
application development. She began as a programmer, developing applications for
corporations in Atlanta, Georgia, and working with a variety of hardware and
software platforms. She joined IBM in 1985 and quickly developed a close
association with the Rochester laboratory during the development of the AS/400
system. She worked in Rochester, Minnesota, for five years in the AS/400
Technical Support Center. She later moved to the IBM Toronto Software Laboratory
to provide technical support for programming languages and AD tools on the
AS/400 and iSeries.
Susan left IBM in 1999 to
devote more time to teaching and consulting. She co-authored one of the most
popular System i Redbooks ever, Who Knew You Could Do That with RPG
IV?She and partner Jon Paris make up Partner400, a consulting
company focused on education and mentoring services related to application
modernization. Susan is also part of System i Developer, a consortium of top
educators on System i technology who produce the RPG & DB2 Summit events.
Visit www.SystemiDeveloper.com for
more information.
Commonly Asked Questions About ILE Activation Groups Jul 30 2007 15:29:00
The programs not seeming to be fixed after we change them probably fall into the first category where it was called from a program that had not yet set on LR, although wouldn't ending those calling programs with LR clear that pointer so subsequent calls should get the correct program without doing RCLRSC? <p>The second scenario wouldn't exist in our environment because of my second issue, that of the bleeding edge. "Allowed" would be a better term than "able". That comment was both tongue-in-cheek and a dig - "If it ain't broke, don't fix it." There are times that I think if IBM's Datamaster was still in production, they'd still have me coding in Basic. <p>I have run our programs (about 1500 of them) through a converter and compiled them, taking only a few hours, and the only problems I've had were due to some coding style issues. We had some flags *like defined to *IN90 which were being used for 'Y'/'N' values rather than '0'/'1', and we had some loops based on *ON = *OFF using a LEAVE statement to exit the loop. Both were OK in the OPM programs but would not compile after converting. Some minor code changes, and those programs compiled. That was done two years ago but none of it is being used yet. Meanwhile we still keep maintaining our old programs.
Commonly Asked Questions About ILE Activation Groups Jul 29 2007 15:11:00
I didn't know that *CALLER and *inLR *on causes the static variables in the main procedure (i.e. the global variables), i only thought about the files being closed when *inLR is *on, but i didn't really give it much thought. Because, to keep it simple, i don't use *inLR to control resource mgt, only AG's. So in case of *NEW i set *inLR *on just for compatibility (but in fact it has no use because everything is cleanup up already), and in case of *CALLER i never set *inLR on because it gets complicated and unnecessery tot take into account the situation that only the files must be closed and global vars initialized, but nothing else. It's all or nothing. In most cases, u want to use *CALLER to keep files open, and to keep the globals. If further control is necessery one can explicitly reinitialize vars and use %open and open (with usropn etc). In my opinion, this results in more clear code, without too many side effects and "insider" information. <p>gr. jacobus
Commonly Asked Questions About ILE Activation Groups Jul 26 2007 17:42:00
"You do not have to use ILE features in order to use RPG IV." It is amazing how certain phrases inspire us as words of wisdom, while to the statesman it would be just another statement. <p>In 2000, I was locked in a battle of opinions with my I.T. Manager who was of the view that RPGIV meant dealing with ILE and nobody had ILE expertice. My repeated answer was exactly what you quoted from Paris. <p>Well, finally she was replaced by a new manager who gave me a free ticket with the condition, "If anything goes wrong, it will be your ass that will be grass". <p>A couple of years later, and I had left the company by then, everything was converted to ILE and /free!!!
Commonly Asked Questions About ILE Activation Groups Jul 26 2007 16:14:00
I certainly agree with you that if choosing between *CALLER and *NEW as a default, I much prefer *NEW. Personally, however, I wouldn't choose either of those as a default. I don't see a compelling reason not to use the current (as of V5R3) default of QILE. In one of my earlier posts, I explained my reasons for preferring a named AG over *NEW, so I won't repeat myself here. IBM changed the default on CRTPGM in V5R3. They very, very rarely change shipped defaults. I have to believe it's because they saw enough shops having problems with *NEW as the default as it was prior to V5R3. <p>One thing I'd like to point out related to your post - the programmer only needs to make sure that variables are properly initialized with *CALLER IF the called program is NOT setting on LR. Even with *CALLER, LR closes files and reinitializes static variables in the main procedure as it did before. The exceptions to this are variables specifically marked STATIC in subprocedures. I suspect you know this and these are the ones you are concerned about initializing, but I wanted to make sure other readers don't get the wrong idea about initialization and *CALLER. <p>All that said - if *NEW in thoughtful combination with *CALLER is working for you and your shop, keep up the good work. Staying out of the DAG is the primary goal and it sounds like you've found a workable solution for your applications.
Commonly Asked Questions About ILE Activation Groups Jul 26 2007 15:44:00
" You might remember that too!!" <p>I'm assuming that was aimed at the OP David and not me - actually there's a pretty good chance that it was me that said it! <p>This mixed-up notion that RPG IV must use ILE is the sad result of IBM having chosen a really silly name for the compiler i.e. ILE RPG. And yes I was part of the group that made that decision and yes I didn't fight it hard enough!!
Commonly Asked Questions About ILE Activation Groups Jul 26 2007 11:10:00
Since my advocacy of *NEW/*CALLER is well known, I wanted to stay out of this and let everybody weigh in. But let me respond now: <p>First, I think Jon's point is that ACTGRP(*CALLER) called from OPM programs will eventually bite you. It will work fine for a while, but eventually it will break, and when it does you will be in for a world of hurt. I absolutely concur. Don't do that, it's a time bomb. <p>On the other hand, I don't agree quite so fully with Susan's assessment of *NEW/*CALLER, particularly her concern that shops won't get it right. Yes there is a possibility of programming it wrong, but there's a possibility of programming anything wrong. If you really thoguth that was an issue, you could program all of your *CALLER modules to check for the activation group via the QWVRCSTK API. <p>Because while the idea of a single named activation group with RCLACTGRP as necessary works for some people, it doesn't work for me. That's because I have to count on some external program to be sure that my stuff is initialized correctly, whereas with *NEW/*CALLER I know that when my *NEW program ends, the next time it starts it starts with a clean slate. If I'm counting on that and the calling program "forgets" to perform a RCLACTGRP, then I may get errors that can be every bit as painful as those caused by running in the default activation group (and sometimes very difficult to diagnose, because they're data specific and depend on the LAST time the program ran). <p>Joe
Commonly Asked Questions About ILE Activation Groups Jul 26 2007 10:57:00
This is an important issue. You can use nearly all of the capabilities of RPG IV wihtout going to ILE. In fact, the only thing you can't use is procedures. You CAN use prototyped calls to external programs and APIs, you just can't bind to service programs or use internal procedures. <p>What you do get is incredible. Long field names, new field types, a plethora of powerful BIFs, the ability to get rid of indicators, easier interface to APIs, the list goes on and on. <p>Joe
Commonly Asked Questions About ILE Activation Groups Jul 25 2007 14:03:00
<i>Jon Paris wrote: Do you mean the only place you have been _allowed_ to use it? You could convert your entire system to RPG IV tomorrow, compile with DFTACTGRP(*YES) and you probably wouldn't notice the difference. </i> <p>Considering the power of the CVTRPGSRC command (free) and other similar tools (not free) there really is no excuse (IMO) not to go to RPG IV. <p>I do remember attending a seminar a few years back where the opening line was "You do not have to use ILE features in order to use RPG IV." You might remember that too!! <p>Dave
Commonly Asked Questions About ILE Activation Groups Jul 25 2007 12:57:00
"Actually the programs that don't seem to be fixed after changing them are OPM" <p>There are two main causes for this: <p>1) The OPM program was called by another OPM program and that program has not yet set on LR. As a result the pointer it has stored to the changed program still points to the old PGM object. This is situation normal and has nothing to do with ILE. RCLRSC should cure it - there should be no need to sign off. <p>2) The OPM program was called from a *CALLER ILE program running in the DAG which has not set on LR. Scenario is as at 1 except the ILE program is unaffected by RCLRSC and therefore sign-off is the only solution. This is the kind of situation that both Susan and I have mentioned. ILE programs are not designed to run in the DAG and you need to know a lot about ILE to do it safely and consistently. <p>"So far, about the only places we have been able to use ILE programs ..." <p>Do you mean the only place you have been _allowed_ to use it? You could convert your entire system to RPG IV tomorrow, compile with DFTACTGRP(*YES) and you probably wouldn't notice the difference. <p>Well you would notice a difference. The programs would be more readable, probably run faster, be easier to modify, and you'd be able to use the improved language features. And by the way you wouldn't have any of the problems you seem to associate with ILE - because you wouldn't be running ILE programs. Just RPG IV pretending to be OPM. This is really a no-brainer. <p>"We don't want to be on the bleeding edge of technology, you know." <p>I'm hoping and praying that you said that tongue in cheek - or at least as a dig at your management. RPG IV stopped being leading edge (it never was bleeding edge) at least 10 years ago.
Commonly Asked Questions About ILE Activation Groups Jul 24 2007 09:55:00
Hi jacobus, <p>I agree with your point that Activation Groups are not that complicated and can be quite useful. Thanks for voicing some of the the positive sides of them for this discussion. <p>I'd like to comment on one of your points. Your comparison of *NEW to setting on LR is close but not 100% accurate. Setting on LR in an ILE program does close the files and sets the static fields in the program up for re-initialization. But it doesn't clean up or deallocate the static storage for the program in the user's job. Reclaiming the Activation Group - either explicitly or implicitly by means of using *NEW - does actually clean up all the storage of the program. Most of the time, this subtle difference doesn't matter to the behavior of the program, although it can make a performance difference.
Commonly Asked Questions About ILE Activation Groups Jul 24 2007 07:19:00
Hi, <p>I'm not sure if using *CALLER as the default instead of *NEW is a good idea. I think it makes a big difference if *NEW is used "by default" and only to use *CALLER in performance critical situations. Using *NEW results in more robust programs because all resources are automatically cleaned up and memory is reinitialized when the program is called again (to which we are used to in the OPM environment). With *CALLER the programmer has to make sure that variables are properly initialized. In any case, it takes some thought using *CALLER. Using *NEW is simple and behaves the way we are used to. All variables are initialized so there is no chance one is missed. But using *NEW has impact on performance, but general wisdom says that 80% of the time is spent in 20% of the code. So one could use *CALLER only in these 20% of the code, or if it is needed for some special functional requirement. Using *CALLER by default seems to me a bad thing. <p>gr. jacobus
Commonly Asked Questions About ILE Activation Groups Jul 23 2007 23:15:00
tiki wrote:<BR>
> The default activation prompt now showing when compiling SQLRPGLE<BR>
> (option 14 or 15) program. Do I have to manually insert it on H<BR>
> Specs. <BR>
<P>
TIKI, it's best to put it in the H specs, since that way you don't have <BR>
to always remember to use CRTSQLRPGI correctly.<BR>
<P>
But if you really want to do it on the SQLRPGLE compile, you can use the <BR>
COMPILEOPT parameter of CRTSQLRPGI, COMPILEOPT('DFTACTGRP(*NO)'). <BR>
(COMPILEOPT is available starting in V5R3 for all the CRTSQLxxx commands.)<BR>
<P>
Commonly Asked Questions About ILE Activation Groups Jul 23 2007 22:26:00
Hi jacobus, <p>I agree with your point that Activation Groups are not that complicated and can be quite useful. Thanks for voicing some of the the positive sides of them for this discussion. <p>I'd like to comment on one of your points. Your comparison of *NEW to setting on LR is close but not 100% accurate. Setting on LR in an ILE program does close the files and sets the static fields in the program up for re-initialization. But it doesn't clean up or deallocate the static storage for the program in the user's job. Reclaiming the Activation Group - either explicitly or implicitly by means of using *NEW - does actually clean up all the storage of the program. Most of the time, this subtle difference doesn't matter to the behavior of the program, although it can make a performance difference.
Commonly Asked Questions About ILE Activation Groups Jul 23 2007 22:13:00
Hi Erick, <p>It is typically easier and simpler to manage an application environment that is either all ILE or all OPM. This is due primarily to the Activation Group scoping issues than can/will arise when there are 2 groups (and ILE one and the DAG) involved. So if you have some ILE programs in an application, I would say yes, it would be easier to convert the OPM programs to ILE and have them all running in the same Activation Group. It requires less knowledge of ILE to work that way. Besides, if the OPM programs are not even RPG IV, I would advise converting them if only to gain access to a more powerful language. <p>That said, the 2 environments can interact - it just takes more knowledge of and attention to things like scoping of overrides, shared opens and commitment control definitions.
Commonly Asked Questions About ILE Activation Groups Jul 23 2007 19:46:00
The default activation prompt now showing when compiling SQLRPGLE (option 14 or 15) program. Do I have to manually insert it on H Specs. <BR>
Thanks, <BR>
TIKI
Commonly Asked Questions About ILE Activation Groups Jul 23 2007 14:49:00
I understand your sentiments concerning ILE implementation. <p>OTOH I believe that after thirteen years of ILE being around, the bleeding has stopped. <p>Dave
Commonly Asked Questions About ILE Activation Groups Jul 23 2007 12:13:00
Actually the programs that don't seem to be fixed after changing them are OPM programs, since we have very few ILE programs, and signing off and back on seems to be the only way to get the machine to recognize the change when that happens. So far, about the only places we have been able to use ILE programs are where we need functions that are not available in OPM. We don't want to be on the bleeding edge of technology, you know.
Commonly Asked Questions About ILE Activation Groups Jul 22 2007 13:25:00
Hi, <p>I "use" activationgroups all the time, for every ILE program, i.e. i'm aware of activation groups. In practice, to me they have added value, and only introduce one more choice. Each time i create a program, i make a conscious descision about whether to choose *NEW or *CALLER for the activationgroup. In principle, the default choice for me is *NEW, because this ensures that everything is cleaned up when the program ends, e.g. allocated memory. In some cirumstances, when performance is critical, i use *CALLER, so that all resources are kept in memory when the program ends, and will be still there when the program is called again. So, with activation groups you have more control over the system's behavior regarding allocating and releasing resources. If you don't make use of dynamically allocated memory or any other resource you have to allocate yourself in the program besides files then setting LR on will have the same effect as choosing *NEW. However, with *NEW it's guaranteed that alle resources are clean-up, especially because you can't know everything (like what happens in that program you call which is not yours). Activation groups are not complicated and quite essential in the ILE environment. <p>jacobus
Commonly Asked Questions About ILE Activation Groups Jul 21 2007 00:43:00
This DFTACTGRP(*NO) ACTGRP(*CALLER) combo often "works" for as long as you don't have service programs (SPs) in the mix. Particularly SPs that use files. As soon as you have that situation then we're into a scenario of driving the wrong way down the highway. It is no longer a question of _if_ you have an accident but _when_. <p>As I believe Susan noted earlier - ILE programs were not designed to run in the DAG. They _can_ run there, but in order to run them in all combinations with any degree of safely you need to know a heck of a lot more about ILE than I do - and I helped design it! On the other hand, to use ILE the way it was designed to be run - i.e. ILE programs run in AGs other than the DAG - requires little knowledge of ILE and is perfectly safe requiring only basic knowledge of resource scoping rules. <p>If you use a software combination where even IBM can't tell you exactly what can go wrong and when, then you have a problem, why take the risk when the "proper" option is easy and avoids all of this?
Commonly Asked Questions About ILE Activation Groups Jul 20 2007 12:33:00
In a recent article (<a href="http://www.mcpressonline.com/mc?.6b506c7a">Forum Decorum</a>) I focused on "forum decorum", that nebulous concept of appropriate behavior in an online forum. In it, I noted that phrases that concentrate more on the poster than the post are not really welcome here. For example, above you state that activation groups are a source of "technical snobbery" and provide "a vague sense of superiority for those who use this obscure feature". <p>Well, since Susan is writing about activation, that would imply that she's a technical snob. Even if that wasn't your intent, it's the predictable result of a response like this that starts out with an antagonistic tone. It's particularly ironic that you chose Susan to unload upon, since she is perhaps the least snobbish of any of the "name" writers in this community. Susan is perhaps the best in the industry at making advanced topics accessible and productive for new users. <p>Anyway, enough on this. I just wanted to point out that your tone could be taken as somewhat rude and needlessly confrontational. Add to that the fact that you did it anonymously taking advantage of the bug in the forum software and the entire post is just a wee bit on the combative side for me. <p>Joe
Commonly Asked Questions About ILE Activation Groups Jul 19 2007 12:39:00
The scenario you describe – using *NEW for specific programs in combination with *CALLER for others is fine. I believe this is a similar idea to the architecture that Joe Pluta described in his Tech Tip in March. If this approach is working for you, go for it. <p>My biggest concern about this approach the requirement for enough consistency and discipline within the shop to stick to this architecture. <p>What I mean is that it only takes one of those *CALLER programs being called from one OPM program to start an entire string of them in the DAG. The fact that you’ve witnessed the dreaded “I recreated the PGM and it’s still doing the same thing as before” situation indicates to me that it may have happened in your shop. Maybe it was before you had this architecture in place. <p>By the way, speaking of that “it’s still doing the same old thing” situation – it is not necessary to sign off to fix that situation. You need only reclaim the activation group the programs are running it. Unless, of course, if they are running in the DAG, because it’s the only Activation Group that can’t be reclaimed. A good enough reason not to use it for me. <p>Personally, my own preference is to use a named Activation Group for everything – just one unless I have a need for scoped overrides as you describe. Then if/when I feel I need to reclaim the Activation Group for some reason, I just do it. It doesn’t seem like a big chore to me to code RCLACTGRP(QILE) after the call to that first ILE program in the stack (the one you code as *NEW). In my experience, if someone forgets to do the reclaim the results of that error are usually less dangerous and/or at least more predictable than the situation where ILE pgms are running in the DAG by mistake.
Commonly Asked Questions About ILE Activation Groups Jul 19 2007 12:00:00
Virtually all of our in-house developed programs are compiled with DFTACTGRP(*NO) ACTGRP(*CALLER), and we have not experienced any problems. That allows us to use procedures without having to worry about Activation Groups. <p>Every time the question of Activation Groups comes up at department meetings, the big question is "Why bother?". The only answer so far has been for minor performance gains.
#116665
There are too many comments to list them all here. See the forum for the full discussion.
