× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



At V6R1 and above, you can use the DCLPRCOPT command to specify these things directly in the CLLE source.

If you are on V5R4 (or earlier), use Alan Campin's COMPILE tool, available at http://www.think400.dk

> On 2/5/2013 5:46 PM, Gqcy wrote:
I agree with having one named activation group.

If we would place "ACTGRP(xyzcompany)" in our default H spec,
wouldn't that cause problems at the CLLE level?

Wouldn't we need to also change the command defaults for CRTBNDCL as well?


On 2/5/2013 3:57 PM, Buck Calabro wrote:
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
a program.

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
DFTACTGRP(*NO) ACTGRP('MYCOMPANY').

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.
--buck


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.