This document describes how Natural allocates and uses main storage. A chunk of storage requested by a Natural nucleus component is called a "buffer".
This section covers the following topics:
There are two different types of storage environments:
Thread storage environment (typical for multi-user environments, for example, CICS)
Non-thread storage environment (typical for single-user environments, for example, batch)
In a thread environment, a big piece of storage called "thread" is pre-allocated for a session. The thread size must be predefined by the system administrator. During a session each buffer allocation request (GETMAIN) is satisfied within its thread by Natural itself. Free space due to release buffer requests (FREEMAIN) can be reused.
Upon certain events (terminal I/Os and long waits), the thread storage may be compressed and rolled out to external storage (roll file). The released thread can be reused by other Natural sessions. When a suspended session is to be resumed, it is rolled in from external storage into a free thread again.
The place on the roll file where the compressed thread storage is stored, is called a "slot". The slot size has a fixed length and is defined by the system administrator. It must be large enough to contain the largest compressed thread storage. In the worst case, it may be equal to the thread size.
In a non-thread environment, all storage requests are directly passed to the operating (sub)system. No roll-out/roll-in is performed, that is, the buffers for a session are kept until session termination, unless they were explicitly released before.
There are three different types of buffers:
fixed buffers
variable buffers
physical buffers
Fixed buffers and variable buffers have a 32-byte
prefix with a common layout for all environments. The buffer prefix starts with
the buffer name followed by 5 buffer length fields (total, used low-end, max.
used, used high-end, max. used high-end). The used length fields are maintained
by the buffer-owning components and are used for thread compression. Each
buffer has a unique ID number (1-255) and can exist only once. Some buffers are
allocated during session initialization, others are allocated when required.
The system command BUS can be used
to show information about all fixed and variable buffers currently allocated.
The characteristics of the buffers are defined in the source module
NATCONFG, which can be
customized in exceptional cases (see
Customization of
Buffer Characteristics below). The size of some buffers
can be specified by a profile parameter. For a complete list of such buffers,
see the profile parameter DS.
Physical buffers are allocated outside the thread. They do
not have a buffer prefix and they are not unique. They are used in exceptional
cases and temporarily only. Physical buffers are automatically released at the
next terminal I/O. It is possible to define work pools for physical buffers by
profile parameter WPSIZE.
In a thread environment, fixed buffers are allocated from the low end of the thread only. In contrast to variable buffers, fixed buffers cannot be moved relatively to the thread and their size cannot be increased or decreased.
In a thread environment, variable buffers are allocated from the high end of the thread. If there is no more space in the thread, variable buffers are allocated temporarily outside of the thread. Upon thread compression, all buffer parts used are compressed into the thread. If they do not fit into the thread, the session is terminated abnormally. This may happen especially when large dynamic variables are used.
After thread decompression, the variable buffers may have been moved to a different place inside or outside of the thread. Variable buffers can be increased or decreased in size on request by the owning component. Some variable buffers are defined to be reduced or released automatically during thread compression.
The total amount of storage allocated outside the thread can be
limited by profile parameter OVSIZE.
All buffers are defined in the source module
NATCONFG by
NTBUFID macro definitions.
 |
Warning: Please, do not change any buffer characteristics except the MIN, MAX and
CMPR parameter settings explained below, because the
results may be unpredictable. |
It is possible to change the buffer size limits by the parameters
MIN and MAX of the macro
NTBUFID. This makes sense for variable buffers
(TYPE=VAR) only. Limits
for all buffers are defined either by default (0 - 2097151 KB) or
by the limits of the corresponding profile parameters. For further information,
see the profile parameter DS. The limits of the
buffer size profile parameters in the Natural parameter module are not affected
by the MIN and MAX parameters of
NTBUFID, but the limits for the dynamic profile buffer
size parameters are overwritten by MIN and
MAX.
Setting the MAX parameter to a value in KB
means that the size of this buffer cannot exceed this maximum during session
execution. This may cause runtime errors if more buffer storage is requested
for the desired buffer.
Setting the MIN parameter to a value in KB
means that the size of this buffer cannot be less than this value during
session execution. For example, in the case of the 3GL CALLNAT interface
(NAT3GCAN), the setting of a buffer minimum value makes sense for
the following buffers, because the sizes of these buffers may not be increased
on a lower Natural program level called by a 3GL program.
| Buffer | Purpose |
|---|---|
DATSIZE |
Data areas |
GLBTOOL |
Utility GDA |
GLBUSER |
User GDA |
GLBSYS |
System GDA |
AIVDAT |
AIV area |
CONTEXT |
Context variables |
The parameter CMPR of the macro
NTBUFID defines the compression optimization algorithm for the
buffer. It corresponds to the profile parameter CMPR
which defines the default. For more information about the possible parameter
values, see CMPR – General Default
Compression Optimization Algorithm in the
Parameter Reference documentation.
Example of a buffer characteristics definition:
DATSIZE NTBUFID ID=GETMDATA,TYPE=VAR+INI,CMPR=OPT2,MAX=512
For further information on profile parameters affecting the buffer sizes, see Storage Management in the Parameter Reference documentation.