CS8493-OPERATING SYSTEMS

UNIT-I

Lecture 4:
Evoluation of Operating Systems

Staff Incharge
Mr.R.Prabhu AP/CSE
Evolution of an Operating
Systems?
• Must adapt to hardware upgrades and
new types of hardware. Examples:
– Character vs. graphic terminals
– Introduction of paging hardware
• Must offer new services, e.g., internet
support.
• The need to change the OS on regular
basis place requirements on it’s design:
– modular construction with clean interfaces.
– object oriented methodology.
 Evolution of Operating Systems
• Early Systems (1950)
• Simple Batch Systems (1960)
• Multiprogrammed Batch Systems (1970)
• Time-Sharing and Real-Time Systems (1970)
• Personal/Desktop Computers (1980)
• Multiprocessor Systems (1980)
• Networked/Distributed Systems (1980)
• Web-based Systems (1990)

3 A. Frank - P. Weisberg
Early Systems
• Structure
– Single user system.
– Programmer/User as operator (Open Shop).
– Large machines run from console.
– Paper Tape or Punched cards.

A. Frank - P. Weisberg
 Characteristics of Early Systems
• Early software: Assemblers, Libraries of
common subroutines (I/O, Floating-
point), Device Drivers, Compilers,
Linkers.
• Need significant amount of setup time.
• Extremely slow I/O devices.
• Very low CPU utilization.
• But computer was very secure.

5 A. Frank - P. Weisberg
 Simple Batch Systems
• Use of high-level languages, magnetic tapes.
• Jobs are batched together by type of languages.
• An operator was hired to perform the repetitive
tasks of loading jobs, starting the computer,
and collecting the output (Operator-driven
Shop).
• It was not feasible for
users to inspect memory
or patch programs
directly.
6 A. Frank - P. Weisberg
 Operator-driven Shop

7 A. Frank - P. Weisberg
 Operation of Simple Batch Systems
• The user submits a job (written on cards
or tape) to a computer operator.
• The computer operator place a batch of
several jobs on an input device.
• A special program, the monitor, manages
the execution of each program in the batch.
• Monitor utilities are loaded when needed.
• “Resident monitor” is always in main
memory and available for execution.

8 A. Frank - P. Weisberg
 Idea of Simple Batch Systems
• Reduce setup time by batching similar jobs.
• Alternate execution between user program
and the monitor program.
• Rely on available hardware to
effectively alternate execution from
various parts of memory.
• Use Automatic Job Sequencing – automatically
transfer control from one job when it finishes
to another one.

9 A. Frank - P. Weisberg
 Control Cards (1)
• Problems:
– 1. How does the monitor know about the nature of
the job (e.g., Fortran versus Assembly) or which
program to execute?
– 2. How does the monitor distinguish:
(a) job from job?
(b) data from program?
• Solution: Introduce Job Control
Language (JCL) and control cards.

10 A. Frank - P. Weisberg
 Control Cards (2)
• Special cards that tell the monitor which programs to
run:
$JOB
$FTN
$RUN
$DATA
$END
• Special characters distinguish control cards from data
or program cards:
$ in column 1
// in column 1 and 2
709 in column1

11 A. Frank - P. Weisberg
 Job Control Language
(JCL)
• JCL is the language that provides
$JOB
instructions to the monitor: $FTN
– what compiler to use ...
– what data to use FORTRAN
• Example of job format: ------->> program
...
– $FTN loads the compiler and
$LOAD
transfers control to it. $RUN
– $LOAD loads the object code (in ...
place of compiler). Data
– $RUN transfers control to ...
user program. $END
A. Frank - P. Weisberg 12
Example card deck of a Job

A. Frank - P. Weisberg 13
Another Job/Steps example

A. Frank - P. Weisberg 14
 Effects of Job Control Language
(JCL)
• Each read instruction (in user program)
causes one line of input to be read.
• Causes (OS) input routine to be
invoked:
– checks for not reading a JCL line.
– skip to the next JCL line at completion
of user program.

A. Frank - P. Weisberg 15
Resident Monitor
• Resident Monitor is first rudimentary OS.
• Resident Monitor (Job Sequencer):
– initial control is in monitor.
– loads next program and transfers control to
it.
– when job completes, the control
transfers back to monitor.
– Automatically transfers control from one
job to another, no idle time between
programs. A. Frank - P. Weisberg 16
Resident Monitor Layout

A. Frank - P. Weisberg 17
Resident Monitor Parts
• Parts of resident monitor:
– Control Language Interpreter – responsible
for reading and carrying out instructions
on the cards.
– Loader – loads systems programs
and applications programs into
memory.
– Device drivers – know special
characteristics and properties for each of the
system’s I/O devices.
A. Frank - P. Weisberg 18
 Offline Operation
• Problem:
– Card Reader slow, Printer slow (compared to Tape).
– I/O and CPU could not overlap.
• Solution: Offline Operation (Satellite Computers) –
speed up computation by loading jobs into memory
from tapes while card reading and line printing is
done off-line using smaller machines.

20 A. Frank - P. Weisberg
Main/Offline Computers

A. Frank - P. Weisberg 21
Spooling (1)
• Problem:
– Card reader, Line printer and Tape drives
slow (compared to Disk).
– I/O and CPU could not overlap.
• Solution: Spooling -
– Overlap I/O of one job with the computation
of another job (using double buffering,
DMA, etc).
– Technique is called SPOOLing:
Simultaneous Peripheral Operation On
Line.
A. Frank - P. Weisberg 22
Spooling System Components

A. Frank - P. Weisberg 23
We assumed Uniprogramming until
now
• I/O operations are exceedingly slow
(compared to instruction execution).
• A program containing even a very small
number of I/O operations, will spend most of
its time waiting for them.
• Hence: poor CPU usage when only
one program is present in memory.

A. Frank - P. Weisberg 25
Memory Layout for
Uniprogramming

A. Frank - P. Weisberg 26
Multiprogramming (1)

A. Frank - P. Weisberg 28
Multiprogramming (2)

A. Frank - P. Weisberg 29
 Why Multiprogramming?
• Multiprogramming (also known as
Multitasking) needed for efficiency:
– Single user cannot keep CPU and I/O devices busy
at all times.
– Multiprogramming organizes jobs (code and data)
so CPU always has one to execute.
– A subset of total jobs in system is kept in
memory.
– One job selected and run via job scheduling.
– When it has to wait (for I/O for example), OS
switches to another job.
30 A. Frank - P. Weisberg
Example of Multiprogramming
p1 p2 p3 kernel
I/O
} scheduler
I/O request
device driver {
}
scheduler

Time slice exceeded

} schedulerInterrupt
device driver {
} scheduler
A. Frank - P. Weisberg 31
Components of Multiprogramming

A. Frank - P. Weisberg 32
Requirements for
Multiprogramming
• Hardware support:
– I/O interrupts and DMA controllers
• in order to execute instructions while I/O device is busy.
– Timer interrupts for CPU to gain control.
– Memory management
• several ready-to-run jobs must be kept in memory.
– Memory protection (data and programs).
• Software support from the OS:
– For scheduling (which program is to be run next).
– To manage resource contention.

A. Frank - P. Weisberg 33