Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

General notes on improving loading speed

  • All the PLAM libraries involved should be organized as efficiently as possible, i.e.

    • they should contain no redundant LLMs

    • they should be completely reorganized, so that the LLMs they contain are not split into an unnecessary number of extents

    • the library itself should comprise as few extents as possible

    • the library should possibly be created using (STD,2).

    All these measures reduce the number of I/Os and improve runtime behavior. The effectiveness of these measures is, of course, dependent on the original structure. A library created with (STD,2) will be larger than the original library by about 1 KB per member. The reduction in I/O operations will be greater, the more members the library has, provided that these members are not too small. Runtime improvements can then amount to over 10%.

  • If modules have the READ-ONLY attribute, one slice should be generated for read-only modules and one slice for read/write modules. This speeds up the loading process by reducing both CPU requirements and I/O operations.

  • The number of library accesses is reduced if all symbols not required for subsequent BINDER runs are set to “invisible” with the BINDER statement

    //MODIFY-SYMBOL-VISIBILITY SYMBOL-NAME=...,SYMBOL-TYPE=...,

                               SCOPE=...,VISIBLE=*NO,...

  • If PUBLIC/PRIVATE slices are to be used, format 2 should be used in order to reduce the CPU requirements of BLS and DSSM (see the BINDER statement //SAVE-LLM ... FROM-BS2000-VERSIONS=*FROM-V11).

    The operand SUBSYSTEM-ENTRIES in the BINDER statement //START-LLM-CREATION allows you to specify a symbolic name for the links between the private and public slice. This name must also be defined in the DSSM catalog. (DSSM is called for every link with the old format.)

  • You should ensure that the LOGGING parameter in the DSSM parameter file is not set to ON (default: OFF). ON would cause DSSM data to be logged when subsystems are loaded.