�ݺ�ߣ

VIRTUAL DEVICES
Motivation
Devices such as card readers, punches, and printers present two serious problems that hamper effective
device utilization.
First, each of the devices perform best when there is a steady, continuous stream of requests at a
specified rate that matches its physical characteristics.
Second, these devices must be dedicated to a single job at a time. Thus, since most jobs perform some
input and output, we would require as many card readers and printers as we have jobs being multi programmed.
Historical solutions
If it were possible to use Direct Access Devices for all input and output. A single DASD can be
efficiently shared and simultaneously used for reading and/or writing data by many jobs as shown in Fig.12.
DASDs provide very high performance rates , especially if the data are blocked , thereby
decreasing the amount of wait time for jobs that require substantial amounts of input/output.
OFFLINE PERIPHERAL OPERATIONS
Fortunately, a solution to this dilemma can be found in the three-step process illustrated in Fig -
13.
At step 1 we use a separate computer whose sole function is to read cards at maximum speed
and record the corresponding information on a DASD.

At step 2 the DASD containing the input recorded by computer 1 is moved over to the main processing
computer.
Finally, at step 3 the output DASD is moved to a third computer that reads the recorded output
at high speed and prints the information on the printers.
The offline peripheral processing technique solved the problems presented earlier, but it also introduced
several new problems in regard to (1) Human intervention, (2) turnaround,
(3) scheduling.
As a result of this batch processing, it was difficult to provide the desired priority scheduling.
DIRECT-COUPLED SYSTEMS
The major drawback to the offline peripheral processing approach was the need to physically
move the output DASDs between the main computer and the peripheral computer.

Fig .14 illustrates a configuration in which the input and output DASDs are physically connected to both
the peripheral computer and the main computer, thus eliminating the need for manual handling. This
configuration is called a Direct-Coupled Systems (DCS).
The directly coupled system approach eliminates most of the problems of offline peripheral
processing. No human intervention is required; there is no “batch processing” turnaround time delay, nor
any scheduling restrictions.
ATTACHED SUPPORT PROCESSOR
Another variation on this approach consists of directly connecting the peripheral and main computers
together via a high-speed connection as in Fig 1.15a. In this configuration the peripheral computer is called an
Attached Support Processor (ASP).
The support processor assumes all responsibility for controlling the input/output peripherals as well
as the input and output DASD. It also performs buffering and blocking. The ASP has the appearance of multiple,
very high-speed card readers and printers (Fig 15b).

The major disadvantages of this ASP approach:
Two or more processors are required, if it is assigned to some tasks, it is possible that one processor may be
idle or underutilized.
Does not necessarily utilize all resources efficiently.
VIRTUAL SYSTEM
In a SPOOLing system, the main computer performs Simultaneous Peripheral Operations On Line
(SPOOL) as illustrated in Fig .16.
These jobs are actually system job rather than user jobs, they are often given special names, such as
“phantoms” or”daemons”.
The jobs that perform the SPOOL functions are special, permanent system jobs, memory
management may handle these jobs in different ways. Finally, efficient blocking, buffering, and I/O
control must be performed to attain good performance.
Design of a SPOOLing System
The SPOOL programs are assumed to be an integral part of the operating system (rather than
“normal” jobs) and perform their own specialized information management. These are typical assumption
of small to medium-scale operating system.
In such systems, there are two special operating system functions (e.g., SVC supervisor
calls) provided:
1Read next input card,
CALL READNEXT(BUFFER)
2Print next output line,
CALL PRINTNEXT(BUFFER)

A general input and output SPOOL system can be subdivided into four components as in Fig .17.
The division of a program into a “call side” and an “interrupt side” is a common occurrence in
handling various devices and operating system functions.
INPUT SPOOL
Two major operations must be performed by the input SPOOL facility:
1)to read physically each input card and store it on a DASD and
2)to provide access to DASD copy of the next input card to the job during execution.
The operation initiated in response to the I/O complete indication from card reader.
This type of operation is called Interrupt driven.
The call side and interrupt side of input SPOOL cannot function independently. DASD is capable of
holding input deck of suitably large size such as 2000 cards.
input: The input deck is still being read.
hold: Input deck has been copied onto the DASD but the corresponding job has not been started yet.
run: The corresponding job is currently running and is reading the input data from the SPOOL area.
RELATIONSHIP BETWEEN SPOOLING AND JOB SCHEDULING
There is a significant relationship between the job scheduler and the SPOOL facility.
The SPOOL table also serves an important database of the job scheduler and is often called the job
queue or job hold list.

1. the reader table maintains information on the status of teach physical card reader and the
corresponding input SPOOL area being used, and
2. the job table maintains information on the status of all jobs currently running
and the corresponding SPOOL area being used as a virtual device.
If DASD is organized as one hundred 80-byte records per track and twenty tracks per cylinder, the
SPOOL table entry designates the cylinder number, and
Track number = card number/20
Record number = remainder [card umber/20]
Thus card 1= (track 0, record 1) on the cylinder, and card 15=(track 1, record
5), etc.
Fig .19a illustrates the algorithm used by the interrupt side of the input SPOOL program.
Fig .19b illustrates the call side of input SPOOL program

�ݺ�ߣ

Operating System - Virtual Device Technology

Recommended

More Related Content

Similar to Operating System - Virtual Device Technology (20)

More from cscprabh (8)

Recently uploaded (20)

Operating System - Virtual Device Technology