RE: Eliminating *MODULES with IMPORT and EXPORT parms and replacing them with Service Programs

Jerry,

Your strategy for dealing with ACTGRP naming depends a bit on your environment. Here, our menu software uses group jobs to launch new menu selections, forcing the activation groups to automatically reclaim when the user exits the program option. For us, we could get away with simply using one activation group name for EVERYTHING. Normally, I think the downside of this relates to job storage and file resources. Unless you RCLACTGRP consistently, you might not be releasing resources as you might want.

If you are not using some similar job management facility, you might need to consider using (at least) TWO H-spec copybooks. One for service programs, and one for everything else. The service program would use ACTGRP(*CALLER), the other might be ACTGRP(*NEW). This might not be the absolute best solution in terms of performance, but it would be fairly robust in terms of automatically reclaiming AG resources. (Honestly, I'm not sure about having a copy book for H specs. I just code it for each program, so that I am sure I understand how *THIS* program that I am developing is supposed to manage AG resources.)

Also note that overrides can be a real pain if you try to use ACTGRP(*NEW), depending on your OVRSCOPE() usage on the override command. This is especially troublesome if you use a LOT of CLP (not CLLE) for job control, that call ILE programs.

I hesitate to make any specific suggestions, because I could be wasting your time with these...

-Eric DeLong

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of GKern@xxxxxxxxxxxxxxxx
Sent: Wednesday, April 13, 2011 12:42 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Eliminating *MODULES with IMPORT and EXPORT parms and replacing them with Service Programs

Hi Eric,

See inline comments:

"Do you make use of Binding Directories to help you build your ILE
programs? If you do, I suspect that currently your binding directory
references *MODULE objects, no *SRVPGM objects... If you don't use
binding directories (meaning that you specify all the modules in your
compile command), you should look at them immediately."

--Yes - we use one 'master' binding directory and all but two entries are
for *module (we have 2 *SRVPGM entries).

"If you ARE using binding directories, to convert from Bind-by-Copy to
Bind-by-Reference, all you need to do is create service programs from your
modules, then remove the *module entry from your binding directory and add
it as *srvpgm. Any programs that use your binding directory will then
change to bind-by-reference the next time they are compiled. Make sure to
use the H specs to tell the compiler to use your ACTGRP and BNDDIR values
specified in your source."

-- Yep - that is what I would like to do - remove the *MODULE entry and
replace it with *SRVPGM in the binding directory.

We have an H spec copybook with the following:

H Option(*NODEBUGIO : *SRCSTMT)
H BNDDIR('MASTER') BNDDIR('QC2LE')
H DFTACTGRP(*NO)
H ACTGRP(*CALLER)

The one area that I have concerns with here is the ACTGRP(*CALLER) entry
in the H spec copybook. My concern lies in that we may have some OPM
programs that would result in running the the default AG. My thought is
when compiling service programs we should use the service program name for
the activation group parameter on the CRTSRVPGM. (That was a suggestion
from another thread awhile back here on RPG-L).

"The mechanics of this are really easy to accomplish. You *could* do this
bind method change today, leaving everything else just as it is
(import/export fields, no parms, etc.) and reduce the size of your
programs, if that's your primary goal... However, I would hope that
defining real PR/PI (parameter definitions) and making use of local
variables (to reduce the use of module scoped "global" data) is on your
hit list as well. Where the binding method is easy to change, fixing your
architecture is a much bigger job."

-- Reducing program size is one goal, (not the primary one but is
beneficial), using real PI/PR to as you say reduce the use of 'module
scoped global data' is IMO a bigger goal (as well as introducing these
concepts to the staff). Yes the binding method is the easy part - and
fixing our architecture is indeed a big job, but I feel that these baby
steps will get us moving in the right direction.


Thanks, Jerry

Gerald Kern - Information Technology
Programming Supervisor
IBM Certified RPG IV Developer
Lotus Notes/Domino 8.0.1 Administrator
The Toledo Clinic, Inc.
4235 Secor Road
Toledo, OH 43623
Phone 419-479-5535
gkern@xxxxxxxxxxxxxxxx