RE: Service Programs in Named Activation Groups

[Alan Campin <Alan.Campin@xxxxxxxxxxxxx>]

Does your example assume a call from within the same job? I assume it does.
I only get into using dynamic storage when I may have something that might
be called from multiple programs within the same job and I need to keep
everything separate for each caller.

Great thread. There are some heavy issues in writing reusable code but that
is beauty of ILE, you hide all that complexity and the consumer of the
function never needs to know what is going on in the function but you have
to think all that out. That's why it bothers me that all over the country,
we are reinventing, in various forms, the functions in service programs.
Writing a good service program is not trivial. 

-----Original Message-----
From: pytel@us.ibm.com [mailto:pytel@us.ibm.com]
Sent: Wednesday, November 24, 1999 2:59 PM
To: RPG400-L@midrange.com
Subject: RE: Service Programs in Named Activation Groups


Your example just illustrates my point.
You static storage variable value is retained from call to call by virtue
of named activation group. If it were *NEW activation group, static
variables will be refreshed every time and you will not be able to pass
iformation from call to call.

But there is subtle difference between *CALLER and named activation group.
Let me show an example.

Named activation group:
a) Procedure S lives in service program with activation group QSRVPGM.
It has static variable V with initial value 0.
b) Program A runs in activation group G1 and calls S.
c) S sees V to have value 0 and increments V to 1 - because this is the
first call of S in its own activation group QSRVPGM.
d) Program B runs in activation group G2 and calls S.
e) S sees V to have value 1 and increments it to 2 - because this is the
second call of S in its own activation group QSRVPGM.
In this case A and B are not isolated.

Activation group *CALLER:
a) Procedure S lives in service program with activation group *CALLER.
It has static variable V with initial value 0.
b) Program A runs in activation group G1 and calls S.
c) S sees V to have value 0 and increments V to 1 - because this is the
first call of S in activation group G1.
d) Program B runs in activation group G2 and calls S.
e) S sees V to have value 0 and increments it to 1 - because this is the
first call of S in activation group G2.
In this case A and B are isolated.

Hope this helps.

Best regards
    Alexei Pytel


Alan Campin <Alan.Campin@CaseLogic.com> on 11/24/99 03:24:47 PM

Please respond to RPG400-L@midrange.com

To:   "'RPG400-L@midrange.com'" <RPG400-L@midrange.com>
cc:
Subject:  RE: Service Programs in Named Activation Groups




>> Static storage is scoped to activation group, so if programs from
different
>> activation groups are calling modules in a service program, running in a
>> named activation group, they should expect to see changes to static
>> variables, made in previous calls, even coming from unrelated activation
>> groups.

Alexei, what does this mean exactly. Can up supply an example. I make call
into service programs running in a named activiation group QSRVPGM and I
have never seen a static storage variable change between calls. If it did,
I
would have all kinds of service programs that would not work.

What I do quite often is to build the program smart enough to handle
multiple calls from different users into the same service program at the
same time. I do this by allocating all my data structures with heap storage
and then keeping a table in static storage with nothing but an integer
number and a pointer to the data structure for that user. The user passes
me
the integer number they got from an earlier call to an initialization
function and I use that number to lookup the pointer to that users storage.

In other words, dynamic memory management but, if what you are saying is
true, this would never work. The static storage wouldn't be there from
before or would have been changed.

Am I missing something?

Thanks

Alan Campin
alan.campin@caselogic.com

-----Original Message-----
From: pytel@us.ibm.com [mailto:pytel@us.ibm.com]
Sent: Wednesday, November 24, 1999 1:19 PM
To: RPG400-L@midrange.com
Subject: Re: Service Programs in Named Activation Groups



Static storage is scoped to activation group, so if programs from different
activation groups are calling modules in a service program, running in a
named activation group, they should expect to see changes to static
variables, made in previous calls, even coming from unrelated activation
groups.

Automatic (local) storage is allocated in stack and is not affected by
activation group.

Heap storage is also scoped to activation group, so all dynamic allocations
made from service program modules will go to the same heap (which will be
freed when this activation group ends).
This may lead to orphan pointers in other activation groups.

Basically, there is no problem in using named activation group for service
program if you understand what you are doing.


Best regards
    Alexei Pytel



+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---



+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---