Global Data Management

Memory Management Concepts

Because almost all EUS Toolkit programs are CALLed and rely on the global string table to store and maintain data items, it is important to understand the underlying concepts in memory management and the use of the STBL() function.

When PRO/5 is initialized, it STARTs with a fixed amount of memory that constitutes its working environment. This working environment may be divided into program memory and data memory. Both of these memory areas are dynamic and are allocated from available memory as needed. Additionally, PRO/5 needs memory for all CALLed programs and the global string table. As programs are CALLed and global space is used, PRO/5 allocates multiple chunks of memory as needed. As more global data space is used, it begins to have an iceberg effect on the memory chunks. If this data is configured and stored at one time, memory fragmentation is kept to a minimum. This is another reason for maintaining a central storehouse of global data.

The use and management of CALLed program memory is not within the scope of this Appendix. However, it is important to understand that there must be available memory for both CALLed programs and the global string table for the EUS Toolkit programs to run.

Global Data Concepts

When PRO/5 is first invoked, the global string table contains four global strings: (!EDIT), (!TERM), (!CTYPE), and (!DATE). These entries are vital to PRO/5 and should never be removed.

The global string table is not a fixed amount of memory but is dynamically allocated from available memory. On operating systems such as the UNIX OS, this is normally not a problem. It may, however, be a consideration when operating in a minimally configured DOS environment. For this reason, it is necessary to avoid overloading the global data area. It is also important to understand that the continued addition and removal of items from the global string table will result in memory fragmentation and may cause memory constraints.

The global string table is linear in nature and does not use any hash indices to access individual data items. All items are maintained in a static position within each data area, unless removed and reinserted. This means that any STBL() function call to an item requires a search from front to back. Normally, this should not be a problem. But, if multiple lookups of the same item are performed, it is better to get the global item once and then use that local variable to reference the data item. This is especially true as global data items grow in number.

For example, instead of continually invoking:

CALL STBL("BBEXT")+"_acu.utl"
CALL STBL("BBEXT")+"_lkeymap.utl"

define a local variable once, and then utilize this variable:

CALL "_acu.utl"
LET BBEXT$=STBL("BBEXT")
CALL BBEXT$+"_lkeymap.utl"

Global String Management

The global string table is a linear data space. PRO/5 provides a convenient way of clearing this area from one data item to the end of the data area. It is possible to put a marker item in the global string table and use that marker to clear all data entries from that point forward to the end of the data area. This provides a convenient way to clean up after a program or an application.

An application could begin using the global data space by some specific tag (the value of the tag is not important) such as:

TRASH$=STBL("{BEGIN}",$$)
[add variables here]

Because global data items are added to the front of the data space, this value will be added within the data space and all subsequent values will precede this entry. Therefore, when the application finishes, it can clean up with the following function call:

TRASH$=STBL("!CLEARTO","{BEGIN}")

The global string table can be compared to a memory bucket that is filled from the bottom. Once the marker is in place, additional items will be placed on top of this value. Therefore, in order to clear a current region, PRO/5 will CLEARTO the marker (from the top of the memory area).

The EUS Toolkit includes a program, _cleanup.utl, that clears all EUS data items created since invoking _acu.utl. The EUS maintains a global group of all EUS data items that _cleanup.utl uses to clear these specific data items. Therefore, any data items added outside the _acu.utl program will not be cleared by this program. This provides a method of restoring the environment, especially in an emergency.

REM " Set up environment:
CALL "_acu.utl"
LET BBEXT$=STBL("BBEXT")
REM " Set up keyboard :
CALL BBEXT$+"_lkeymap.utl"
REM Restore original keymap :
CALL BBEXT$+"_rstold.utl" )
REM Clean up global data space:
CALL BBEXT$+"_cleanup.utl")
REM " Back to original state, assuming no additions outside _acu.utl

Global Data Usage

Any items can be added as needed to the global string table. Items stored there are exempt from all data-destructive commands such as CLEAR, RESET, and BEGIN. Therefore, global string data is available to any application program, regardless of the prior state of the environment.

It is unnecessary to know all the global string names used by the EUS programs. With only a few exceptions, most EUS global string names begin with the pound (#) or exclamation (!) character Conflicting names can be avoided if the application uses some other initial character. There are also several reserved names in the EUS for graphical environments: (MOUSE), (MOUSETAG), and (RKEYMAP). Review Getting Started for additional information on global string names. Other names may be included in these groups in future product releases.

Templated strings must be stored in the global string table in separate components (template and data).

One method of saving a templated variable in the global string table is to set up related entries, such as:

LET TRASH$=STBL("%TEST_DATA.TPL",FATTR(TEST_DATA$))
LET TRASH$=STBL("%TEST_DATA",TEST_DATA$)

The data would be retrieved by code similar to the following:

DIM TEST_DATA$:STBL("%TEST_DATA.TPL")
LET TEST_DATA$=STBL("%TEST_DATA")

An alternative method uses a backslash (\) character as a separator between the template and data:

LET TRASH$=
STBL("%TEST_DATA",FATTR(TEST_DATA$)+"\"+TEST_DATA$)

The data would be retrieved by code similar to the following:

LET TRASH$=STBL("%TEST_DATA")
LET TRASH=POS("\"=TRASH$)
DIM TEST_DATA$:TRASH$(1,TRASH-1)
LET TEST_DATA$=TRASH$(TRASH+1)

This method reduces the number of required global string names to more efficiently use the global data space in applications that store large numbers of templated variables in the global string table.