Solid advice, good strategy Buck. We need a few programs to be launched in a *NEW activation group as opposed to *CALLER or NAMED, but that's just a nit.
----- Original Message -----
From: Buck Calabro <kc2hiz@xxxxxxxxx>
Sent: Tuesday, February 5, 2013 2:57 PM
Subject: Starting to use ILE. Was: How to best identify if applications are running in OPM mode?
On 2/5/2013 4:17 PM, Gerald Kern wrote:
Thanks for the input Mark - your last sentence about mixing ILE & OPM was
the reason I started down this path.
And yes I have Scott's ILE Concepts presentation and have given the staff a
copy of it to.I'm asking them to refresh their minds on this stuff,
especially as we move to modernizing more of our applications.
In my opinion, the easiest way to get going with ILE is to start with
the programs. Don't worry about service programs just yet. Get used to
prototyping and consuming user-written functions (sub-procedures) inside
With that in mind, almost no one needs more than one activation group.
Those who disagree with this advice should keep in mind that it is
advice for ILE beginners. When one is more experienced, one understands
when that simplistic model needs augmentation. :-) My advice is to
create a standard RPG H-spec and compile all of your programs with
If you're already in a mixed shop, don't worry too much about it. The
most common problem is MCH3601. If you get that, you know you should
recompile the caller and the service program into their respective
activation groups. And my advice for service programs is the same as
for programs. Use ACTGRP('MYCOMPANY').
With respect to binder language, I adhere to a similar philosophy. I
used to like the *PRV signature functionality but now it seems like
something only a Very Large Shop would use. I use a single *CURRENT
signature block and add my new exports to the end. STRPGMEXP
PGMLVL(*CURRENT) SIGNATURE('MYCOMPANY') It's exactly what we've been
doing for 20 years with physical files so it's not like I'm trying to
develop a new, unusual habit.
With respect to service programs, I have one and only one source member
per service program. That source member lives in QRPGLESRC for RPG and
has the same name as the service program. I have a /COPY source file
called QPROTOSRC (an idea I shamelessly stole from David Morris many
moons ago) and the source member has the same name as the service program.
I have a handful (less than 5) service programs. Frankly there aren't
that many functions that we use in more than one place yet. I've
divvied them up by functional area. So A/P goes in APSRV, P/R goes in
PRSRV and so on. Each service program is listed in a single binding
directory (which goes in my standard H-spec).
There is some additional work needed to create a service program, but
it's not a lot. For a program to soncume one of those functions is as
simple as /COPY PRSRV, eval FICA = getFICA(employee#); and compile with
PDM option 14.
ILE /can/ be complicated but it can also be very simple to use.
1) One activation group
2) One standard H-spec
3) Service program, binder source, /copy and RPG source members all have
the same name
4) One binder language signature block
5) One binding directory
Hope this helps assuage some worry.