|
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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.