Virtual Virtual , Symbolic
IBM Device Address
1 , Name Device Type 3210, 3215, 1052, ccu CON1 System console 3066, 3270 2314, 3330, 3340 190 DSKO System disk (read-only) 3350 "...,.4 .. 3330, 3340 191
2 DSK1 Primary disk (user files) 3350 2314, 2319, 3330, ccu DSK2 Disk (user files) 3340, 3350 ') 1/1 ').,10 .,.,.,n ccU DSK3 Disk (user files) £..J 1 ." JJJV, 3340, 3350 2314, 2319, 3330, 192 DSK4 Disk (user files) 3340, 3350 2314, 2319, 3330, ccu DSK5 Disk (user files) 3340, 3350 2314, 2319, 3330, ccu DSK6 Disk (user files) 3340, 3350 2314, 2319, 3330, ccu DSK7 Disk (user files) 3340, 3350 2314, 2319, 3330, 19E DSK8 Disk (user files) 3340, 3350 2314, 2319, 3330, ccu DSK9 Disk (user files) 3340, 3350 1403, 3203, 3211 OOE PRN1 Line printer
1443 2540, 2501, 3505 OOC RDR1 Card reader 2540, 3525 OOD PCH1 Card punch
2415, 2420, 3410, 181-4 TAP1-TAP4 Tape drives 3420 lThe device addresses shown are those that are preassembled into the CMS resident device table. These need only be modified and a new
device table made resident to change the addresses.
2The virtual device address (ccu) of a disk for user files can be
any valid System/370 device address, and can be specified by the CMS user when he activates a disk. If the user does not activate
a disk immediately after loading eMS, eMS automatically activates
the primary disk at virtual address 191.
Figure 26. Devices Supported by a CMS Virtual Machine , , I I I , , I , I • Transient 12 • Since it is not essentIal to keep all nucleus functions resident in storage all the
time, some of them are made "transient." This means that when they
are needed, they are loaded from the disk into the transient program
area. Such programs may not be longer than two because that
is the size of the transient area. (A page is 4096 bytes of virtual
storage.) All transient routines must be serially reusable since
they are not read in each time they are needed.
242 IBM VM/370 System programmer's Guide

• . 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
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 storage, while no storage of the other type
is available.
Part 3. Conversational Monitor System (CMS) 243