HP 3000 Manuals

Micro Focus COBOL for UNIX COBOL User Guide

Handling Large Programs 

UNIX             The Micro Focus COBOL system enables you to execute
                 statically linked or dynamically loadable code.
                 Statically linked code is an executable object module
                 which has all of its overlays permanently linked into
                 memory.  Dynamically loadable code is either a COBOL
                 intermediate code (.int) file or a COBOL native code
                 (.gnt) file.  The dynamic loader loads COBOL program
                 overlays as needed.

When designing a COBOL application program that is to be dynamically
loadable, you want it to make efficient use of the available memory.

It is possible, using the COBOL system, to create and run programs that
use more memory than is physically present in your computer.  There are
two ways you can do this:

   *   Carefully segment one large COBOL program so that it holds on disk
       the code that is not being used, or

   *   Separate the program into smaller programs and use the COBOL call
       mechanism.

The following sections look at these topics.


NOTE  Segmentation is rarely required for 32-bit operating systems as
      memory management is not usually a problem.  However, the facility
      is available should it be required and so is described here.


Segmentation (Overlaying) 

This section describes the segmentation mechanism, which enables you to
divide a COBOL program with a large Procedure Division into a COBOL
program with a small Procedure Division and a number of overlays
containing the remainder of the Procedure Division.  Segmentation enables
all of the Procedure Division to be loaded into the available memory.
However, because it cannot be loaded all at once, it is loaded one
segment at a time to achieve the same effect in the reduced memory space. 

To segment a program, you must divide it into sections by using a SECTION
label.  Each group of sections with a common section number then forms a
single segment in the Procedure Division.

For example:

           . . .
           . . .
      section 52.
          move a to b.
           . . .
           . . .
      section 62.
          move x to y.
           . . .
           . . .

You can use segmentation only on the Procedure Division.  The
Identification, Environment and Data Divisions are common to all
segments.  In addition there might be a common Procedure Division segment
called the root segment.  All of this common code is known as the
permanent segment.  The Compiler makes space for the permanent segment
and for the largest independent segment in a segmented program.  See your
Language Reference for a complete description of control flow between
permanent and independent segments. 

You can suppress segmentation at compile time using the NOSEG Compiler
directive, even if you specify segment numbers.

Communication (CALL) 

Interprogram 

This section looks at the interprogram communication (call) mechanism for
creating large applications but avoiding large programs.

The COBOL system enables you to design applications as separate programs
at source level.  Each program is then called dynamically from the main
application program, without first having to be linked with the other
programs.  The format of the call statement is described in your Language 
Reference.  An intermediate code program can call a native code program
and vice versa.

Figure 3-1  shows an example of an application divided up in this way.


          Figure 3-1.  Application Divided Using CALL 

The main program A, which is permanently resident in memory, calls B, C,
or H, which are programs within the same suite.  These programs call
other specific functions as follows:

       B calls D, E and F

       C calls X, Y, Z, L and K

       H calls K

       K calls M, N and O.

Because the functions B, C and H are stand-alone they do not need to be
permanently resident in memory together.  You can call them as they are
needed, using the same physical memory when they are called.  The same
applies to the lower functions at their level in the tree structure.

In the figure, you would have to plan the use of CALL and CANCEL
operations so that a frequently called subprogram such as K would be kept
in memory to avoid load time.  On the other hand, because it is called by
C or H, it cannot be initially called without C or H in memory; that is,
the largest of C or H should call K initially so as to make space.  It is
important also to avoid overflow of programs.  At the level of X, Y and
Z, the order in which they are loaded does not matter because they do not
make calls at a lower level.

If a called program opens files, and needs to keep them open while other
programs in the application are executing, it is better to leave the
called program in memory to avoid having to reopen the files on every
call.  The EXIT statement leaves files open in memory.  The CANCEL
statement closes the files and can release the memory that the canceled
program occupies, provided all other programs in the executable file have
been canceled or never called.

If you use a tree structure of called, independent programs as shown
earlier, each program can call the next dynamically by using the
technique shown in the following sample coding:

     working-storage section.
      01 next-prog        pic x(20) value spaces.
      01 current-prog     pic x(20) value "rstprg".

     procedure division.
      loop.
          call current-prog using next-prog
          cancel current-prog
          if next-prog = spaces
              stop run
          end-if
          move next-prog to current-prog
          move spaces to next-prog
          go to loop.

The actual programs to be run can then specify their successors as
follows:

          . . .
          . . .
      linkage-section.
      01 next-prog pic x(20).
          . . .
          . . .

      procedure division using next-prog.
          . . .
          . . .
          move "follow" to next-prog
          exit program.

In this way, each independent segment or subprogram cancels itself and
changes the name in the CALL statement to call the next one with the
USING phrase.

Call Requirements 

Having decided to use the call mechanism for your application, the
following sections look at some of the practical aspects of creating such
applications.

The total number of programs which can be loaded in memory as the result
of a call is not constant.  The number depends on the amount of available
memory in your computer and the size of the program being called.

One consideration regarding dynamically called programs is the amount of
memory fragmentation at the time of the call.  By calling and canceling
dynamically linked subprograms, it is possible to have free areas of
memory scattered among blocks of memory allocated to active subprograms.
With free memory fragmented into several small blocks, there might not be
enough contiguous free memory to load a dynamically linked subprogram.
When a program is dynamically called, the following conditions affect its
loading:

   *   There must be enough contiguous memory free to load the program.
       Note that overlaid programs allocate enough memory to hold the
       root and the largest overlay.

   *   The run-time system must be able to open the executable file.
       This might not be possible if the operating system's limit on the
       number of open files has been reached.

   *   On UNIX, canceling a COBOL program actually frees memory only if
       the -l run-time switch is set to 0.  If this switch is not set,
       the program is merely marked as being canceled.  Subsequent calls
       to the program need only initialize the Data Division and mark the
       program active once more.  With -l0 set, the program must again be
       searched for on disk and loaded.  If the limit set by the -l
       switch is exceeded, programs marked as canceled are canceled
       properly in order to free memory resource.

Dynamically called programs have an advantage over programs that have
been linked into a single executable file in that dynamically called
programs have their memory freed when they are canceled while the latter
do not.

Public Symbols and Your Program-ID 

Every program must have an entry point and a public symbol as the name of
that entry point.  If your program includes a Program-ID paragraph, the
Compiler uses that name as the name of the entry point.  If no Program-ID
paragraph exists, then the Compiler uses the file-name of the .o file
(from the command line) as the name of the entry point.

Programs which are linked together are called by the entry-point name.
However, dynamically called subprograms can only be called by their
file-names since the run-time system must perform disk searches to load
them.  In this case the file-name and entry-point name must be the same.

So, to avoid errors we recommend that you do not use the Program-ID
paragraph, or, if you do, use the same name as the file-name (without the
extension).  This also provides more flexibility in constructing your
executable programs since you can choose to link them or use them as
dynamically called programs without having to change the source code.

For details on the Program-ID paragraph, see your Language Reference.

MPE/iX 5.0 Documentation