× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 06-Apr-2012 12:11 , Nathan Andelin wrote:
From: Alan Campin
The same thing in a C program needs 270 bytes.

What happens if you code the following in main()
static int x = 0;

I haven't tried it, but my guess would be that the static
storage used by the C program would also be around 4K. If I
understand correctly, storage under IBM i is allocated in 4K
minimum blocks using system APIs. Wouldn't that be what the
compiler would do?


I do not believe that would be the case.

Being associated with the process, thus being storage outside of any "object", the size for the program static storage is not dictated by any [object] minimum page size nor any other similar dictum. Thus the static storage size used to support all of the declared static storage in a program can be exactly the number of bytes declared as static; storage that is acquired by the process dynamically [irrespective the /static/ moniker], according to the defined "static storage size" requirement of the compiled program object. The noted 270 byte static storage size for the C program storage is more likely to be accommodated in the actual run-time on a 16-byte boundary rather than a 4K boundary, thus presumably taking 272 bytes of dynamically acquired process static storage. IIRC, the output from DMPJOB PGM(named) shows the actual static storage [for a previously invoked program] fairly clearly and conspicuously.

In a later message in this thread, what I suggest below is apparently already understood; best I can infer from the comments made about "the difference between 'static' and 'heap' storage".
http://archive.midrange.com/rpg400-l/201204/msg00092.html

However "heap" storage might just as well have been called "memory", because the means to acquire dynamic storage that is not directly associated with the implementation of the process, need not be limited to acquisition from the heap. Much of the DB2 for example, had long relied [presumably still] on non-heap miscellaneous temporary storage [spaces]. For the process, the two types of [OPM] storage are "Automatic storage size" and "Static storage size"; i.e. "program automatic storage area" PASA and "program static storage area" PSSA, both of which are allocated within the process.

The compiler would prepare the object for any amount of storage that is required to accomplish what the program needs to do at run-time, according to what is necessary to accommodate all of the [referenced] variable declarations made by the program. However because the compiled objects do not physically "contain" the storage that will be used for the static variables, the compiler effectively does little more than store a number, the "Static storage size" [per DSPPGM], in order that the LIC\AI "Activation Invocation" feature knows how much [the actual /size/ of the] storage must be acquired within the "process storage" when the program is invoked.

The [process] Static storage, much like the [process] automatic storage, is process storage that is allocated dynamically within the process, effectively for [associated with] the stack frames. The difference between them is effectively that program static storage is allocated and initialized only on the first invocation of the program within a process\job, whereas the automatic storage is allocated and [optionally] initialized on every invocation of the program within each thread of a process.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.