Strategy for Successful CHAINing with COBOL 3.00 Is Available
PSS ID Number: Q45709 Article last modified on 04-26-1991
3.00 3.00a | 3.00 3.00a MS-DOS | OS/2
Summary: An article is available in the Software/Data Library that explains in detail how the CHAIN statement releases memory in Microsoft COBOL Versions 3.00 and 3.00a for MS-DOS and MS OS/2. COBCHAIN can be found in the Software/Data Library by searching on the keyword COBCHAIN, the Q number of this article, or S12327. COBCHAIN was archived using the PKware file-compression utility. This article in the Software/Data Library may also be obtained as an application note on paper from Microsoft Product Support Services by calling (206) 454-2030. Ask for the application note called “Successful CHAINing with COBOL 3.00.”
More Information: Below is a summary of the application note. For more detailed explanations and diagrams, please refer to the complete application note. Using multiple CHAINs often results in memory fragmentation. This is due to two traits of the COBOL 3.00 CHAIN: 1. The first program that is run in the CHAIN stays in memory until all programs in the CHAIN are ended. 2. When a program is CHAINed to after the first program, its memory is not released until the second subsequent CHAIN. The memory fragmentation problem often occurs in COBOL 3.00 or 3.00a when updating from COBOL 2.00, 2.10, or 2.20 programs, which rely heavily on CHAINing. In COBOL 2.x, only the current program remains in memory. There are three steps in the strategy to avoid memory fragmentation and to successfully CHAIN in COBOL Version 3.00 or 3.00a: 1. A “DRIVER” program must do all of the CHAINing. The program that is CHAINed-to should always CHAIN back to the DRIVER. The DRIVER then should CHAIN to the next program in the CHAIN. 2. You must statically link in any support modules to the DRIVER.OBJ. The COBOL support modules are .OBJ files that contain the code support for programming ACCEPT, DISPLAY, INDEXED files, and EXTERNAL files and data. For example, a program that uses INDEXED files, ACCEPTS, and DISPLAYS uses the following link line: LINK DRIVER.OBJ+ADIS.OBJ+ADISINIT.OBJ+ADISKEY.OBJ+IXSIO.OBJ; If you use EXTERNAL data, you must add EXTERNL.OBJ to this link line. If you use EXTERNAL files, exchange EXTFH.OBJ for IXSIO.OBJ. This means that you would link in EXTFH.OBJ and not IXSIO.OBJ because EXTFH.OBJ supports both EXTERNAL FILEs and INDEXED files, but IXSIO.OBJ handles only INDEXED files. Once you have linked these modules into the DRIVER program, it is not necessary to link them with any of the CHAINed programs. This is because the DRIVER is the first program run, and always remains in memory. Therefore, the support modules linked to it are always available to the current CHAINed program. 3. If you use any files, the first time the DRIVER program is executed, it must OPEN one INDEXED file and one file of any other type, RELATIVE or SEQUENTIAL, and leave them OPEN until the last CHAIN has finished. These files should be two “dummy” files so that leaving them open for the duration of the program will not cause problems. This is necessary because there are two buffer regions associated with files, a 64K buffer region used by INDEXED files and a 32K buffer region used by other files. By OPENing and leaving OPEN these files in the DRIVER program, the buffers are allocated immediately above the DRIVER.EXE program and remain stationary as long as these files are OPEN. Note that these are “buffer regions” and not the file buffers themselves. These buffer regions are memory that is set aside for allocation of file buffers. Every time a file is opened, a file buffer is allocated inside of one of these two regions. If all files are CLOSEd in the run-time system, then the memory for these areas is released. This is why the driver must leave them OPEN the two “dummy” files so that the buffer regions remain stationary.
Copyright Microsoft Corporation 1991.
