Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Generating shareable objects that are loaded in a common memory pool

If parts of your application program are to be loaded in a common memory pool, you should note the following:

  • 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.

  • If a compiler created two separate object modules for the shareable and non-shareable part, then you should link these modules beforehand to an LLM with slices using the binder.

  • 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, while the private slice is loaded later either when the application is started (STARTUP) or when the program is called (ONCALL). PROGRAM statements are also needed for the programs of this LLM that are to be called using openUTM.

    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 that 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 binder can also be linked together beforehand with other modules in one LLM with slices. This LLM can then be generated as follows:


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

     

Example

The example assumes that the COBOL compiler was used for compiling and that the compiler stored the objects in an LLM. The shareable modules of the COBOL program units PU1 and PU2, the format descriptions FORMAT1 and FORMAT2, and the data module DATAMOD are to be loaded in the local application pool LCPOOL. LCPOOL is to be loaded at address X’020000’, is to be capable of occupying 128 KB, and is to 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 prelinked to the LLM LLM-LCPOOL before the application starts, which means that the option BY-ATTRIBUTES(PUBLIC=YES) must be specified in the BINDER statement START-LLM-CREATION, whereby the LLM is split into a public slice and a private slice. The LLM created in this way must be supplied in the libname library.