Free Storage Management
Free storage can be allocated by issuing the GETMAIN 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 areas.
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 stor­
age, while no storage of the other type is available.
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 MAINSTRT. The location MAINHIGH in NUCON is the "high extend" pointer for GETMAIN storage.
The STRINIT function initializes pointers used by CMS for simulation of OS GETMAIN/FREEMAIN storage management. In the usual CMS environment,
that is, when execution is initiated by the LOAD and START commands, CMS calls the STRINIT macro as part of the LOAD preparation for execution. In an OS environment established by CMS, such as OSRUN, the STRINIT function has
been performed by CMS and should not be done by the user program. In any case,
the STRINIT macro should be issued only once in the OS environment, preceding
the initial GETMAIN request. The format of the STRINIT macro is:
[label]
where: TYPCALL= [SVC J
BALR.
STRINIT
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 nucleus-resident must use linkage SVC (TYPCALL=SVC). If no operands are specified, the default is TYPECALL=SVC. When the STRINIT macro is executed, both MAINSTRT and MAINHIGH are ini­
tialized to the end of the user's program, in the user program area. The end of the
user's program is the upper boundary of the load module created by the CMS LOAD and INCLUDE commands. This upper boundary value is stored in the NUCON field LOCCNT. When execution of the user's program is started and the
Functional Infonnation 323

and MAINHIGH. During execution of the user's program the LOCCNT field is
used within CMS to pass starting and ending addresses of files loaded by OS simu­
lation (see Notes below). As storage is allocated from the user program area to sat­
isfy GETMAIN requests, the MAINHIGH pointer is adjusted upward. Such
adjustments are always in multiples of doublewords, so that this pointer is always
on a doubleheader boundary. As the allocated storage is returned, 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 takes an error exit, indicating that insufficient storage is available
to satisfy the request.
The area between MAINSTRT and MAINHIGH 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 MAINLIST. Refer to Figure 35, Figure 36 ,
and Figure 37 for a description of CMS virtual storage usage.
Notes:
1. Reissuing the STRINIT macro during execution of an OS program, or issuing
the STRINIT macro without having done a CMS LOAD is not advised because
the value in LOCCNT will not have been appropriately set, possibly causing a
subsequent storage management failure.
2. A high level language may issue a STRINIT. In this case, a user should not
issue an additional STRINIT.
The format of an element on the GETMAIN free element chain is as follows: I I I FREPTR -- pointer to next free 0(0) element in the chain, or 0 if there is no next element ---------I 1 1------------ FRELEN --length, in bytes, of
4(4) this element ----------I 1--------- ---------- Remainder of this free elem2nt When CMS issues the GETMAIN macro instruction for a variable amount of stor­
age, the following formula determines the amount of storage obtained:
Amount of storage = 6 pages + 1 additional page for each 256K bytes obtained in
excess of 512K bytes.
DMSFREE Free Storage Management
The DMSFREE macro allocates CMS free storage. The format of the DMSFREE
macro is:
324 VM/SP System Programmer's Guide