2.0 OBJECTIVES OF A NEW OPERATING SYSTEM
Designing a new operating system implicitly asks the question, “What is wrong with the ones we have?” Operating systems have been doing the same sorts of things for years, or apparently so.
The first answer usually is “It doesn’t do exactly what we want.” Experience has shown that major problems appear when a computer system is asked to do something differently than it used to.
Unfortunately, small changes to a few routines rarely provide a solution.
Commercial time-sharing has been a reality for four years now.
As the industry grew the requirements of operating systems grew with it; we are now very close to the position where the old software architecture can no longer support the demands for change.
A new, more modern approach is required.
The objectives of this approach are discussed in the following sections.
2.1 Breaking the Development Logjam
Operating system changes are generally of the most devastating nature.
First, the number of people capable of working on the operating system effectively is almost vanishingly small because of their complexity.
Second, even small changes sometimes have disastrous effects on users who neither knew nor cared about the change.
Third, the debugging tools at hand for system people are not as sophisticated as those at the disposal of other programmers unless the system is already running pretty well.
Dedicated access to the computer generally applies a number of further constraints, and all these factors tend to lengthen development and acceptance cycles.
Development time is also subject to other constraints.
According to some theories, the optimal size of a programming project is something one or two people can do in less than six months.
If more time is required no one remembers the original objectives.
If more people are required they generally develop internal communications problems resulting in long delays.
Operating system projects have typically been massive efforts taking several years, almost out of control for most of the time.
One of the prime objectives of the design of the New System is the elimination of artificial bottlenecks in the development process.
The core system is designed to provide the minimum of services required for the system to function effectively.
This is emphatically not to say that the ultimate product will be a stripped-down system.
The objective is rather to allow designers at the user mode level to create and package those services they wish in the most useful way.
Descriptions of command languages, file system calls and subsystems will all be added later.
The virtue of the system design is that all these things can be decided upon while the basic monitor is being implemented.
The problem is that these services have to be designed and programmed before the system is complete; the amount of effort involved here should not be underestimated.
It is hoped, however, that the system design described will allow more people to start this job sooner than would otherwise be the case.
2.2 Specific Objectives of the New System
Turning from these general considerations of system flexibility we can list a number of other desirable system features.
Most of them provide mechanisms that will be crucial to the growth of time-sharing and Tymshare in the computer services industry.
2.2.1. Emulate Operating Systems
Time-sharing is the best way to debug almost any program.
It is of considerable practical advantage to allow systems programmers to debug new versions of the operating system by simulating the effects of privileged operations and letting the rest of the system run normally.
The basic requirement for this is for one program to have absolute control over the traps or unusual conditions produced by another.
2.2.2 Simulate Obsolete Monitor Environments
Considerable software is generated by computer manufacturers and others which often cannot be used without extensive revision because it was written to be executed under a different monitor system.
A program which can intercept and interpret another’s monitor calls can provide the necessary insulation to allow the foreign program to execute.
This may not be a desirable long term mode of operation, but it supplies an interim means to utilize foreign software.
2.2.3 Provide Multiple Executive Modes
Most time-sharing systems have, in the past, concentrated on the development of the “best” command structure or executive features because only one was possible.
A system should provide alternative executive structures for different purposes and different users.
2.2.4 Allow Wider variety of Program Types
Many of Tymshare’s long run objectives require more diverse types of program activity than is currently possible on current systems: detached processes, batch execution and programs serving multiple terminals are several categories in which interest is already high.
2.2.5 Allow Checkpointing of User Tasks
Handling of telephone disconnects and orderly system shutdown procedures need a mechanism for suspending a user task in such a way that it can be restarted as if nothing had happened.
With this capability a user can start a computation that will run (in batch mode, obviously) for several days, without being concerned about crashes or scheduled down-time.
2.2.6 Provide Protection to Users and Vendors of Proprietary Software
Techniques have been developed to protect Tymshare’s software from being stolen by its users.
Similar protection needs to be extended to the users and vendors of software for which Tymshare provides a vehicle.
The right for a program to be secure from theft has been recognized in many systems.
The right for a user’s data given to a proprietary program to be similarly secure is a problem not yet generally recognized.
2.2.7 Allow Sharing of Programs or Data
The 940 and other systems allow certain classes (subsystems) of programs to be shared; sharing of input data files is also
possible.
These capabilities need to be extended to make almost any program or package sharable, as well as to share data files used in update mode.
2.2.8 Provide an independent Program Unit
A mechanism for packaging a program in a form usable by others as an independent self-contained unit must exist.
An example is the 940 Library GO-TO program.
This form is unduly restrictive, however: it must be called stand-alone from the EXEC and can only communicate with other programs through files.
A similar mechanism under program control would provide extensive flexibility for new program packages.
2.2.9 Allow Parallel Operation of Program Versions
Development and quality control functions are currently severely handicapped because of the necessity of having one and only one copy of a given program available to users.
Software changes and gradual conversion would be greatly facilitated by the ability to have new and old versions of a program available to different users simultaneously without changing user procedures.
2.2.10 Provide Selective Distribution of Privileged Capabilities
Most systems have a few broad status categories to which privileged functions are assigned. Inevitably the need arises to allow a user to access one element of a class but not the others.
A mechanism for identifying individual capabilities and distributing them without undue overhead is needed.
A similar problem exists for files and file directories.
2.2.11 Provide a Flexible Means for Controlling Usage
Many companies and users have a common problem with time-sharing: positively controlling the expenses incurred by run away programs or programmers.
When programs are allowed to run in batch or detached modes, some facility must be provided to ensure that they are stopped after exceeding specified usage limits.
2.2.12 Provide a More Efficient Tymnet Interface
Simulation of the functions of the CTE equipment was a convenient way to implement Tymnet; this method, however, is inefficient both for the 940 and for Tymnet.
A new scheme would provide more effective use of both resources on the flew System.
In particular, high speed terminals make a low overhead interface mandatory.