Storage concept
Subsystems are loaded as follows, depending on the declaration:
into the system address space (class 3 or class 4 memory)
if MEMORY-CLASS=*SYSTEM-GLOBALinto the user address space (memory pool: class 5 or class 6 memory) if MEMORY-CLASS=*LOCAL-PRIVILEGED/*LOCAL-UNPRIVILEGED
into both address spaces if MEMORY-CLASS=*BY-SLICE
Interfaces to subsystems in the user address space are possible only if the allocated address area in the local task is free. The code must always be located at the same address after linkage. For generally accessible subsystems in the user address space, which can be addressed by any task at any time, a fixed area in class 5 memory is reserved, known as the “address space strip”. This address space strip is shared by all generally available subsystems, with a separate strip being available for each nonprivileged subsystem.
Problems can occur for user tasks if there is not enough class 5 memory space. The address space strip reserved for subsystems can be released by means of the DSSM command RELEASE-SUBSYSTEM-SPACE in order to obtain more class 5 memory space.
Subsystems that are not used at the same time and therefore do not call each other may be located in parallel within the address space. The more parallel subsystems there are, the smaller is the address space strip required. Care should be taken to ensure the right balance of parallel subsystems, since a high degree of parallelism, though it saves address space, may result in a deterioration of performance (the more parallelism, the more mutual preemption). The distribution of the subsystems within the address space strip can be controlled using the SSCM statement SEPARATE-ADDRESS-SPACE.
Address space housekeeping
DSSM address space housekeeping provides a means of reducing the load on the system address space (class 3 and class 4 memory) by putting subsystems in the address space of the holder task. This is only of relevance to nonprivileged subsystems, however, because all privileged subsystems are always loaded into the system address space (MEMORY-CLASS=*SYSTEM-GLOBAL).
Transfer is straightforward, provided that the subsystems do not call each other, do not depend on each other through a third program, and do not have the ability to run in class 6 memory as a main program.
Note that it is only possible to attempt to relocate nonprivileged subsystems which are currently below the 16-Mbyte boundary.
For all other nonprivileged subsystems, loading above the 16-Mbyte boundary is recommended (SUBSYSTEM-ACCESS=*HIGH).
Subsystems which are reentrant-compatible and run as main programs can also be swapped out of the system address space. They must be available in the memory pool in the class 6 memory (MEMORY-CLASS=*LOCAL-UNPRIVILEGED).
There is a strategy aimed at minimizing system address space occupancy for subsystems that consist of a shareable code (program area) and a non-shareable code (data area). This strategy works as follows:
The program area is loaded into the shareable address space (this corresponds to MEMORY-CLASS=*SYSTEM-GLOBAL). The data area is loaded into the user address space of the holder task; then, when a task is linked to the subsystem in the task’s private user address space, it is copied to the same address.
This strategy is implemented when a subsystem is defined with MEMORY-CLASS=*BY-SLICE.
The advantages of this approach are as follows:
address-related references between the program area and data area are always possible because the copy of the data area begins at the same address as the original
performance is considerably enhanced by this type of address space apportionment because no access is made to the program library or object module library when a task is linked to the subsystem, and external references do not need to be resolved.
The disadvantages of this approach are:
once the address space for the data area has been defined and reserved at the time of startup, it can be expanded to only a very limited degree; optimization of memory space is not possible because of the strict apportionment of address space
if the address space belonging to the task being linked and intended for the data area is already occupied, the subsystem code (data area and program area) is loaded in its entirety into the user address space of that task.
Relocation from the system address space to the user address space is only worthwhile in the following cases:
Where subsystems which are independent of each other and are not used simultaneously by user programs can be placed in parallel in the user address area. If this is not the case, relocation is pointless, since they will take up more memory in the user address space than in the system address space.
Where the subsystems are large enough to compensate for the loss that occurs through the use of the memory pool (minimum size of a memory pool: 1Mbyte).
Where the subsystem must be located below the 16-Mbyte boundary (for subsystems which may also be loaded above this boundary, the operand SUBSYSTEM-ACCESS= *HIGH can be used to counteract any overloading of the lower 16 Mbytes).
Summary:
It is only appropriate to use parallel configuration of independent subsystems in memory pools if the sum of the sizes of all the subsystems amounts to over 1Mbyte and none of the subsystems is larger than 1Mbyte in size.
Task concept - holder task
A subsystem is activated under its own task, the holder task. Depending on the type of subsystem, this task can be used as a subsystem work task or as a pure holder task. The user address space of this task can be used for relocation from the system address space.
The number of holder tasks required should be kept as small as possible. A large number of tasks does have a positive effect on parallelism, since the more tasks are created at the same time, the more subsystems can be installed. On the other hand, more tasks also require more task-specific tables.
DSSM itself minimizes the number of holder tasks. However, the distribution of subsystems can also be controlled with SSCM by means of the ASSIGN-HOLDER-TASK statement during generation of the subsystem catalog.
The default option is that all subsystems defined with MEMORY-CLASS=*BY-SLICE are connected to the same holder task.
If an error occurs, a restart of the holder task is automatically initiated, to avoid bringing down all the subsystems which are connected to the holder task. Provision is also made for restarting a subsystem by means of the RESTART-REQUIRED operand of the SET-SUBSYSTEM-ATTRIBUTES command. This parameter makes it possible to call the subsystem initialization again if the holder task was terminated during the execution of subsystem routines (see "Error handling in DSSM").