Re: ILE activation group strategy...I need help/advice

Tony,

Here is a description of our activation group environment. It has worked well 
for us and was easy to implement.

The first rule is that every module is used in no more than 1 program or 
procedure with two exceptions.  The exceptions are our entry program, and error 
processing/cleanup routine. The next rule is that service programs do not 
contain both statically and dynamically called procedures.  Service programs 
with statically called procedures have binding source.  Service program contain 
logical groups of modules to reduce circular references because this makes 
moves to production more difficult.  We also maintain a catalog and cross 
reference of system objects and procedures.  The catalog supports object 
creation, signatures, binding, and dynamic calls.

Every users starts with an initial program that has an activation group. This 
allows us to run programs with *caller from a command line in a named 
activation group. Without this, *caller programs will run in the default 
activation group.

For most of our users and staff the initial program calls an OPM menu system 
supplied by IBM. When an option is taken this menu system calls an interface 
program that we supply. This interface program determines the environment (TEST 
or PRODUCTION) and transfers to another interface program that establishes 
library list, authority, and activation group. This second interface program 
executes the program/command passed to it with the parms supplied. 

All programs/service programs except the interface, initial, command processor, 
database trigger, and vendor interface programs specify *CALLER. The command 
processor programs specify *NEW, and database triggers specify TEST for files 
in the test system and PRODUCTION for files in the production system. We have a 
single trigger entry program which is duplicated in production and test 
libraries.  For vendor supplied programs that call our ILE environment programs 
we supply an interface in both our test and production environment. 

This has been easy to set up and has proven to be flexible and safe. Our 
biggest question was whether we should use a named activation group for major 
function such as order entry, accounting, payroll, etc. We went with the 
simplest, although this would have just required a few
more interface programs that had named activation groups.  The weakest link is 
that files can only be scoped to production or test.  I am considering 
enhancing the trigger entry point program to dynamically set the activation 
group to either production, test or *new.

David Morris

>>> "Tony Corbett" <corbett@CBT400.COM> 04/15/99 05:16PM >>>
HELP!
I am trying to devise a good (maintainable) activation group strategy.
This is a pretty large company (second largest food distributor in the nation)
with a lot of users and programs, probably 200+ workstations online in house 
and about 50 remote users, mostly PC workstations,
running on a 510 with 1G memory and about 75G disk used on V3R7.  We(they) plan 
to
go to a 7xx model (and V4) within about 6 months.  Internet-stuff is handled 
with an NT server.

Everything I come up with seems lacking.  
I am in an environment with mostly consultants (or contract programmers, 
depending on your frame of mind today) and I have been assigned the task of 
piloting the ILE changeover with a subsystem I'm currently working on, with 
many constraints:
1. We will be in a mixed OPM and ILE environment for some time
2. The strategy must be maintainable, with very little thought on the part of 
the programmer
3. The environment is relatively lax in the way of standard methodology
4. Some of the programmers have little knowledge of ILE.
5. Programs and menus are in an almost constant state of modification.
6. A lot of subprograms called from RPG end with LR off, prompt programs in 
particular.
7. Menus are not "real menus", i.e., use dspf with a clp driver (I call this 
38-style)
8. Everybody in the IS dept (and their close relatives) have group profile 
QSECOFR
9. There is no file-sharing across pgms.
10. I am a consultant and can change none of the above.

Everything is pretty straight-forward, with the exception of how to handle 
activation groups in
a way that will not get screwed-up in maintenance.
My latest revision of a plan:
1. Create one (large) binding directory and CHGCMDDFT on CRTBNDRPG command to 
use it
2. Change the "create rpg module command"  to add all modules to this binding 
directory
3. CHGCMDDFT on CRTBNDCL to use the binding directory and ACTGRP(cl pgm name)
4. Compile ALL rpgle pgms with ACTGRP(*CALLER)
5. In the CL pgms, immediately follow a CALL "clpgmname" with RCLACTGRP 
"clpgmname"

Is this going to create too large  a binding directory?
Will this be "too many" activation groups??  too few??
Should I use actgrp(*new) for the CL pgms in the above strategy and let the 
system do the reclaim, 
or will the non-LR pgms prevent the system from cleaning up??

Thanks for reading all this, your help will be appreciated...

Tony Corbett
corbett@cbt400.com 
as of 6/1/99:  corbett@asresources.com 
the industry stole my name, it now means "I'll create CD's for you"
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *