RE: Static, Automatic and Heap Storage

[Alan Campin <Alan.Campin@xxxxxxxxxxxxx>]

>> for example, if sflsiz=sflpag the subfile fields are all kept in
static(?) storage, whereas >> for extending subfiles automatic(?) storage
will be used. 

Talking about subfile storage is completly different from storage in memory.
How IBM implements the storage for the subfile I do not know. 

The term static storage means that the storage is allocated at the start of
a program or module. The term global variables means the same thing. If you
writing in RPG III or using global variables(D specs defined at top of
program or module before any subprocedure or any file storage), you are
creating static storage. The storage exists until the program or module is
terminated. It gets a little more complex with ILE because the static
storage is, also, scoped (or divided between) activation groups. This just
means the operating system protects the storage between the two activation
groups. If you are walking a pointer through memory in a program and the
pointer ends up pointing out of storage for your activation group, the
system stops you with a hard halt. In effect, a Chinese wall. 

Automatic storage is different. Automatic storage only exists inside of a
sub-procedure and only for the life of the sub-procedure. When you call that
function, any storage, i.e. variables, required are allocated from the
system heap, used during the function and then discarded unless you
specifically define them as static. If you do, then the values for kept
between calls(Something you don't want to do unless you have to).

This reason this all important is that languages like ILE RPG (C type
languages) are very efficient at managing automatic storage and very
inefficient at managing static storage. The best possible ILE RPG or C
program would have zero static storage and all automatic storage. This is,
of course, usually unattainable and if using files in ILE RPG programs,
completely unavailable. 
 
>> Is heap storage only applicable where you are using the alloc and dealloc
>> commands and doing things with pointers ? How does it differ from the
>> automatic storage as described above ?

Automatic storage is allocated from the heap. It just done automatically by
the runtime. You have no control over it. Alloc and Dealloc allows you
control over storage and how much and yes it always is based on using
pointers. 

You use Alloc and Dealloc when you don't know how much storage you are going
to need at runtime. For example, someone passes me a variable length string
and I need to put a null on the end before passing it to a "C" function. I
don't know how long it will be so I just get the actual length and add one
to it for the null character and do an Alloc to create that much storage.
The storage is then just like any other storage except that I need to
release it when I get done.

Alloc can be tricky. You need to understand how it works and be very careful
about releasing it when you done or you can create some nasty problems but
for many classes of programs, there is simply no other way to do it except
with dynamic storage (Alloc and Dealloc). 
 
>> Is it possible to share one area of storage between
>> different activation groups ?  (Intentionally ! <g>)

Only way to I know of is to use a User Space. Getting a pointer to the user
space would map all programs to the same storage but this is real tricky, if
two or more programs can be updating at the same time. Have to have some
form of locking and then prevent deadlock. "C" has all kinds of functions to
try to deal with this problem.

I believe you can, also, return a pointer to a caller pointing to the
storage in another activation group but I try to avoid this. Someone could
potentially use that pointer to walk all over the storage in your activation
group. I always try to return a Handle which is just an integer number. The
Integer number just points to some dynamic storage in my function that
actually contains the pointer. That way, no one has access to my storage
except through defined functions. 

-----Original Message-----
From: watern@cbs.fiserv.com [mailto:watern@cbs.fiserv.com]
Sent: Thursday, November 25, 1999 2:00 AM
To: RPG400-L@midrange.com
Subject: Static, Automatic and Heap Storage




Hi all,

The discussion about service programs has left me getting a bit confused
about the different types of storage.

I thought that one of the differences between static and automatic storage
is that one of them (static ?) contains data which has the same storage
requirements for every call of the program - for example if sflsiz=sflpag
the subfile fields are all kept in static(?) storage, whereas for extending
subfiles automatic(?) storage will be used.  Am I understanding this
correctly ? Is one of the types of storage actually linked to the program
object itself in some way ?

Is heap storage only applicable where you are using the alloc and dealloc
commands and doing things with pointers ? How does it differ from the
automatic storage as described above ?

Does the term "scoped to activation group" mean shared within one
activation group ?  Is it possible to share one area of storage between
different activation groups ?  (Intentionally ! <g>)

- thinking about the last point, I imagine by using pointers you would
achieve this ?  I guess even passing parameters has the same end result
that storage is shared, whether activation groups are the same or
different.

Thanks In Advance for answers.

Nigel.


    Alexei Pytel wrote...
>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.



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