Named Activation Groups (was: DoW (WAS DoU...))

Jon Paris wrote:

>PS.  What on earth is wrong with named AGs?  Since they are 
>the foundation for ILE (i.e. the way it was designed to work) 
>I find it hard to guess at what you find wrong with them.

The basic issue is one of tracking.  A tool like Pathfinder helps
considerably, as does a firm grip on creating new named AG's.  A basic
naming standard would help tremendously, but people who are new to ILE
haven't the experience to put one together.

Here's a theoretical setup to be kicked around for discussion:

A/R menu actgrp(AR)
  A/R inquiry actgrp(*caller)
  Apply payments actgrp(*caller)
G/L menu actgrp(GL)
  G/L inquiry actgrp(*caller)
  P&L statement actgrp(*caller)
A/P menu actgrp(AP)
  Vendor inquiry actgrp(*caller)
  Purchase orders actgrp(*caller)

Interest calculation service program actgrp(*caller)

We get a call from customer x.  She wants to order shopping bags imprinted
with her store's name and logo.  We go to the A/P menu.  We're in
actgrp(AP).  Take the option to search for a vendor and we're still in
actgrp(AP) because of *caller.  Once we've found the vendor, we start to
enter the P/O.  During the course of entering the P/O, we're prompted to
look at the customer's A/R standing because of the amount of the special
order.  We take the function key to A/R inquiry and stay in actgrp(AP)
because of *caller.  You see the pattern.  We will stay in actgrp(AP) until
we go back to a menu and start a new AG.

This style basically ties the AG to a business process - until we start a
new process we stay in the same AG.  Flaws: 1) Can't share file overrides
across traditional menu boundaries.  This means that we need to be extremely
careful about shared file opens.  If we're in the A/R inquiry with a shared
open and look at a different customer we've repositioned the file pointer
for the P/O entry process.  2) If the user does the A/R lookup first
(they're experienced and know it's coming) then we've got two AG's going -
AR and AP.  If we're intending that the file pointers be shared among all
programs in the same business process, we'll be disappointed.  3) Who knows
what I've forgot?

Back to tracking, if I need a new "top level" AG, how do I know that the
name I choose isn't already in use by some other "top level" program that
somebody else is developing?  Or has deployed to another division that I
don't know about?  Or intends to deploy to a customer's box?  (Think about
the implications of the Attn key.)  What if I need to force a program into a
"top level" AG - how can I readily determine the AG name of the Human
Resources application?  Tracking the name is mixed up with "why should I
create an AG (and name it)?"

I think that a discussion of how and why to use named activation groups in a
real business environment would be immensely helpful to ILE newcomers.  I
myself advise newcomers to use exactly one AG for client programs: QILE.
This is the closest model to the OPM environment for overrides and shared
file opens.  Until complete application suites are released that use shared
file opens, I don't think that there's a business need for multiple named
activation groups.  Service programs should always be *caller I would think.

I hope I'll get disagreement because I'd like to learn something on this
topic.  

Buck Calabro
Aptis; Albany, NY
"Nothing is so firmly believed as
 that which we least know" -- Michel Montaigne
Visit the Midrange archives at http://www.midrange.com
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---