Re: Private storage, static storage, bound modules and service programs

Static storage is always scoped to activation group.
If program is ACTGRP(*NEW), this is a kind of "program level" - because a 
new AG is created for each program invocation.
If activation group is unique for a job (default or named), it's a kind of 
"job" level.
Passing pointers from procedure in one AG to a procedure in another AG is 
not a very good idea, because activation groups can end or be reclaimed 
independently of each other, which will cause addressing exceptions.
Automatic storage is allocated in stack. Each thread has its own program 
stack.
Pointer to a value in automatic storage is only valid while procedure 
invocation is in stack.
Using such pointer will more likely cause garbage data, because stack 
itself is always there (unless thread terminates).
Heap storage is scoped to AG, so it has similar issues as the static 
storage.
Hope this helps.

    Alexei Pytel
always speaking for myself

Where is the beginning of the end, which ends the beginning?



"Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/22/2004 12:00 PM
Please respond to
Midrange Systems Technical Discussion


To
"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
cc

Subject
Private storage, static storage, bound modules and service programs






Okay, I've completely confused myself now.

I have values that I like to keep for an entire job, and values I like
to keep at a program level.  So, Program A calls Program B, and they
share a job level value J_SESSION, but each has its own program level
value, P_CALLLEVEL.

Typically, I have a separately bound program I call that keeps the job
level values, and I bind in a module to keep static variables at the
program level.  So, I have a program that returns J_SESSION, and both
Program A and Program B call it through an EXTPGM call.  However, each
has its own P_CALLLEVEL value, which it gets through an EXTPROC call to
a bound module.

In the world of service programs, can I emulate this?  Barring getting
into activation groups, it seems to me that the only way I can keep data
at the program level is by a module bound to that program.  It seems to
me that all calls to a service program from the same job regardless of
the opposition of the calling program in the call stack will always have
the same global variables.

As I look at this, it SEEMS as though activation groups might allow me
to do something.  If I put each program in the stack in its own
activation group and had one service program with a named activation
group and the other with an activation group of *CALLER, it seems that
the first service program's global storage would be shared among the
programs, while the second service program's variable would be unique
for each program.

That's a pretty elegant concept, although it does mean I have to have an
activation group for every level of my stack.  But in the great scheme
of things, that doesn't seem to be all bad.

Comments?

Joe

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.