Re: Activation Groups/SQL Suggestions

Mark S. Waterbury wrote:

Consider making the "top-level" or "launcher" programs use a "named" actvation group, rather than *NEW. (This could be the same as the program name.) Then, you control when it is time to force a "clean-up" of each named activation group, e.g. by issuing RCLACTGRP ACTGRP(name) from a CL program, for example.

This is very much a design decision, so it really depends on your situation. And you're not the only one to suggest a named activation group. But here's my reasoning against the idea: when do you do the reclaim, and how do you know what to reclaim? Say you've got 20 menu options - is each one its own AG? When do you reclaim? Do you have to remember which one is the last one you called and don't do a reclaim if you're executing the same option? There also has to be a hardcoded list somewhere specifying which option belongs to which AG; that's one more maintenance step.

And for what? To save the time to open the AG in the case where the user calls the same option twice? Since it only happens during an actual display wait (for the next menu option to execute), it seems a little bit of over-complication for something that the user isn't likely to even notice.

Now, there may be something to be said for leaving some files open. If lots of your programs leave files open and don't set on *INLR and especially if they share access paths, then leaving an AG open may make more sense. But if your menu options essentially start from a clean slate, opening files and initializing variables, then the *NEW/*CALLER architecture works very well and doesn't require generating and maintaining AG names for every option and without worrying about coding RCLACTGRP to clean up after yourself.

Just my thoughts on the concept.

Joe