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
00Log-in allowed
01 ) Log-in allowed if Δ = 0. Otherwise log-in in restricted mode only *
10 )
11Log-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 :

  1. non-priority user
  2. logged-in in free mode
  3. has used most comp.time this shift

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.

  1. when a user logs in
  2. when a user logs out
  3. when a SST4 buffer is full, or when a preset time expires, whichever comes first.

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:
MAFOne entry per job number. Records time used with back-memory of last 13 weeks and last 3 quarters. Includes name, address department etc.
WLFAccumulates records for the current week; one entry per job number. No names etc.
CSLLike the weekly log, but accumulates information only for the current shift. May turn out to be redundant.
AUFOne 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.
AFOne entry for each authorised console user. Includes:
  1. Allocations of space-time, comp time and exce time for each shift.
  2. Maximum comp time, exec time and store in any one shift, (may be different for each shift).
  3. Privileges, priority status, etc.
  4. Which group the user belongs to.
  5. Whether user is stricted to particular consoles.
  6. Whether user is 'special' e.g. administration.
  7. Disc allocations.
  8. Space time, comp time and exec time left in each shift.
  9. Anything else relevant such as Password.


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.

  1. It collects the information about each job and updates the CSF. For console jobs it also debits the "time left" in the AUF.
  2. It computes the load factor and takes action accordingly, setting switches if log-in is to be restricted, and initiating an automatic log-out if one is called for.

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:

  1. if log-in is absolutely forbidden (severe overload) type FULL LOADED - TRY AGAIN LATER, otherwise send WRU, read answer-back,type READY and wait for number.
  2. find entry in allocations file. If no entry type NUMBER UNKNOWN and kill.
  3. if necessary check console number and send error message in unsatisfactory (e.g. administrative control is limited to certain consoles)
  4. type PASSWORD, send type-head to right and await password. If it is wrong, type PASSWORD UNKNOWN and kill.
  5. Check that the time left in this shift is >0, message if not.
  6. If user is in class "RESTRICTED" set log-in mode as "RESTRICTED" and go to (x1).
  7. If no overload, set log in mode to "FREE" and go to (x1).
  8. If overload and non-priority user, set log-in mode to "RESTRICTED" and go to (x1).
  9. If overload and priority user, type "DO YOU WANT FREE MODE?" Set log-in status according to reply, and if reply is YES, make a note to log someone else out.
  10. If non-priority user and mode "FREE", check whether user has a background job running. If so, set mode to "RESTRICTED".
  11. Set mode in command control program (i.e. indicate which commands may be used). Send title to SST4 for logging purposes. Send title to Supervisor (for output indentification). Set limstore and limout. Set comp and exec times as max. in this shift or time left in this shift, whichever is smaller.
  12. Type
          LOGGED IN FREE        MODE  DATE  TIME
    TIME LEFT IN THIS SHIFT IS    __________
  13. Make entry in AUF.
  14. Enter command switching program

5.2.4 LOG-OUT

Log-out occurs in respone to command, when time/store limits are exceeded, or possibly when the system is overloaded. Mechanism is :

  1. Update AF from AUF
  2. Type    LOGGED  OUT  DATE  TIME
  3. Set console dormant status
  4. Enter filemaster.


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

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.

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

Contact: CUCPS Committee (
This HTML version last updated: $Date: 1999/06/11 20:18:36 $