|
|||||||
|
|
![]() |
|
|
|
|
||
|
ILE Strategies Hey, David: I finally have the opportunity to spend some time using ILE. I have converted quite a few programs to RPG IV but have always used the Create Bound RPG Program (CRTBNDRPG) command. I have a few subprograms I would like to convert to procedures, but I am not sure how I should set the activation group or groups. This has to be well-traveled territory, but I can't find a simple explanation of activation group strategies. --Tom I am glad to hear that you have decided to take the plunge into ILE. There are a lot of ways to set up activation groups, but simple is generally best. In your case, with a few programs that you are converting to subprocedures, you should definitely stick to simple. I use several rules when either setting up new applications or converting existing applications to ILE. These rules cover simple and complex ILE environments. Here is a summary of those rules. The first rule is that every module is used in no more than one program or service program, with two exceptions. The exceptions are initial sign-on programs and possibly error processing and cleanup programs. Referring to modules in a single program or service program reduces the number of objects you have to deal with and minimizes the impact of change. Service programs 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. The third rule is that service programs do not contain both statically and dynamically called procedures. Dynamically called procedures are rarely used, but when they are it is a good idea to place them in a separate service program. Service programs with statically called procedures have binding source. The fourth rule is that every initial program has an activation group. This allows programmers to test programs that specify *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 parameters supplied. The fifth rule is that all programs and service programs--except the menu interface program, the initial program, the command processor, exit programs, and vendor interface programs--specify *CALLER. All command processor programs specify *NEW. Triggers, if used, are a special case. Ideally, you can duplicate your trigger program in the TEST and PRODUCTION libraries with corresponding activation group names. Vendor-supplied programs are another special case. For vendor programs that call ILE environment programs, we supply an interface in both our test and our production libraries that set the activation group as described for triggers. This has been easy to set up and has proven to be flexible and safe. The weakest link is that files open can only be scoped to the activation group. --David
|
Editors
Contact the Editors |
| Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved. |