DEF_LIST - Dynamic vs Static for RDMLX components to avoid memory errors

Date:27 June 2005
Product/Release:Visual LANSA on iSeries V11
Abstract:Static DEF_LIST may cause memory errors
Submitted By:LANSA Technical Support

There are two types of working list. The first list is one that specifies *MAX for the ENTRYS parameter. This kind of list dynamically allocates memory and is referred to as a Dynamic Working List. The second specifies any other value for the ENTRYS parameter. These are static working lists.

The recommended kind of list to use in an RDMLX object is DYNAMIC as the list is only limited by the available resources.

Dynamic - Specifies *MAX for the ENTRYS parameter

A dynamic working list in an RDMLX object allocates and releases memory on demand and only pre-allocates a small amount of memory to hold pointers to the list entrys. Then, as more space is required it is allocated with one page of operating system memory or the size of one entry, which ever is the larger. On Microsoft Windows the size of a page is 32 Kbytes. Memory is also released as entrys are deleted from the list. If you were to keep adding entries indefinitely, memory would eventually run out on windows.

This is the recommended kind of list to use in an RDMLX object, though it has severe restrictions when used with the SORT_LIST command. The aggregate entry length cannot exceed 2 Giga bytes in a primary list. Also, String and Binary data memory needs are on top of this as they are not stored in the list itself. Thus each entry could have many Strings each up to 64 Kbytes long. Thus it is very easy to consume very large amounts of memory.

Static – Specifies any other value for the ENTRYS parameter

The list will contain up to the number of entries specified but which has a maximum of 2 giga entries. The aggregate entry length cannot exceed 2 Giga bytes in a primary list. Also, String and Binary data memory needs are on top of this as they are not stored in the list itself. Thus each entry could have many Strings each up to 64 Kbytes long. Thus it is very easy to consume very large amounts of memory.

WARNING – keep in mind when defining static working lists that the amount of storage allocated to each working list will be equal to the entry length multiplied by the number of entries on the list, so the amount of storage space allocated to a function using many working lists can increase quite substantially.

When a static working list will exceed typical available Windows process memory, messages 870, 871, 872, 873 and 874 may be displayed. An example of message 871 is:

"Maximum 32-bit windows server process memory of 3 GB will be exceeded."

These messages should be considered as near fatal errors. They are indicating that the memory requirement is beyond the capability of particular windows configurations. The capabilities of other platforms is generally larger, like the iSeries, but to raise these warnings still indicates a design that should be re-considered.

Message 874 contains the dimensions of the list. An example of message 874 is:

"List page size = 1098000000 bytes Entry length = 549 bytes."

Note: Whilst the iSeries has a greater total amount of memory available it is limited to a maximum of 16MB in any single memory allocation. This means that on iSeries each STATIC working list is limited to a TOTAL size of 16MB and each DYNAMIC working lists is limited to a maximum ENTRY width of 16MB. Thus a dynamic working list has a far greater total capacity - only limited by the total amount of memory that the operating system has available for the process to use. This is strictly just an iSeries limitation. All other platforms have the same limit for each list as for the total memory used by all lists.