THE PROBLEM OF A TIME-SHARING OPERATOR SYSTEM

I have not seen any comprehensive written treatment of the time-sharing problem and have not discussed the problem with anyone who had a complete idea of the problem. This treatment is certainly incomplete and is somewhat off the cuff. The equipment required for time-sharing is the following:

a. Interrogation and display devices (flexowriters are possible but there may be better and cheaper).

b. An interrupt feature on the computer--we'll have it.

c. An exchange to mediate between the computer and the external devices. This is the most substantial engineering problem, but IBM may have solved it.

In general the equipment required for time-sharing is well understood, is being developed for various advanced computers, e.g., Stretch TX2, Metrovich 1010, Edsac 3. I would not be surprised if almost all of it is available with the transistorized 709. However, the time-sharing has been worked out mainly in connection with real-time devices. The programs sharing the computer during any run are assumed to occupy prescribed areas of storage, to be debugged already, and to have been written together as a system. We shall have to deal with a continuously changing population of programs, most of which are erroneous.

The major problems connected with time-sharing during pro- gram development seem to be as follows:

1. Allocating memory automatically between the programs. This requires that programs be assembled in a relocatable form and have a preface that enables the operator program to organize the program, its data, and its use of common subroutines.
2. Recovery from stops and loops. The best solutions to these problems require

   Changing the stop instructions to trap instructions. This is a minor modification to the machine. (At least it will be minor for the 704.)

   Providing a real time alarm clock as an external device.

3. Preventing a bad program from destroying other programs. This could be solved fairly readily with a memory range trap which might not be a feasible modification. Without it, there are pro- gramming solutions which are less satisfactory but should be good enough. These include:

   Translations can be written so that the programs they produce cannot get outside their assigned storage areas. A very minor modification would do this to Fortran.

   Checksums can be used for machine language programs.

   Programming techniques can be encouraged which make destruction of other programs unlikely.

   There is an excessive tendency to worry about this point. The risk can be brought down to the present risk of having a program ruined by operator or machine error.