Re: Service Programs in Named Activation Groups

["David Morris" <dmorris@xxxxxxxxxxxxx>]

m,

You may be over complicating this.  Usually it is just fine to run service 
programs 
in the caller's activation group.  If you are storing state variables for 
multiple 
client programs in your service program, you can allocate the storage for the 
state variables in the calling client and pass them to the service program as 
parameters.

If you want to allocate and store information for client programs in your 
service 
program, you can assign a handle (a unique key, like a serially assigned 
integer) 
which is returned to the client.  This handle can then be passed by the client 
to 
the service program.  The handle can then be used in the service program to 
retrieve client state variables which may be records, heap storage, global 
variables, etc.

David Morris


>>> mdrazic@ORIENTAL.COM 11/24/99 10:39AM >>>


The AS/400 ILE Concepts manual indicates on page 5.1 that Multiple Applications
running in the same job must provide some sort of mechanism for managing storage
for each client calling a Service Program in a Named Activation Group.
Furthermore, the same manual on page 5.3, states that "You must, however, manage
the state information for multiple clients" for the same scenerio.  There is NO
further information in any of the IBM manuals or redbooks on how this
might/should be accomplished.

For a Service Program running in Named Activation Group:

Must you provide storage management for each client attached to the Service
Program?

If so, is it only Static storage involving global declarations?  Is
local/automatic storage used by the subprocedures effected?

If so, does the Service Program need to manage the "HEAP" to create individual
storage for each client?
What issues would be created by this technique, especially since multiple
clients would be accessing the same "HEAP".
Are there any ILE RPG examples or recommendations about how this might be done?


+---
| 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
+---