MEMORY=<workmem size>{,sbxmem size{,cachelimit}}
Examples: MEMORY=700K
MEMORY=700K,200K
MEMORY=2M,400K,500K
MEMORY configures certain memory allocation sizes used by each A-Shell user.
The first number specifies the size of the ASB work area. If no MEMORY statement is specified, the default work area size is 512K. This work area is used for a variety of purposes, including variable storage, the CALL/RETURN stack, allocation of dynamic arrays, string stack, and if sufficient in size, for sorting files, and compiling, and editing programs.
The ASB mem() function displays the amount of free memory available in the main work area. Note, however, the program itself—and any modules loaded by the LOAD command—is stored in dynamically allocated memory outside of the ASB work area.
The second parameter specifies the amount of memory to be provided for any SBX subroutine call. If not specified, the default is 384K. In either case, if the main work area has sufficient free space at the time the subroutine is executed, then that will be used instead. (So if you call a lot of SBX routines, it might be more efficient to make your main work area large enough to accommodate the needs of your largest SBX.)
The last parameter specifies the maximum amount of memory to be set aside for caching of SBX subroutines and other modules that are automatically loaded on demand. The default is 200K. Such modules are kept in memory for a period of about 10 minutes after their last access, or until the specified limit is exceeded. At that point, modules are discarded on a LRU (least recently used) basis.
Notes
A number of A-Shell operations that require additional memory, such as BASORT, COMPIL.LIT, and VUE.LIT, may take the liberty of allocating it outside of the ASB work area. See the MALLOCLIMIT directive for details on limiting those allocations.
The minimum practical amount of memory to execute many of the system commands is about 350K.
You can also specify the memory size on the A-Shell command line.
History
2016 July, A-Shell 6.3.1518: Memory enhancement: Move the string expression stack out of the main partition into a separate module which now auto-expands as needed. This should eliminate the most common and yet most unpredictable cause of out-of-memory (or stack-overflow) errors, which are related to operations on strings whose size is not obvious or easily predictable.
The main partition (specified by the first and/or second values in the MEMORY statement) is now used mainly for mapped variable storage, call stack, and command files. The actual RUN files are loaded separately. SYSTAT/M shows the minimum available memory in the partition since the beginning of the session, allowing you to perhaps gauge how much larger-than-necessary your partition allocation is.
