A local application pool is created by the first task of an application. All subsequent tasks of this application likewise access this pool, i.e. the pool is created with SCOPE=GROUP in the context of BS2000 memory pool management. Tasks of other UTM applications that were started under the same user ID can also connect to this common memory pool.
The local application pool offers the following advantages for the user:
The programs loaded in this pool can only be used from this user ID.
The user has full control over the use of shareable objects, regardless of the system initialization.
The pool only exists for as long as the application is running or, if a number of applications are accessing the pool, until the last application has terminated. When the application ends, the pool is cleared and the programs – like all other application programs – are unloaded.
The programs loaded in a common memory pool can also be exchanged dynamically during the application run under certain conditions. For more information, see the chapter "Exchanging programs during operation".
The physical memory is utilized more efficiently.
When the (last) application terminates, the pool is cleared and the programs are unloaded (as are all other application programs).
CAUTION!
All modules, formats, and data areas have the same access authorization within a pool.
Programs loaded in common memory pools may not contain any open external references to addresses outside the common memory pool which point to modules located in other common memory pools or nonprivileged subsystems in class 5/6 memory. These CSECTs and ENTRYs are not found. Moreover, open external references must only point to shared code located at the same address for all tasks. See also the DSSM manuals.