Commonly Asked Questions About ILE Activation Groups

[jrbromm]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
The way I understand activation groups, the following practices seem to me to be the way to go. I hope someone with more understanding will correct me as needed. A job that is to be run from the command line, a menu, or as a submitted job should start with a program set to activation group *new. Any program called by this initial program should be set to activation group *caller unless it has has some special need for overrides that would be outside that of the initial program, in which case it also should be in activation group *new. When a program is created to run in a named activation group, a bunch of garbage (overrides, work space, and who knows what else) is left over when it ends that has to be cleaned up, either by running RCLACTGRP or by signing off the session. When a program is created to run in activation group *new, all this garbage is automatically cleaned up when that program ends. Sometimes you see indications of this garbage when you run a program, notice some changes that need to be made, make those changes and recompile the program, and when you run the program again, the changes don't seem to be there. It's not until you sign off and sign back in and then rerun the program that the changes show up. Signing off is a way of getting that garbage cleaned up. By having the initial program set to activation group *new and programs called by this initial program set to activation group *caller, not only is all the garbage caused by the initial program cleaned up when that program ends, but all the called programs' garbage is also cleaned up. This means that I no longer need to delete overrides done in those called programs. I also don't have to do a final call to any reentrant programs (programs that return to the caller with *INLR left off) in order to set *INLR off. There may be cases where overrides have to change several times during the running of a job. In this case, I may want to treat each of these cases as a separate job and have the starting program there also set to activation group *new. An example might be an inquiry program showing a list of items where each time an item is selected from the list, a report is printed to a different printer based on the class of the item. The inquiry program would be in a *new activation group, and the print program with its overrides to the printer would be in its own *new activation group so its overrides would be cleaned up as it ends and returns to the inquiry program. Most of the literature I've seen seems to say to avoid using *new as an activation group because of the overhead in creating and cleaning up after itself, but I would think that overhead is insignificant when used as above. The place where you would not want that overhead is in a report or posting program where thousands or millions of records are being processed and a program is being called for each of these records. That called program should not be set to *new. There may be cases where named activation groups might be useful. A service program which is used throughout the system might be an example. Its activation group could start as you go into your first task of the day and stay active until you sign off at the end of the day while each task would be doing its own cleanup as it ended leaving the service program active for other tasks to use.

[gantner]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
I'm new to the MC Press team, but based on some of the articles I've read I was left with the impression that many of the readers are into using ILE already and so I didn't feel it was necessary to start at the beginning. The purpose of this article was to provide some answers for some of the questions I get asked all the time. These are questions from people who apparently do see some benefit in utilizing ILE features. This piece wasn't intended to "advertise" anything so if it that's the way it came across, perhaps I wasn't clear enough. I had no intention of convincing anyone who wasn't using ILE that they should. If you are not convinced of the usefulness of ILE, then there's no reason to use it and therefore no reason to use Activation Groups. Perhaps the whole “why ILE” question could be explored in a future article, although I prefer these days to write about more practical tips for those who have already made the decision for ILE. In my experience, most folks who have a need for ILE seem to understand the “why” without my help and have more need for the “how”. Bottom line, if you're going to use ILE facilities in your applications, then you should use at least one ILE activation group simply because that's the way the environment was designed to work. That means that you should also understand some of the facts discussed in this piece.

[Guest.Visitor]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
In some circumstances, I have seen ILE programs call older OPM programs. Personally, I don't like that architecture, but I wondered if you could comment generally on the interoperability of two. For example, do you highly recommend the OPM programs be converted to ILE with the activation group set as *CALLER, or set as the same named activation group? Thanks for your input. Erick

[gantner]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
I happen to think the ability to call C functions from RPG is very useful, but it’s far from the only reason – not even the best reason - to use ILE, IMHO. Far more useful to me, for example, is the ability to write my own functions in RPG – true functions that return values and are used much like RPG’s built-in functions from expressions. It’s almost like allowing me to extend RPG for my own specific application needs. It doesn’t need to have anything at all to do with calling C. I don’t think ILE – including using Activation Groups – is particularly complex. It’s just different from our pre-ILE world and that involves learning new things. As I alluded to in the response to the last FAQ in the article, it is often made more complex than it needs to be by trying to mix ILE and non-ILE in the same application. But the best part, to me, is that we, as RPGers, are able to take advantage of so many of the features of the advanced language (e.g., dates, built-in functions, expressions, XML parsing) without any need of learning about ILE, binding, Service Programs or Activation Groups. The ILE COBOL compiler doesn’t have a DFTACTGRP(*Yes) option so COBOLers must learn, to some extent, ILE in order to use the new language features.

[JohnFox]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
We make extensive use of ILE and have a huge legacy of non-ILE programs that go back to the days of the System 38 running on our i5 system. All of our ILE programs are DFTACTGRP(*NO) ACTGRP(*CALLER) and in most cases, our ILE programs are called from the non-ILE programs. You mention that it is not recommended to call ILE programs and allow them to work within the default activation group (which is how the majority of our solution works today by virtue of the settings above) because there are problems that could occur. Unfortunately, you do not elaborate on any details as to what problems could occur. I am very concerned that I may be sitting on top of a ticking time-bomb and would greatly appreciate it if you would elaborate on the kinds of problems that can occur in this setting so that I can understand how they could potentially impact my systems. Thanks.

[Guest.Visitor]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
Yeah, I'd sure like a more detailed explanation of "can cause some very bad problems" too. I did have an issue once with using an ILE feature inside an RPG IV *CALLER program where the caller was an OPM CL. I registered the cancel handler 'CEERTX' and the program would inexplicable zero out an order number in a file, about 1 per day. I yanked that mod out of production after about 3 days. And I always code my service programs as activation group QILE or something named anyway. But most of the RPG IV programs that only contain one procedure (the main procedure) run as *CALLER and so in the DAG. Chris

[gantner]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
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. My biggest concern about this approach the requirement for enough consistency and discipline within the shop to stick to this architecture. 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. 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. 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.

[lujate]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
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. 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.

[gantner]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
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. My biggest concern about this approach the requirement for enough consistency and discipline within the shop to stick to this architecture. 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. 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. 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.

[J.Pluta]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
In a recent article (Forum Decorum) 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". 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. 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. Joe

[JonFParis]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
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_. 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. 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?

[jacobus]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
Hi, 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. jacobus

[jrbromm]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
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.

[David Abramowitz]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
I understand your sentiments concerning ILE implementation. OTOH I believe that after thirteen years of ILE being around, the bleeding has stopped. Dave

[Guest.Visitor]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
The default activation prompt now showing when compiling SQLRPGLE (option 14 or 15) program. Do I have to manually insert it on H Specs. Thanks, TIKI