NUMBER OF REMOTE BATCH TERMINALS
3.1.4 SYSTEM MANAGEME NT
UTS system management routines perform all of the functions associated with the running of pro-grams and the providing of required system resources. The major functions of UTS system manage-ment are described below.
3.1.4.1 User State Queues
Each user in UTS is associated with a state describing his current activity. Examples of states in-clude LOGGING ON, COMPUTING, and I/O IN PROGRESS. Each user has one (and only one) entry in a state queue which is a list of users in the same state. Twenty-eight such queues are maintained
by
the scheduler. Three subsets of these 28 queues are used to select users for:(1)
swapping in, (2) execution, and (3) swapping out. Results of this structure include:• A flexible manner of establishing user priorities
• Inte
II
i gent selection of users to swap in and outThe queues are also used for entry and use of processors, I/O activities, and waiting for "wake-up" at a preset time.
3.1.4.2 Schedule and Swapping Routines
The UTS scheduler routine performs two major system functions: (1) selection and organization for users to be swapped in and out, and (2) selection of users for ex~cution. The scheduler keeps track of the state of each user as a function of the events reported to it and, based upon this, makes decisions concerning the initiation of swapping and execution at these event times.
Typically, highest priority users residing in core memory are executed first; then, highest priority users residing on the swapping RAD are swapped in, with lowest priority users residing in core memory being swapped out to make room for them.
The swapping RAD acts as a high capacity, low cost extension to core memory and is used to store the overflow of users that cannot fit into core memory. Swapping out is possible for those users
residing in core memory for whom execution is not imminent. Swapping in is required for those users residing on the RAD for whom execution is imminent. Execution can take place only if the user currently resides in core memory. Swapping in can occur only if there is enough unused core space available to fit the user, or if lower priority users can be swapped out to make room for him.
Only one user is swapped in at a time, although several users may be simultaneously swapped out.
All programs are organized into two areas: The procedure (program instructions) area, and the data area. Typically, the procedure area is not modified in the use of a program. During a swap in, the procedure and data are read into core memory. The associated processor is also read in if it does not already reside in core memory. A copy of the procedure and data remain on the swap-ping RAD after the swap in is completed. The procedure is swapped out only if it has been modi-fi ed (e.g., by debugging). The associated processor is'never swapped out. Thus, processors fre-quently remain in core memory even though they are not in use. In the event that a processor is not in use and more room in core memory is required, the processor is wri~ten over.
3.1.4.3
Memory ManagementVirtual memory will consist of 128K words (512K bytes) although physical memory may be larger.
The virtual memory layout within which programmers will structure their programs is shown be-low in the chart.
Monitor Area User Area Special
Data Program Context Data Program Symbol Area
Table
• Monitor Area contains the monitor and its associated tables. The user is denied all access to this area
• User Area contains:
(1)
context, consisting of a job information table (JIT), data control blocks (DCB1s), and buffers (file buffers and coop buffers); (2) Data (some pages are assigned directly to the program while others are assigned dynamically as needed);(3)
program (pro-cedure); and (4) Symbol table• Special Area contains special shared processors (TEL, LOG-ON, DELTA, FOP, and public libraries)
Various buffers are required for the movement of information to and from core memory. These include:
• Terminal I/O buffers which reside in the monitor area
• Fi Ie I/O buffers whi ch reside in the user's context area
• Symbiont (input) buffers which reside in the monitor area
• Coop (symbiont output) buffers, which reside in the user's context area
The recommended core configuration will typically accommodate one batch user and three or four on-line users in core memory simultaneously. In the initial version of UTS, only one batch job wi" be processed at a time. Once a batch job is brought into core memory for execution, there is virtually nothing to distinguish its treatment from that of an on-line job. In particular, the batch job is eligible for swapping along with the on-line jobs. It is possible to modify this treatment of batch jobs by setting the appropriate system parameters (explained in a later section).
The memory map is used to dynamically fragment and relocate programs, data, and processors on a page basis. A given program will be broken up into its constituent pages which will be non-contiguously located in memory (physical memory). However, during the running of the program, the memory map trans lates a II address references so that the program runs as if the pages were con-tiguous (virtual memory).
This translation process is accomplished by a series of map translation registers - one for each page of memory. Each register has an access protection code which defines whether a given page can be written into, read from, or executed by a given user. The map translation registers and access protection code registers are changed whenever a new program is allocated to CPU.
The access codes are:
•
•
•
•
None - no access of any kind permitted Read - read access on Iy
Execute - execute or read access
Write - write, execute, and read permitted
During user execution, the following access protection is in effect:
AREA ACCESS CODE
Mon i tor Area None
User Area
Context - JIT Read
DCB Read
Buffer None
Data Write
Program Execute
Symbol Table Read
Special Area None or Execute
The basic purpose of memory protection is to protect the monitor and resident real time programs.
The memory protection locks and keys are not changed during the running of different programs.
This is in contrast to access protection which is changed every tilT'e a new program is run. Access protection is used to protect one user against another user and to protect a program from storing in its procedure area. Through a combi nati on of memory protecti on and access protection, the UTS system is able to provide all the desired forms of protection.
3.1.4.4
RAD ManagementA UTS configuration will contain one or more Model 7212 High Speed RAD's for swapping storage and storage of the operati ng system.
When a user logs on to the system, space is allocated to him on the swapping RAD. As his page requirements grow during his session, the RAD area necessary to contain him grows into consecu-tive sectors following his initial page, so that the individual user on the RAD is organized for swapping as efficiently as possible.
LAST PAGE
RAD
FIRST PAGE ROTATIONAL DIRECTION
When multiple users are being swapped out, the I/O commands for each user are sorted and chained together so that the end of one user's area is the shortest possible distance from the be-ginning of the next:
I/O COMMAND CHAIN USER NO.3
\~
USER NO.4/
~USERNO.l~USER NO.2 HALT
~---SENSORS
\
USER NO.3 START
" - - USER NO. 4~
USER NO.1
After this chaining is accomplished, a command is issued to the RAD to find where its sensors are located at that time. With this information, the chain of commands is broken and I/O is initiated to the RAD. This procedure reduces latency well below the RAD's 17 millisecond average access time. Similar logic is applied to the swapping in of multiple processors along with a user.
Additional storage is required for symbionts and permanent user programs and files. Typically, a combination of Model
7232
Extended Performance RAD's and Model7242/6
Removable Disk Stor-age systems is used for this purpose. This combination provides the large capacity required for permanent storage.3.1.4.5
Character Oriented Communications (CO C) HandlingOn-line terminal communications in UTS are generally handled by the COC handler. Full support for both full and half duplex terminals is included. Individual terminals are accessed by means of a table translation technique which defines the appropriate character code for that terminal type.
All requests by a user for I/O to or from a terminal are handled through CAL instructions which consist of requests for read, write, and format control.