This document is based on the ideas put forward in PD15, and outlines an initial scheme for the control of on-line jobs which can be extended to cover all jobs. This can of course only be a temporary scheme since at present there is no swapping, and the scheduling algorithm is built into the Supervisor. This is the reason for some of the features which would be unsatisfactory in a permanent system. Initially there will be no priority users or forcible log-out, and no direct means of ensuring a constant ratio of on-line to background time; this will allow experiment with the other restrictions to see what effect they have on the foreground/background ratio.
The load will be controlled by imposing limits on the total numbers of users and number of users in free mode, and also a restriction on the sum of the current limstores (ignoring users in restricted mode). Restricted mode can be taken to include all the common system commands which use up to 2K words, but this list must not become too large or else there will be many short programs nearly always in core with a serious cumulative effect. Some users (perhaps most) will be restricted, and those in free mode will normally be allotted a maximum limstore of about 8K words except in exceptionally deserving cases. (8K is sufficient for a reasonably sized Autocode program.) Users requiring more store will usually have to wait (except at night), and so part of the log-in program will deal with requests for more store and perhaps queue them. Because of this, and the desirability of combining the log-in and log-out programs, the whole program will be a system (called CONTROL) which has the privileges to set COMP, EXEC and LIMSTORE etc., and access the accounting files.
At the moment the limiting factors for on-line working are the amount of time a program spends in core and the space it occupies. In other words, we can tolerate a large program for a relatively short real time or a small program for rather longer. The best measure of this is EXEC X STORE, but unfortunately we can only measure this directly after the event from the information in Supervisor Stream 4. There are various ways this could be measured, such as an entry to the accounting routine from the end-phase extracode, or a resource allowance which the Supervisor decrements automatically, forcing a monitor when it has expired. However, these involve changes to the Supervisor which could not be implemented in a hurry, and granted the present arrangements the most satisfactory way of dealing with this problem is to have an EXEC time which is dynamically dependent on LIMSTORE. Each time a user wishes to change his LIMSTORE he enters the accounting routine (CONTROL) and uses a LIMSTORE or RESTRICTED command. According to the load on the system his request may or may not be granted, but he may have several tries if he thinks he can manage with less, or do some useful editing in the mean-time. (He might, for example, have a variable size buffer which can be changed by setting a parameter to fit in with the requirements.) In a more sophisticated system he could ask to be put on a queue of on-line jobs awaiting space and notified when it is available, or there is no point in waiting any longer because of an overload. When the user asks for a new LIMSTORE or logs out, the EXEC time remaining is re-adjusted by multiplying by the previous LIMSTORE in blocks. If his request is granted he will be allotted a new EXEC time corresponding to the remainder of the allocation divided by the LIMSTORE in blocks. Restricted mode is treated as if the LIMSTORE were one block, though in fact it is 2K words. This allows for the economy gained from much used pure procedures. The EXEC allocations mentioned hereafter refer to the time allowed in restricted mode and are adjusted as above for free mode.
<carriage return> USER JMHH208/TITLE XXXXXXXX (password - see below) (DATE xx.xx.xx TIME xx.xx.xx <message of the day> (RESTRICTED MODE ( or (LIMSTORE m COMP xx.xx EXEC xx.xx
Two attempts each are allowed at the user identification and the password. After reading the user identification, the program puts out 8 superimposed H, I and X terminated by a carriage return over which the user types his password. If the user and his password are recognised and his time has not expired he will be told the maximum store and time he is allowed. He may then use any of the following commands which may also be obeyed whenever he has entered CONTROL:
|PASSWORD||Sets the first 8
characters on the following line to be the new password.
The use of a password is optional, but if one is not used someone malicious may set a password unknown to the user and he will be unable to log in until the administration has rectified this.
|RESTRICTED||Sets restricted mode.|
|LIMSTORE m||Sets new limstore.
To either of these the system will respond NO or type the new value of COMP and EXEC, the latter being inverseley proportional to the LIMSTORE.
These may be repeated indefinitely.
|Set new limit of xx minutes yy seconds which is less than the maximum. This saves users from using all their allowance by accident.|
|FINISH||Initiates log-out and types FINISHED TIME xx.xx.xx when this is completed. This command is also recognised by the command switching program.|
|@ A||Enters command program.|
|Privileged commands which may only be used by the user called CONTROL.|
|MAXSTORE m||Maximum total allocation to free mode jobs.|
|MAXLIM n||Maximum individual allocation to free mode jobs.|
|MAXFREE n||Maximum number of free mode users.|
|MAXUSERS n||Maximum total number of users.|
|Updates table. If entry for name exists then replaces it by new entry with details of COMP, EXEC, LIMSTORE and privileges.|
This set of privileged commands is only a very tentative suggestion of the sort of means that might be used to control and experiment with the operation of the system on-line. The latter four commands could all be implemented instead by using the filing system directly but it might be desirable to have a format that operators could use and is easy to remember.
Because of the delay in the production of Supervisor Stream 4 and difficulty of allowing an O.P. to get at this, it is difficult at present to use it for up-to-the-minute logging information which is required for on-line jobs. This can conveniently be done with a file containing remaining COMP and EXEC time and LIMSTORE which is read at log-in and updated at log-out. This will stop anyone using more than his allocation, whereas with information from SS4 can only be used to tell the Administration when it has already happened, which is too late for on-line jobs. The information needed will be stored in the UAF, which initially will only contain on-line users, as follows:
|1wd||comp time left today and allowance per day|
|1wd||exec time left today and allowance per day|
|½wd||date this file was last updated|
|also privileges priority group etc., as necessary.|
I have envisaged a daily shift with rationing between different times in the day depending on supply and demand, particularly for core space rather than time. This can be changed by replacing the date with a shift number. The SS4 paper tapes are fed in as convenient with a suitable standard JD on the front. These update the WLF which contains name and amount of COMP and EXEC time remaining. If this becomes negative a message is printed warning the Administration of this fact and the amount is debited from the next week's allowance. At weekly intervals this is used to update the MAF, print out a summary of the week's usage and compile statistics. Thus violation of the daily totals will stop a job running whereas violation of the weekly totals will only stop the user running any more jobs that week and will not affect the current job. This separation of immediate control using the UAF, and long term control using the WLF and MAF enables these two sections to be written and changed separately. This is particularly important for the latter,which will be changed when Supervisor Stream 4 can be read directly, and when new sets of statistics are required. It also enables the minimum amount of filed information to be accessed and changed at run time.
1 November 1966
There is also a supplement to this document, Logging in and Control : System 1 by JMHH, dated 4.2.67.
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: 20. Command Control
Program - Proposals, DFH, 21.10.66 (plus supplement, DFH, 1 November 1966)
Next Planning Document: 22. Job Scheduling, BL, 21.11.66
Return to Cambridge Supervisor Planning Documents
Return to CUCPS TITAN page
Return to CUCPS home page
Return to University of Cambridge home page