When creating an ILE RPG program why should default activation group name of QILE be avoided

Question

According to Paul Tuohy's style guide, and other sources I'm sure I've read before, the default activation group QILE should be avoided when creating ILE RPG programs. However, Googling this subject I can't seem to find out the reason for this.

According to this pdf presentation QILE is often used by the system, could this why it should be avoided?

Here is a reference to QILE being a poor choice of activation group but no reason given.

Answer 1

I think it was me who initiated the idea that choosing QILE was not the best idea. I stand by that, especially if you are a third-party application as Mark mentioned, or even if you do or might use third-party applications that use QILE.

If I didn't have any particular reason to choose one activation group over another, I'd have my own non-specific activation group rather than using QILE.

Answer 2

It appears from the linked style guide that Paul Tuohy objects to QILE simply because it is a default named activation group name, and for no other reason. He is really objecting to folks not intentionally choosing a named activation group name.

This is the activation group that is used when care has not been taken to choose the activation group. If care was not taken to choose the activation group, care may not have been taken in other aspects of the application...

I generally will use QILE as a named activation group if I am using named activation groups. The reason is that given no special circumstances, there is no good reason not to use it. If I have special circumstances, then I will use a named activation group that reflects the special circumstances. For example I once created a message broker that operated with exit programs that processed specific message types. I did not end the exit programs when they ended. This had the effect of improving next call performance because the programs did not have to be reinitialized. This also had the effect of keeping certain files open. I had a requirement that at times I would need to get a lock on some of the files left open by the exit programs. In order to obtain that lock the files needed to be closed in the message broker jobs. But the message broker jobs neither knew which exit programs had been run, nor which files those exit programs had open. To solve the problem, I put these exit programs in their own activation group which I could reclaim to close any files. By suspending the message broker, and reclaiming the special activation group I was able to close all the files held open by the exit programs. My other process was now able to gain a lock on the files. When I was finished, I resumed the message broker, and the exit programs regained their locks as they were needed.

The point is that you should be intentional about which activation group to use. I prefer to use *NEW in the CLP that begins a process, and *CALLER for all the called programs and service programs. *NEW gets me out of the default activation group and into a fresh activation group that will end with the program that starts it. *NEW also lets an RPG program to be called recursively. But I do not like to use *NEW everywhere because that causes excessive activation group creation, and activations are somewhat time consuming, particularly if you do it frequently. Know your application, and design an Activation Group strategy. If you do that, QILE can be a part of it, and you won't have any surprises.

Now if you are developing application for use by a third party, QILE might not be such a good idea because you could have unexpected consequences when someone else reclaims your activation group without you knowing it. Or you might reclaim someone else's activation group on them, or you just might not be able to do the reclaim you needed. In this case it is best to avoid QILE because most people who use names activation groups do just use QILE, and you don't want to affect applications that you have no control over.