Shared code in common memory pools

Objects that are not linked statically when linking the application program can be loaded into a common memory pool. In a common memory pool you can dynamically load several load modules.

A common memory pool must be generated with the KDCDEF statement MPOOL.

MPOOL statement in section "MPOOL - define a common memory pool (BS2000 systems)" The most important properties for common memory pools are defined with the following operands:

• poolname

  Name of the common memory pool. This name is used at generation to assign to a pool those load modules whose Public Slice is to be loaded to the pool (see LOADE-MODULE statement).

• SCOPE=

  Specifies the scope of the pool (local application with SCOPE=GROUP or global application with SCOPE=GLOBAL).
  For each BS2000 user ID, BLS supports a maximum of eight common memory pools with SCOPE=GROUP and eight common memory pools with SCOPE=GLOBAL.

• PAGE=

  Hexadecimal address in the form X’xxxxxxxx’.
  If global common memory pools with the same contents/names are used in several UTM applications, the parameter PAGE=X’xxxxxxxx’ must be specified with the same address in all applications. The address entered using PAGE= is to be selected in such a way that the address area reserved is available in all these applications.

• SIZE=

  Specifies the size of the common memory pool.
  The size is specified in units of 64 KB. With 24-bit addressing, the size of a common memory pool is always a multiple of 64 KB. With 31-bit addressing, the size of the common memory pool is calculated by n * 1MB >= SIZE * 64 KB (where n is selected as a minimum).

Only one common memory pool should be defined with SCOPE=GROUP. A number of statically linked load modules can be loaded into this pool. This reduces the time required to set up and load the common memory pools and thereby minimizes the time needed to start the application.

Generating shareable objects that are to be loaded in a common memory pool

The following section describes how you generate shareable objects that are to be loaded in a common memory pool if you are working with BLS.

• For performance reasons, all shareable parts of an application program that are to be loaded in a common memory pool should, as far as possible, be combined into one load module.

• The program’s shareable code module created by the compiler must be contained in an LLM or OM. LLMs with slices can be generated with a single LOAD-MODULE statement:

  LOAD-MODULE llm-name ,VERSION= version -
    ,LOAD-MODE=(POOL, poolname ,{STARTUP|ONCALL}- 
    ,LIB= program-lib -
    ,ALTERNATE-LIBRARIES={YES|NO}

  With this statement, the public slice of the LLM is loaded in the common memory pool poolname, and the private slice is loaded dynamically either when the application starts (STARTUP) or when the program is called (ONCALL). Additional PROGRAM statements are required for the programs of these LLMs that are called by openUTM.

  If a compiler created two separate object modules for the shareable and non-shareable part, then should link these modules beforehand to an LLM with slices using the linker. You can then generate this LLM as described above.

  Alternately, you can also generate the shareable and non-shareable module using two LOAD-MODULE statements. You should avoid this, if possible, because you cannot exchange these two modules without having inconsistencies arise.

• A shareable data area which is to be loaded in the common memory pool must be described with an AREA statement. The area must then be contained in the load module which is generated as follows:

  LOAD-MODULE ar-share ,VERSION= version - 
    ,LOAD-MODE=(POOL, poolname ,NO-PRIVATE-SLICE) - 
    ,LIB= libname

  Areas that were assigned the PUBLIC attribute during compilation or by the linker can also be linked together beforehand with other modules in one LLM with slices. This LLM can be generated in the following manner:

  LOAD-MODULE llm-with-slices ,VERSION= version - 
    ,LOAD-MODE=(POOL, poolname ,STARTUP)- 
    ,LIB= libname

Example

The example assumes that the COBOL85 compiler was used for compiling and that the compiler has saved the objects in an LLM.

The shareable modules of the COBOL program units PU1 and PU2, and the data module DATAMOD are to be loaded in the local application pool LCPOOL. LCPOOL is to be loaded at address X’020000’, occupy 128 KB, and be write-protected.

MPOOL        LCPOOL,SIZE=2,SCOPE=GROUP,ACCESS=READ,PAGE=X'20000'
LOAD-MODULE  LLM-LCPOOL,VERSION=1,                                   - 
             LOAD-MODE=(POOL,LCPOOL,STARTUP),                        -
             LIB=libname    
PROGRAM PU1 ,LOAD-MODULE=LLM-LCPOOL,COMP=ILCS
PROGRAM PU2 ,LOAD-MODULE=LLM-LCPOOL,COMP=ILCS
AREA DATAMOD,LOAD-MODULE=LLM-LCPOOL

The object modules must be statically linked to the LLM-LCPOOL LLM before the application is started, i.e. you must specify the option BY-ATTRIBUTES(PUBLIC=YES) in the BINDER statement START-LLM-CREATION, whereby the LLM is divided into a public slice and a private slice. The LLM created in this way must be made available in the library libname.