. Segment 1 of storage contains
the reentrant code for the CMS Nucleus routines. In shared CMS systems, this is the which =ust consist only of reentrant code, and may not be modified under any circumstances.
Thus, such functions as DEBUG breakpoints or CP address stops cannot
be placed in Segment 1 when it is a protected segment in a saved
system. Area (X'20000' !Q User programs are
loaded into this-area--by the LOAD command. Storage allocated by
means of the GETMAIN macro instruction is taken from this area,
starting from the high address of the user program. In addition,
this storage area can be allocated from the top down by DMSFREE, if
there is not enough storage available in the low DMSFREE storage
area. Thus, the usable size of the user program area is reduced by th9 amount of free storage that has been allocated from it by DMSFREE. (!Q£ 21 The top of storage is occupied
by the loader tables, which are required by the CMS loader. These
tables indicate which modules are currently loaded in the user
program area (and the transient program area after a LOAD command).
The size of the loader tables can be varied by the SET LDRTBLS command. However, to successfully change the size of the loader
tables, the SET LDRTBLS command must be issued immediately after IPL. Free Storage Management
Free storage can be allocated by issuing the GE!MAIN or DMSFREE macros. Storage allocated by the GETMAIN macro is taken from the user program
area, beginning after the high address of the user program. Storage allocated by the DMSFREE macro can be taken from several
If possible, DMSFREE requests are allocated from the low address free
storage area. Otherwise, DMSFREE requests are satisfied from the
storage above the user program area.
There are two types of DMSFREE requests for free storage: requests
for USER storage and NUCLEUS storage. Because these two types of
storage are kept in separate 4K pages, it is possible for storage of one
type to be available in low storage, while no storage of the other type
is available.
Part 3. Conversational Monitor System (CMS) 243
GETMAIN FREE STORAGE MANAGEMENT All GETMAIN storage is allocated in the user program area, starting
after the end of the user's actual program. Allocation begins at the
location pointed to by the NUCON pointer 8AINSTRT. The location
MAINHIGH in NUCON is the "high extend" pointer for GETMAIN storage.
Before issuing any GETM!IN macros, user programs must use the STRINI! macro to set up user free storage pointers. The STRINIT macro is issued
only once, preceding the initial GETMAIN request. The format of the STRINIT macro is:
[label] I r r "1' STRINIT I II I I IBALRII ILL JJ r "1 I IBALRI L ..J indicates how control is passed to DMSSTG, the routine that
processes the STRINIT macro. Since DMSSTG is a
nucleus-resident routine, other nucleus-resident routines can
branch directly to it ( TYPCALL=BALR) while routines that are
not must use linkage SVC (TYPCALL=SVC). If no
operands are specified, the default is TYPCALL=SVC. When the STRINIT macro is executed, both MAINSTRT and MAINHIGH are
initialized to the end of the user's program, in the user program area.
As storage is allocated from the user program area to satisfy GETMAIN requests, the MAINHIGH pointer is adjusted upward. Such adjustments
are always in multiples of doublewords, so that this pointer is always
on a doubleword boundary. As the allocated storage is released, the MAINHIGH pointer is adjusted downward.
The pointer MAINHIGH can never be higher than FREELOWE, the "low extend" pointer for DMSFREE storage allocated in the user program area.
If a GETMAIN request cannot be satisfied without extending MAINHIGH above FREELOWE, then GETMAIN will take an error exit, indicating that
insufficient storage is available to satisfy the request.
The area between MAINSTRT and MAINHIGH may contain tlocks of storage
that are not allocated and that are, therefore, available for allocation
by a GETMAIN instruction. These blocks are chained together, with the
first one pointed to by the NUCON location MAINS!RT. Refer to Figure 21
for a description of CMS virtual storage usage. 244 IBM VM/370 System Programmer's Guide
Previous Page Next Page