Natural Storage Management

#### Search Results

Search

# Natural Storage Management

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:

- Thread and Non-Thread Environments

- Buffer Types

- Fixed Buffers

- Variable Buffers

- Customization of Buffer Characteristics

## Thread and Non-Thread Environments

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.

## Buffer Types

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`.

## Fixed Buffers

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.

## Variable Buffers

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`.

## Customization of Buffer Characteristics

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.

### On this page

- Thread and Non-Thread Environments
- Buffer Types
- Fixed Buffers
- Variable Buffers
- Customization of Buffer Characteristics