Re: Activation Groups/SQL Suggestions

> Buck wrote:

The only way to know is to measure. I'm not being sarcastic in the least. 500 open files per user might be a light load for your particular configuration, and a crushing load on another. In general, i5/OS has an extremely good virtual memory paging heuristic. I personally would not worry about performance until I measured it.

I agree. One approach could be to instrument top-level driver (CL) programs to keep track of how often they are invoked (for example, recording a date/time stamp of the last invocation, etc. -- maintaining a small history database of how frequently each unique user invokes each menu item. Then, based on this, the application itself could decide that, for this userID, they don't use this menu option very often, so let's just issue RCLACTGRP whenever they exit this option, while, for another menu option, this user uses it "often" during a typical day, so let's leave the AG active.

More to the point, activation group strategy is not a construction decision, it is a design decision. Changing that strategy in the middle of construction might generate a fair amount of rework. The point of multiple activation groups is to allow for multiple applications to co-exist; to let the A/R point to customer 100 and let order entry point to customer 50 at the same time.

Good point -- having separate AGs is like having several "mini-jobs" within a single job (usually an interactive session). (The older CPF concept of "group jobs" also provided a similar function; these were actually separate jobs, running round-robin, on behalf of the same user -- only one of them was 'active' at any one time.)