Structural measures for reducing resource requirements

Unfortunately, it is rarely possible to quantify precisely the effect of each of the measures described below. The effects depend to a large degree on the structure of the load objects, the subsystems and the libraries. One can, however, generally assume that a gain of at least 10% can be achieved with each of the measures.

Reduce the number of libraries or optimize their contents

• Merge alternative libraries

  If alternative libraries are merged to form a single library (this could even be the specified load library), this results in a considerable reduction in search operations in BLS/PLAM, which in turn leads to a saving in I/O operations and CPU time which is sometimes considerable greater than 10%.

  Merging is generally only recommended if no entries or CSECTs exist with the same name.

• Link in modules from libraries permanently

  If the contents of the alternative libraries and the specified library never or only rarely change, it may be advisable to link the modules into the load object permanently. This reduces the CPU requirements on loading. On the other hand, static linking means that the load object will increase in size, thus generally causing more I/O operations, which in turn increases the runtime.This measure makes sense, therefore, if only small modules are involved and if the alternative libraries contain a particularly large number of entries.

  If you adopt this strategy for improving performance, you must, of course ensure that the link procedure is repeated each time the alternative library is modified.

• Mixed strategy

  If, for instance, the contents of only one of the alternative libraries is modified regularly, it may be advisable to adopt a mixed strategy using both of the methods described above.

Restricting dynamic loading of shared code

• Do not dynamically load/link shared code

  Many programs do not need to dynamically load/link from a subsystem/shared programs or user shared memory. These programs should be started as follows:

  /START-EXECUTABLE-PROGRAM ...,RESOLUTION=(SHARE-SCOPE=*NONE),...

  This prevents BLS from searching the subsystems for the appropriate entry, resulting in an often considerable reduction in CPU time.

• Only dynamically load from system memory

  This is the default. It is not possible to restrict the search for the entry performed by DSSM to specific subsystems or to shared programs only.

• Only dynamically load from user shared memory

  When you issue the START-EXECUTABLE-PROGRAM command, you can issue the parameter

  RESOLUTION(...,SHARE-SCOPE=*MEMORY-POOL(...)...)

  to restrict loading to user shared memory. It is also possible to further restrict the operation to specified memory pools.

• Preload user shared memory

  As far as possible, all shareable sections of the applications in use should be preloaded (e.g. FOR1-RTS). This means that they are loaded only once and only need to be linked (with little overhead) for each further load operation. This strategy generally results in a saving of considerably more than 10% in I/O operations and CPU requirements.

Eliminating ESD information

• Complete elimination

  This measure only applies for standalone programs. These are LLMs which are not called by other programs and which are completely prelinked. For programs of this type, the load operation can be accelerated if the ESD and other BLS information tables are eliminated using the appropriate BINDER call. Call BINDER as follows:

  /START-BINDER
  //START-LLM-UPDATE LIB=<orig-lib>,ELEMENT=<elem-name>
  //SAVE-LLM LIB=<new-load-lib>,TEST-SUPPORT=*NO,MAP=*NO,
             SYMBOL-DICTIONARY=*NO,LOGICAL-STRUCTURE=*NO,
             RELOCATION-DATA=*NO
  //END
  

  This parameter specification means that only those BLS structures are created which are required for loading a simple program, thus reducing the size of the object. This saves CPU time and I/O operations when the program is loaded. All the information required for other processing is then no longer available. This means that

  • these parameters cannot be used for load objects which are split into a number of slices

  • no LLM updates can be carried out on an object of this type.

  • relocatable objects (e.g. as part of a runtime system) cannot be created.

  The (supplementary) parameter setting REQUIRED-COMPRESSION=*YES should not be selected, since, although up to 10% of I/O operations can be saved, approx 40% more CPU time is required.

• Partial elimination

  When merging LLMs or sub-LLMs to form a prelinked module with a single CSECT, you should specify what ESD information is to remain in the external address book with the BINDER statement MERGE-MODULES. This can result in a considerable reduction in BLS overhead during loading.