|
midrange.com
Buck,
This is a very nice example of how to organize activation groups (AGs), but
what is the real benefit? When I first started ILE about eight months ago I
never saw any real advantage to them. In OPM the only time I ever used an
open data path (ODP) is when I did an OpnQryF just before calling a program
and then deleted it before moving on to the next program. AGs seem to add a
lot of complexities to RPG programming. I believe it is the primary block
to getting programmers to convert to ILE. I don't just mean RPG IV, but
real ILE. The ILE concept book makes a big deal out of ODPs, but like I
stated earlier. I hardly use them.
Patrick Conner
www.ConnecTown.com
(828) 244-0822
Buck Calabro
<buck.calabro@aptissof To: rpg400-l@midrange.com
tware.com> cc:
Sent by: Subject: Named Activation
Groups (was: DoW
owner-rpg400-l@midrang (WAS DoU...))
e.com
12/20/00 09:49 AM
Please respond to
RPG400-L
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
+---
+---
| 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
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
