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



On 3/3/2011 5:40 AM, Luis Maldonado wrote:

we have a lot of problems in our system about activation groups.
I wonder if you can help us !!!
I mean we are working with ILE RPG but always compile with DFTACTGRP(*yes). Now we begin to compile with DFTACTGRP(*NO) ACTGRP(QILE) and all the OVRDBF and OPNQRY don´t work.

Because we have some ILE RPG that use procedures we need to compile with DFTACTGRP(*NO) and QILE or *Caller.

Two questions :
1) is a good idea to compile all the programs (CLLE,RPGLE) of the system with DFTACTGRP(*NO) ACTGRP(*caller) ? Can cause some problems ?

2) Maybe, It´s better to compile all the programs with DFTACTGRP(*yes) and only the programs that have procedures with DFTACTGRP(*NO) ACTGRP(*caller) .

There is no simple, single, correct answer.

First, the behaviour you see is exactly how activation groups are
supposed to work. An activation group isolates overrides from other
activation groups. There is an exception for overrides in the default
AG - they are inherited by other AGs. When I started with ILE, I kept
my CL as OPM and compiled my RPG as dftactgrp(QILE). Today, I might use
my company name instead of QILE. When I say ILE, I specifically mean
using sub-procedures.

There is more than one right way to move to ILE. One can compile all
ILE programs and service programs into a single named activation group
like QILE, one can compile the top level programs into a named AG and
all child programs called from the top level (including service
programs) actgrp(*caller). These are two common conventions; there are
more right ways to go about it.

There is a wrong way though. Compiling your ILE programs
actgrp(*caller) and then calling them from the default activation group
will lead to problems. I strongly advise against this.

If you are completely lost, I can relate how we got started. It is one
way but there are others. We left our CL programs as OPM. We left our
RPG III programs alone - no mass conversion to RPG IV. When we need to
modify an RPG III program we convert it to RPG IV and make a decision.
If the change is simple, like making an array larger, we compile it
dftactgrp(*yes). If the change is complex, and needs a service program
or an internal sub-procedure we compile it dftactgrp(*no) actgrp(QILE).
If it uses OPNQRYF we go back to the calling CL and change OVRSCOPE.
Service programs are actgrp(*caller).

The good news is that there are several good ways to get into ILE and
only one really wrong way. Do read Scott's article; some good stuff
there. Paul Tuohy's book Re-engineering RPG Legacy Applications is a
bit old, but it has lots of examples. The IBM manual ILE Concepts is
good, but it took me more than one time through to really make use of
it. Set aside a day to read it, make a test library, type in some
examples and try things out. Use many comments; I compiled by hand;
CRTBNDRPG, F4, fill in the parameters, F14 and then copy/pasted that
into the comments. Go back to work for a day or two and then set aside
another day to re-read the ILE Concepts again, after your mind has had
time to work through it the first time. Go back to your test library
and examine your examples. When you're finished, you'll have a library
containing some things you don't want to do, and some things you do.
Don't delete anything; put a lot of comments in the code as to why this
worked and why that did not. Knowing what NOT to do is every bit as
important as knowing what to do. In the future, when someone says 'We
should compile our child programs actgrp(*caller) you'll have examples
to understand where that is a good idea and where it is not.

I hope that helps some.
--buck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.