User programs are
loaded into this area by the LOAD command. Storage allocated by means of the GET"AIN 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 DftSFREE, if
there is not enough storage available in the low DftSFREE storage
area. Thus, the usable size of the user program area is reduced by the amount of free storage that has been allocated from it by DftSFREE. 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 co.mand must be issued immediately after 1PL.
Free Storage Management
Free storage can be allocated by issuing the GETft!II or DftSFREE macros. Storage allocated by the GETft!IN macro is taken from the user program area, beginning after the high address of the user program. Storage allocated by the DftSFREE macro can be taken from several
areas.
If possible, DftSFREE 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 DftSFREE requests for free storage: requests
for USER storage and BUCLEUS 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. GETftAIN FREE STORAGE ftANAGEftENT All GET"AIN 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 BUCON pointer ftAINSTRT. The location ftA1NHIGB in NUCON is the "high extend" pointer for GET!AIN storage.
Before issuing any GETft!IN macros, user programs must use the STRIIIT macro to set up user free storage pointers. The STRIIIT macro is issued
only once, preceding the initial GETftAII request. The format of the
STRINIT macro is: I r r,'
[label] STRIIIT I ITYPC!LL=ISVC II I ILL .I.J
2-14 IBft VM/370 System Logic and Program Determination--Volume 2
1 I I I I
r , TIPCALL=I.§!£ I IBALRI L .J
indicates how control is passed to DESSTG, 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 nucleus-resident must use linkage SYC (TIPCALL=SYC). 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 GET MAIN 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 MAIN HIGH 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 may contain blocks 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 MAINSTRT. Refer to Figure 3
for a description of CMS virtual storage usage.
The format of an element on the GETMAIN free element chain is as
follows: .- 1 I I FREPTR -- pointer to next free
o (0) I eleme nt in the chain I or 0 I if there is no next element I I 'I I I FRELEN --length, in bytes, of
4 (4) I this element I I I I 1------- I Remainder of this free element When issuing a variable-length GETMAIN, two and one-half pages are
reserved for CMS usage; this is a design value. A user who needs
additional reserved pages (for example, for larger directories) should
free up some of the variable GETMAIN storage from the high end. eMS Introduction 2-15
Previous Page Next Page