previous | contents | next


Batch Processing

Batch processing has evolved from the original, fully interactive PDP-6. where a user was expected to interactively provide commands for each step in the generation/execution of a program. The first batch on the KA10 was based on a user-built command file that mimicked his terminal actions. The user invoked this command file to execute his programs. Later, a multiprogrammed batch system was added, and the job control syntax evolved to provide more functions per command. However, batch/ interactive command commonality has been preserved through the current Monitor versions. Still, batch control ran as a timeshared job using queued batch control files. Thus, the ability to log in a job, run to completion, and log off is accomplished from a card reader or any other storage or file device. Symbiant (queued) operation allowed control of card readers, line printers, etc., by the batch control program so that the machine could be scheduled more effectively. During this batch evolution, little Monitor enhancement was necessary to specifically address the batch environment. Modules to improve efficiency (by multiple strands and better scheduling) and increase functionality were implemented as "user" jobs and interprocess queuing allowed communication between the "user" modules.

A line printer spooler, for example, was run as one of many jobs by the operator - a notion that evolved beginning with the KA10. If a special form was required for a print job, the operator would be notified and act accordingly. The user was relieved of this responsibility. Operator allocation, control, and media loading of the card reader, magnetic tape, private disk pack, DECtape, and plotter were provided in the KI10.

Terminal Handling and Communications.

We believe the users' perception of system effectiveness related directly to his feeling that he was interacting and was in control. The requirement to communicate effectively with the user via the terminal was one of the most difficult design constraints. The very first version of the Monitor used half-duplex communication for simplicity. But finally we decided to pay the additional price to gain the benefit of full-duplex communication i.e., being able to continuously input and output independently of system load. These philosophies have guided subsequent Monitor generations.

A hardware module was constructed to facilitate terminal communication. This hardware was called the scanner because it looked at all the interface lines connected to Teletypes and interrupted the software when a character was received or needed to be transmitted. These line units, which we built on a single card, formed the basis of the Universal Asynchronous Receiver/Transmitter (UART) LSI chip. A soft ware monitor, called Scanner Service (SCNSER) handled interrupts from the hard ware. SCNSER provided the important function of logically coupling a physical terminal with a job running under timesharing. The user was never burdened with attempting to relate his terminal with his job. This software module, by far the most logical complex part of the Monitor, has been rewritten twice to increase terminal functionality.

Later, the KA10 terminal interface was implemented via a "front-end" concentrator PDP-8 computer for large numbers of terminals - particularly where variable line speeds were involved (up to 300 baud). This implementation allowed some off-loading of the processor. Characters were assembled (serial parallel conversion) in the front-end PDP-8 and communicated with the KA10 via the I/O Bus on an interrupt basis.

In 1971, a front-end PDP-l 1 provided direct-memory access over the I/O Bus. This connection provided high speed, full-duplex, synchronous communications and was the

previous | contents | next