BLINKER MEMORY PACK           Specify CA-Clipper Summer '87 memory packing frequency
------------------------------------------------------------------------------

 Purpose  : Specify CA-Clipper Summer '87 memory packing frequency

 Syntax   : BLINKER MEMORY PACK <nuFrequency>

 Default  : 0

 Example  : # Set the packing to once every 20 overlaid procedure calls
            BLINKER MEMORY PACK 20

 This command is used to set the frequency with which the Blinker overlay
 manager defragments CA-Clipper Summer '87 free memory. The parameter is a
 decimal number indicating the number of overlaid procedure calls after which
 memory is defragmented, and may be set to any value from 0 to 65534. (The
 default value is 0, which causes no packing to occur.)

 CA-Clipper is continually allocating and freeing dynamic memory, causing it
 to become more and more fragmented as execution of an application continues.
 CA-Clipper only considers memory to be available if it is in chunks of 4kb
 or greater, thus large applications can often run out of memory after
 prolonged execution.

 The BLINKER MEMORY PACK command allows the developer of a CA-Clipper Summer
 '87 application to defragment dynamic memory as often as needed without
 modifying the application, and to tune the frequency of the packing to suit
 the individual application. This process is also performed by the CA-Clipper
 function MEMORY(0), but much more slowly.

 The defragmentation process consists of two things: joining up of contiguous
 blocks of free memory, and then resetting the roving pointer which is used
 in selecting (indicating) the next memory allocation. At the time of the
 defragmentation, this pointer is set to specify the highest available
 location in memory. This causes memory to be allocated from the beginning
 each time rather than fragmenting the whole memory area, which can
 significantly reduce the deterioration of available memory due to
 fragmentation.

 Due to the underlying architecture of CA-Clipper Summer '87's memory
 allocation scheme, it is not possible to move allocated blocks of memory
 around, as there is no means of updating the pointer(s) to allocated blocks.
 This means that true garbage collection is impossible, but the
 defragmentation described here is the next best thing, and helps the problem
 considerably.

 Setting the frequency to a low number may slow down the application, but
 will keep memory fragmentation to a minimum, giving the maximum saving on
 memory. Setting the frequency to a higher number will not noticeably slow
 the application down, but the memory gain will be less as the fragmentation
 will be relatively worse (although still a lot better than with no packing
 at all.)

 An optimum frequency appears to be around 10 for an average application,
 giving a significant increase in memory while not significantly slowing the
 application. The optimum frequency for a given application may vary
 considerably from this frequency, and can only be established by trial and
 error.