By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The evolution of dynamic memory
For years, the C language's dynamic memory support gave C programmers the ability to, for example, dynamically (i.e., during run-time) build chains of data structures and grow and shrink arrays at will. Since V3R2, Integrated Language Environment (ILE) RPG and ILE COBOL programmers have also been able to take advantage of dynamic memory, using the ILE dynamic memory APIs. But even though these APIs are relatively simple, they are still complicated by extraneous parameters that could have been left off or left to another API.
A couple of years later, in V4R2, came the introduction of the dynamic memory operation codes in RPG. This greatly simplified using dynamic memory, as the RPG op-codes were much more intuitive than the APIs.
Finally, with V5, the implementation of the dynamic memory support in RPG has reached an apex. In addition to the fixed-format op-codes, RPG now supports two dynamic memory built-in functions, %Alloc and %Realloc, and the free-format op-code Dealloc. The relatively new built-in functions make the process of managing dynamic memory a breeze.
Understanding the three kinds of memory
On most computers, there are three common kinds of memory available for use by programs and their variables:
The main difference among these three is the way the memory is allocated, initialized, and de-allocated (or freed). It is important to remember that these different types of memory are distinguished logically, not necessarily physically; that is, while they might be located in different storage blocks, they are all kept in the main computer memory (i.e., the RAM).
These three different kinds of memory give rise to three different types of variables:
The memory for every static variable declared in your program is allocated at program initialization (a.k.a. program activation). Currently in RPG, all variables declared in the main source section are static variables (as opposed to variables declared in subprocedures -- or non-main procedures -- which are automatic variables by default). Static variables are initialized when they are allocated; character variables are initialized to blanks and numeric variables are initialized to zero (pointers are initialized to null). Static memory allocated by a program is freed automatically when the program is unloaded (e.g., when an RPG program returns with LR set on -- this is called program deactivation ).
Memory for automatic variables, sometimes referred to as stack variables, is allocated when an automatic variable comes into scope and is freed when the variable goes out of scope. An automatic variable comes into scope when the procedure in which it is declared is called (i.e., put on the call stack) and it goes out of scope when the procedure returns to its caller (i.e., taken off the call stack). In RPG, variables declared in subprocedures are automatic variables by default, but can be declared as static if you use the static keyword on the associated D-spec.
The memory for a dynamic variable is allocated and freed manually by your program. For example, if your program needs memory for an array of 100 elements, each two characters long, it would request 200 bytes of dynamic memory. Later, if the program needs to expand the array to 200 elements, it can request that the original 200-byte allocation be increased to 400 bytes.
Memory for dynamic variables is allocated off an internal memory structure called the heap. The heap is simply a chunk of memory that the system allocates for an activation group when the activation group is created. Any program in the activation group can request storage off that activation group's heap (in a coming installment, we'll discuss 10 important things to remember about heaps).
We'll discuss RPG's dynamic memory management built-in functions -- and see them in action -- in the next installment.
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.