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



I think the most common scenario faced in most shops that have evolved over
many years of development is to have a majority of programs that were
converted from RPGIII, with very little change, into OPM RPGIV and running
in the *dftactgrp.  Now, new programs are being written in ILE and many (or
most) of them are called by these older OPM programs which have not been
changed to ILE.  So the question is how these called "new" ILE programs
should set their activation group.

If we use *CALLER, they get stuck into the OPM calling program's activation
group, *dftactgrp. While this will work ok, as Jon keep reminding us and as
I have found on occasion, strange things can result from OPM's calling ILE.
Especially, if the ILE calls another OPM, etc.

*CALLER is great when you know you are being called by a driver program that
used *NEW or some other name, but you don't always know who the caller is
going to be.

*NEW is ok programs that are not called repeatedly, and are especially good
for driver programs, because they create a clear boundary between OPM and
ILE.  Just be aware of the overhead if it is called too often (i.e. don't
use it for a trigger program).

QILE is a safe bet, almost no matter what, since you will always be running
in a true named activation group and it will not have the overhead of being
rebuilt every time another program starts up because all the QILE programs
in that job stream will run in the same activation group.  You may have to
clean up if the original program was called interactively, but this is still
a safe alternative if you don't really know who will be calling your
program.

So I would categorize the scenarios as:

1.)  A tightly controlled run-time environment where a driver can be *NEW
and everything else *CALLER, or
2.) An unknown run-time environment where QILE (or any other name you want
to give it) is the safest way to run.


> -----Original Message-----
> From: Buck Calabro [SMTP:Buck.Calabro@commsoft.net]
> Sent: Tuesday, March 05, 2002 8:59 AM
> To:   rpg400-l@midrange.com
> Subject:      RE: Activation groups for beginners
>
> >Buck, you left off one very important option for
> >AG: *NEW.  While you might be concerned about
> >overhead with AG *NEW, there is one very
> >solid, powerful use for it, which has to do
> >with programs that do not turn on *INLR.
>
> I very deliberately left it out, specifically to narrow the focus.  The
> point of this thread is:
>
> Multiple NAGs (including *NEW) are for complex environments.
> Complex environments include:
>   Shared ODP
>   RETURN with LR off
>
> I want people to get comfortable with how AGs factor into this simple
> environment before introducing the more sophisticated uses.
>
> That's what I mean by "baby steps."  I think that there are an
> overwhelming
> number of iSeries installs that fit the limited criteria, so I decided to
> start there.  And even if I'm wrong (imagine that!) starting from the
> simplest model has to be good for something.
>
> Once we exhaust the feedback on the simple scenario we can move ahead.
> What
> do you think?
>   --buck
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message.
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer.
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.