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

First, I would recommend using Service Programs instead of Modules.  (Maybe
that's what you meant, but you said modules)

Second, I would recommend NEVER EVER using CRTSRVPGM with EXPORT(*ALL).
Create Binder Language for the service programs and specify the binder
language on the CRTBNDxxx command.

Third, use /COPY for prototype definitions.  This will save tons of time and
coding.

Putting all service programs in one binding directory won't hurt.  It's just
a reference for the CRTBNDxxx command to look through for service programs
being used by the program you are compiling.  Similar to the way a library
list works when the program is looking for files in use in the program.

As far as AG names, that's a tough one.  I create all my front end CLLE
programs with named AGs, then always specify *CALLER on the RPG program.
(clears most headaches with data paths, etc.).  As far as another CL that
calls the CL, and then does a RCLACTGRP *ELIGIBLE, I wouldn't worry about
that.  This really defeats the one of the purposes of using AGs.  If you
have to recreate the AG each time a program is called, there goes your
application speed that you were hoping to achieve using named AGs.  

The only problem I have run across when using named AGs is this...

1.  I have a service program that returns static info from master files, for
example:  #CstName() returns the customer name of the customer number
supplied.
2.  This subprocedure is called in a job with DATALIB1 as the data library
containing the Customer file.
3.  I change my data library to DATALIB2.  
4.  When I call #CstName() again, it still is using the file from DATALIB1.


I do suggest using named AGs when using Service Programs.  I ran into a
couple hairy situations using the DAG and service programs.  They're long
forgotten, though, since I've used Named AGs (I think they were nasty
MCHxxxx errors).  I would suggest at the very least to use QILE as the AG
for everything.  You can always split them up later.

You just have to remember that AGs are a subset of a job.  So, having your
customer service program run in CUSTAG activation group will only speed up
subequent calls to programs for that job only.  "Bob" and "Mary" will not
share AGs.  They will each create AGs for their own job when needed.  So if
Bob already called PGM1 that runs in CUSTAG, Mary's job, when she calls
PGM1, will have to create the CUSTAG as well.  

Whew....

Bradley V. Stone
Taylor Corporation - OASIS Programmer/Analyst   
bvstone@taylorcorp.com


> -----Original Message-----
> From: Tony Corbett [SMTP:corbett@CBT400.COM]
> Sent: Thursday, April 15, 1999 6:17 PM
> To:   'RPG400-L@midrange.com'
> Subject:      ILE activation group strategy...I need help/advice
> 
> 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          *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *