Re: ILE questions: activation groups, rpg-cgi, classic web server.

On 28 Feb 2002 at 14:20, Jon Paris wrote:

>  > If you use the default activation group, static binding and binding
> directories are not supported.  This also means CALLB and CALLP aren't
> supported,
>
> There are two problems with this statement.  First, if you specify the
> DFTACTGRP *YES _compiler_ directive they are not supported.  (Darn it I wish
> that compiler option had a more meaningful name like CRTFAKEOPMPGM (Create
> Fake OPM Program) or something 'cos that is effectively what it does.)
> While it is not a good idea, there is nothing to prevent an ILE program from
> running in the default AG.  Second point - CALLP means "Call with Prototype"
> and is perfectly acceptable in a DFTACTGRP(*YES) program as long as the
> proto references a program (EXTPGM keyword).
>

Well, I should have been more specific.  I meant the DFTACTGRP compiler 
directive

I understand your words, and I've never tried it, but in "The Modern RPG IV
Language", second edition, MCPRess 2000, the venerable Robert Cozzi, Jr. says
(on pp. 486):

"ILE static binding is not available when a program is created with
DFTACTGRP(*YES).  This means the CALLB and CALLP operations are not
supported."

Which is why I've never tried it.  This would seem to contradict what you say.  
Can
you help me understand what I'm missing?  Are you saying that CALLP will work if
EXTPGM is specifed and DFTACTGRP(*YES) is used as a compiler directive, and
only in that circumstance?  Is it still true, then that CALLB wouldn't work in 
any
circumstance if DFTACTGRP(*YES) is specified?

>  > You can also use *CALLER to use the caller's activation group, but if the
> caller's activation group is the default activation group, static binding,
> callp, callb, etc. won't work.
>
> This is just not true as I mentioned above.  It is not the recommended
> approach but it works just fine.
>

Same book, pp. 487:

"*CALLER  Specify *CALLER to cause the program to run in the same activation
group as the program that evoked it.  *CALLER should not be used when the 
caller's
activation group is the default activation group"

Mr. Cozzi doesn't elaborate any more than that as to why *CALLER is bad, but I
would take his words to mean that if the evoking program is OPM, or an ILE 
program
compiled with DFTACTGRP(*YES), then statically bound procedures would not be
supported when used by an ILE program compiled with *CALLER that is evoked by
said program.

If I can say that ten times real fast, will you give me ten dollars? <g>

I know I'm not an expert on the subject, and I don't understand fully how that
relationship works.  It seems to me that the activation group provides some of 
the
support for these features, and if you don't use the right activation group 
then the
features aren't supported.  I guess I don't understand what the activation group
provides (or doesn't) to the binding process.  An explanation would be 
appreciated.

> As to the use of *NEW vs. a named AG.  I tend to think of *NEW as being
> useful for the menu level.  When the operator finishes with the function in
> question and backs out of the menu, the resources get cleared up.  Even then
> if they are going to reuse that same functional area again later in the day
> I would go for a named AG and do my own clean-up.
>

This is the part of the subject that is nebulous for me, but I'm working my way
through the previous discussion thread about "I Hate Activation Groups" and I 
think
the light is beginning to shine, although I may have to come back to the list 
for help
on a thing or three.  *NEW goes away when the program returns, right?  So it
provides the needed environment, then dies?  Named hangs out and can be used to
support other processes that want to use it? Or just use similar bindings?

Damn, I'm confusing myself again.

I hate activation groups.

--Chris