This document outlines a scheme for accounting and control within the on-line system. It is planned with the ultimate intention of extension to include the job-shop work as well: in the first instance accounting will include all jobs, but control will apply only to console jobs.
There are two modes of use of the system, restricted and free. In restricted mode the user may input, edit and manipulate files, but may not initiate jobs.
There are three classes of user, priority, primary and secondary. A secondary user is one who is only allowed to log-in in restricted mode. A primary user may log-in (subject to system loading) in free or restricted mode, except that if he has a background job running at the time he tries to log-in he will only be allowed on the system in restricted mode. (Thus he can initiate a job from his console, and then carry on editing). A priority user can log-in in free mode even though he may have a background job running, and is given preferential treatment when the system becomes overloaded. The number of priority users must be strictly limited.
The first level of control is deciding whether a user may log-in, and if so in which mode. However, we defer that question for the present, and consider the control of a user once logged in. Before a user is allowed to start we may set :
| (i) | comp. time | (i.e. processor time) |
| (ii) | exec time | (i.e. console time) |
| (iii) | limstore | (i.e. maximum core allocation) |
| (iv) | limout | (i.e. maximum disc allocation excluding files) |
For control purposes the day is divided into a number of shifts. The exact division does not concern us here. Allocations of time, core-space, etc made to users are split between the shifts so that the load can be spread over the computing day. For example, a student might be allocated a small amount of time at peak period, but a much larger time in the late evening and night. There is no reason why the class of a user should not also vary between shifts, e.g. restricted during the day and free at night.
A further measure of control is obtained by specifying for a user not only his total allocation of time etc., but also a limit on what he may use in any one shift. For example,a user might be allocated 300 minutes of comp. time in the day shift, with a limitation to 5 minutes in any one day. This sort of limitation con apply to console time and store allocation as well. Applied to console time it shares out the use of a console. Applied to store, it gives a way of allowing conversational programming without letting it get out of hand.
Define the load factor L as the ratio of comp. time used by console jobs to total comp.time. From time to time the administration will specify a permitted maximum for L, Lmax say. The system endeavours to keep L ≤ Lmax by automatically controlling the number of users logged-in. It is essential that this control should be stable, and therefore a temporary overload must be permitted. Suppose for the moment that the system computes L at regular intervals of T minutes (i.e. every T minutes L is calculated for the previous T minutes. T = 10 is the sort of interval in mind). Then for each period we can have an overload indicator δ, which is 1 if L > Lmax and 0 otherwise. In additon we can compute the load factor for the total time so far in the shift, and the corresponding overload indicated Δ. Suppose we retain a cyclic record of δ for the last two intervals, δ-1 and δ-2. A possible algorithm for control of logging-in is given below :
| δ-2 δ-1 | ||
| 00 | Log-in allowed | |
| 01 | ) | Log-in allowed if Δ = 0. Otherwise log-in in restricted mode only * |
| 10 | ) | |
| 11 | Log-in in restricted mode allowed * if Δ = 0. Otherwise log-in refused * |
* A priority user can log-in in free mode if he insists, but someone else will be logged out.
If Δ = 1 for two consecutive periods, the system will log-out somebody. The simplest strategy is to find the user who satisfies the following conditions :
If no user can be found to satisfy these conditions then condition (b) is relaxed. If no user can be found even then, condition (a) is relaxed. The mechanism of forcible log-out needs thought: it would be desirable to give a few seconds' warning.
A possible elaboration is to divide users into groups and to cycle round the groups when forcibly logging-out. (e.g. if a user in group 1 is forcibly logged-out, this group will be the last to be examined when looking for the next candidate for oblivion.) The group system is particularly attractive when it is necessary to log someone out in order to let a priority user in. In this case the system would log-out someone from the same group as the priority user wanting to get in.
It is imperative to avoid the situation where a user has to keep trying to log-in. If a non-restricted user is refused access, he will be allowed to request a call. His console number will be entered in a queue, and when logging-in was again possible a message will be sent to the console.
It is convenient to interpolate here a description of the present method of logging. The supervisor generates a stream hereafter referred to as SST4 which includes for each phase of each job comp time, exec time and store used. Because of multi-programming entries for many jobs are intermingled. SST4 is punched out either on demand by the operators, or when the buffer is full. The output tapes for a week are processed by a program which extracts the necessary data and produces a paper tape suitable for input to the main logging program. This maintains a file on magnetic tape, and prints a weekly cumulative log.
Console system control (CSC) is a collection of programs which is activated.
Before entry (iii), the supervisor dresses up SST4 as an honest stream or file.
Associated with CSC are various files. These are
| (i) | Main Accounting File | (MAF) |
| (ii) | Current Shift Log | (CSL) |
| (iii) | Allocation File | (AF) |
| (iv) | Active Users File | (AUF) |
| (v) | Weekly log File | (WLF) |
Briefly,these files are made up as follows:
| MAF | One entry per job number. Records time used with back-memory of last 13 weeks and last 3 quarters. Includes name, address department etc. |
| WLF | Accumulates records for the current week; one entry per job number. No names etc. |
| CSL | Like the weekly log, but accumulates information only for the current shift. May turn out to be redundant. |
| AUF | One entry for each console user currently active. Records his status (e.g. priority), his group, and keeps a running count of how much time he has left. |
| AF | One entry for each
authorised console user. Includes:
|
When a user logs in (see below) the allocation file is read and an entry is made in the AUF which includes his "time left",
When CSC is called on the timed-basis (or when the SST4 buffer is full) it does two things.
When a user logs out, his "time left" is transferred from the AUF to the AF.
At the end of the shift any users still logged in are forcibly logged out, and the CSF is merged into the weekly log.
Once a week the MAF is updated from the WLF. At any time the administration can interrogate the WLF and the MAF.
The user signifies that he want to log-in by typing a specified character at a otherwise dormant console. This takes him directly into the log-in program. Action is now as follows:
LOGGED IN FREE MODE DATE TIME
RESTRICTED
TIME LEFT IN THIS SHIFT IS __________
CONSOLE TIME IN THIS SHIFT IS _________
MESSAGE OF THE DAY
READY
Log-out occurs in respone to command, when time/store limits are exceeded, or possibly when the system is overloaded. Mechanism is :
A user can detach his console from a job by issuing the appropriate command. The job then runs as any other background job. When the user does this, he is immediately logged out by the system. He cannot log-in again in free mode until his background job has finished; he may however, log-in in restricted mode (system loading permitting).
It is not clear to what extent the use of peripherals by console jobs should be discouraged. Should one, for example, make it impossible to create a stream for the plotter other than in the Job Description ?
We have talked above of allocations of time and space-time. In order to encourage the sort of programs that suit the system best, we should allocate "RESOURCE UNITS". One way of calculating units is as follows :
RU = ∑i (αCi + βEi + γSi) + hM
where
| Ci | = | comp time | ) | for the ith phase |
| Ei | = | exec time | ) | |
| ) | ||||
| Si | = | product space X time | ) | |
| M | = | maximum store used at any stage of the job. | ||
α, β, γ, h are numerical constants, and the summation is taken over all the phases of the job.
A similar concept can be applied to disc space, e.g. files which are not preserved on magnetic tape are "cheaper" than those that are.
DWB
August 1966.
Copyright © 1966 University of Cambridge Computer Laboratory. Distributed by permission. Thanks to Barry Landy, Roger Needham and David Hartley for giving permission to distribute these documents. Thanks to Barry Landy for lending me the paper document from which this was scanned. Any typographical errors probably arose in the course of OCR.
Previous Planning Document: 14. File Storage and
Protection, AGF, August 1966
Next Planning Document: 16. Commands and Job
Organisation, AGF, 12 September 1966
Return to Cambridge Supervisor Planning Documents
Return to CUCPS TITAN page
Return to CUCPS home page
Return to University of Cambridge home page