The CANCEL statement places the specified program in its initial state (see above). By default, the program is removed from memory. Subsequent calls to the program cause it to be reloaded from disk. This type of cancel, in which the program is removed from memory, is called a physical cancel. Alternatively, as an aid to tuning system performance, you can set up a system in which canceled programs are placed in their initial state but are left in memory until a specified memory limit is reached. Such cancels are called logical cancels. Subsequent calls to these programs start very quickly because the programs are already in memory. When the memory limit is reached, all logically canceled programs are removed from memory. Two runtime configuration variables are used to set up this system. See DYNAMIC_MEMORY_LIMIT and LOGICAL_CANCELS for more information.
When using logical cancels, replacing an object file on disk does not necessarily mean that subsequent calls to the program will use the new object. To force a subsequent call to load the new object file from disk, you must configure ACUCOBOL-GT to perform a physical cancel on that program.
Also, the use of logical cancels has some implications on debugging. The ACUCOBOL-GT debugger periodically reads source code from the object file on disk. When program code is cached by a logical cancel, the object file is closed and could be replaced or deleted. For the debugger to function correctly, it needs to keep the object file open and ensure that the object code in the disk file is identical to the code in memory. If the program is cached, the debugger accomplishes this by unloading the program from the cache, reopening the object file, and reloading the object code into memory. Because this effectively turns off logical cancels and the code caching feature when the debugger is active, the runtime configuration variable DEBUG_NEWCOPY can be used to control the runtime's behavior.