RM/COBOL supports two forms of memory management. One form is the standard ANSI COBOL form. This is also the memory management scheme used by ACUCOBOL-GT. If your RM/COBOL application uses the ANSI-style of memory management, then you do not need to make any changes to run under ACUCOBOL-GT.
The RM/COBOL implementation of the ANSI memory management is very restrictive, however, in that the main program plus the set of all called programs must fit in 64K bytes (except for those that are canceled). For this reason, many applications use RM/COBOL's alternate mode of memory management. In this mode, all of the currently active programs must fit in 64K bytes, but programs that are not currently active need not. This has the effect of dynamically canceling inactive subprograms as needed to free up enough space. This has the advantage that the programmer largely does not need to worry about canceling subprograms. When this style of memory management is used, however, the programmer cannot depend on a subprogram's remaining loaded in memory. This can cause variables to lose values. RM/COBOL also causes open files in a subprogram to be closed when that subprogram exits (except for files assigned to a printer).
ACUCOBOL-GT has a much larger address space, and thus has no need for this scheme. Furthermore, this form of memory management results in unpredictable behavior, since the state of a called and exited subprogram is unknown. For these reasons, ACUCOBOL-GT does not directly support the alternate form of RM/COBOL memory management.
ACUCOBOL-GT does, however, have several techniques that can be used when you are converting programs that use this style of memory management. Virtually any RM/COBOL program will run under the ACUCOBOL-GT memory management scheme. The only significant problem that applications face has to do with handling menus. These applications have one or more master menus that the user selects specific tasks from. Usually, each of these tasks is a separate program that is called from the menu program when selected. Since ACUCOBOL-GT abides by the ANSI/ISO standard, each of these programs remain in memory until explicitly canceled. As the user chooses more and more menu selections, the memory used can become large. This could eventually overrun the amount of memory available in the machine.
The ANSI/ISO solution to this problem is to cancel the task-handling subprograms when they are finished. This would normally happen when control is returned to the menu program. ACUCOBOL-GT has an extension to the CANCEL verb to make this task easier. This is the statement CANCEL ALL. This statement has the effect of canceling every program except for those that are currently active. This has the following advantages over the standard CANCEL statement:
This is probably the easiest way to handle the memory management problem. Another technique, however, that gives you greater control is to use the INITIAL PROGRAM attribute. Any program that has the initial attribute is automatically canceled whenever it exits. You can specify the initial attribute by either of these methods:
You can use this technique if you want greater control over memory management than the CANCEL ALL statement gives you.
Finally, do not overlook the standard CANCEL verb. This has the advantage that it is part of both the 1974 and 1985 COBOL standards.
For more information about run-time memory management, see Memory Management.