Re: Activation groups -- RPG400-L

At one point, I thought named activation groups were shared across jobs,
which then made them very attractive, but since that's not the case, I have
a hard time understanding the benefits of a named activation group.  The
housekeeping involved with having to manually shut down the activation group
makes them unwieldy to me.

In days of yore, when had to spin our disk platters by hand :-) it tooka long time to open a file. As applications grew in size, they usedmore files. On a low end machine, a proven mechanism for increasingperformance was to use shared opens. That is, the initial program opensall the crucial files, does an OVRDBF fff share(*YES) and then calls themenu.

Every subsequent open in RPG (whether user open or cycle open) does apseudo-open which shares the file cursor with all the other programs inthat job. One penalty for that is very tight coupling between programs.If program A is in a read loop and calls program B (like a subfilesummary/detail situation) when B finished, the file pointer in A isn'twhere A left off: it's where B left off. So A and B need to be aware ofeach other's actions against the file.

Another problem was cross application support. When program A is acustomer list, B is a detailed customer display and either one can becalled from A/R and G/L, then the tight coupling crosses applications!The G/L system needs to be aware of the A/R system and vice versa.

At the very least, you need to code all of your programs as if they haveno clue where they are after calling another program. Yuck. But it wasfast, especially coupled with RETURN (no LR).

It sure would be nice if we could keep the shared files in the A/Rsystem separate from the shared files in the G/L system. Thus, namedactivation groups.

*NEW/*CALLER doesn't help because you only get *NEW at the top of themenu tree. When G/L program F calls A/R program A directly (not througha menu) then A, A and B all live in the same activation group. If youhad named AGs, you could readily avoid this problem by naming the G/Lprograms something clever like GL and the A/R programs AR.

Under this convention, F (GL) has CUSTMAST open and shared and calls A(AR). A (AR) opens its own CUSTMAST, not sharing with F (GL). But whenit calls B (AR), B does a pseudo-open of CUSTMAST and share with A (AR).Both A and B remain independent of F.

Admittedly, there are apparently very few places who share ODPsdeliberately outside of the odd OPNQRYF which makes this a bit academicfor most everyone reading this. But it might give someone an idea ofhow named activation groups might fit into their future designs,especially when coupled with Larry's concept of 'common crossapplication code.'

  --buck