1Taxonomies, Paradigms, and the Untangling of Terminology

Taxonomies of Processing Modes

Download 210.5 Kb.

Page	3/8
Date	31.07.2017
Size	210.5 Kb.
	#25081

1 2 3 4 5 6 7 8

2Taxonomies of Processing Modes

2.1David N. Freeman Taxonomy (Encyclopedia of Computer Science, 3^rd ed, 1993, “Processing Modes”, pp. 1104ff)

2.1.1Batch processing modes

differ from [on line & real time] in that substantial queues of unprocessed transactions (jobs) are held in the computer throughout normal operation.

After all input records have been read into the computer [see below], the job (processing task defined by these records) is enqueued for execution. If small and short, it may be selected for execution a few seconds later; if large and low-priority, it may remain enqueued for hours.

When the control program selects a job for execution, its control statements are scanned for consistency and completeness. If valid, source data and programs are processed on a nonstop minimal-intervention basis. Output records are generated at this time, typically accumulated on tape or disk, rather than flowing directly to a line printer or display device.

use programs and data stored at all levels of a memory hierarchy:

Main memory
Auxiliary memory
Card decks, floppy disks, cassettes, etc.

Each batch installation maintains a library of systems and applications programs on fast auxiliary memory, typically drums or disks.

2.1.1.1Card-oriented batch processing [off-line preparation]

included here for historical completeness, but is now virtually obsolete

Typical response time: 10² to 10⁴ sec.

Applications based on punched cards (or their images) required input unit records prepared on keypunches, key/disk key/tape systems, teletypes, or other off-line devices not connected to a computer. Input data (and specialized programs associated with the data) were submitted to the computer all at once in a high-speed stream. Little validation of data was performed during this input phase.

Likewise [to job queues], substantial queues of output reports are printed/punched continuously for card-oriented batch processing

2.1.1.2Keyboard-oriented batch processing [on-line preparation]

Typical response time: 10⁰ to 10² sec.

Users of keyboard-oriented batch processing prepare input data and programs much the same way as for card-oriented processing. Some validation and syntax checking are performed as statements are typed directly into the computer. When accepted, images of these statements are retained temporarily/permanently on disk storage. A broad repertoire of commands is available for inserting new statements, updating existing statements, and other editing of partially developed programs.

These [output] queues are presented on request during keyboard-oriented batch processing.

2.1.2Performed on line & in real time

responses to input stimuli (or input transactions) are almost instantaneous.

2.1.2.1Interactive computing

Typical response time: 10⁰ to 10¹ sec.

appropriate for those who wish to develop and operate programs in real time, correcting errors as soon as the latter are detected by the computer. (This contrasts with debugging in batch-processing mode, where most errors cause immediate termination of jobs, accompanied by diagnostic printouts.) Also, programs and data may be validated as entered, syntax checked, consistency with prior program statements established, and range tests on variable values performed.

2.1.2.2On-line inquiry & transaction processing

Typical response time: 10⁰ to 10¹ sec.

use the computer to access rapidly a repository of data and to update the database or to insert new data in it. Processing time per query or transaction (e.g. making an airline reservation) is typically trivial compared with times required to enter and display information. This mode has been made feasible by development and widespread usage of large disk drives whose capacities range from 50 million to 1 billion characters per drive. Complete and up-to-date master files can be accessed by authorized clerks, management personnel, etc. using typewriter terminals or CRT (cathode ray tube) displays.

2.1.2.3Message switching

Typical response time: 10^-1 to 10⁰ sec.

resembles on-line inquiry in that processing per input stimulus (message, query) is trivial. Whereas the inquiry mode permits retrieval and display of disk-stored records, the message-switching mode receives streams of characters (messages) from one site and routes them to other sites automatically, according to destination headers describing (for each message) where it is to be sent. Message switching is almost invariably used in conjunction with the public telephone network; large commercial, manufacturing, and governmental enterprises use message switching for high-speed communications among offices and for efficient usage of their telephone networks. Such systems are the forerunners of more general electronic mail systems.

2.1.2.4Data acquisition & control (DAX)

Typical response time: 10^-2 to 10⁰ sec.

has many operational similarities to message switching—modest requirements for computational power and main memory, fast processing of incoming cassette tapes and punched paper tapes. As data are received from such instruments as voltmeters, gas chromatographs, and thermocouples, they are scaled and tested for conformance to normal operating ranges for these instruments (and associated physical processes). When the computer detects an out-of-range condition, it notifies appropriate personnel such as a plant guard, fireman, or operating engineer. Typically, the DAX-oriented computer types out a warning message, rings an alarm bell, or flashes an alarm light continuously until the out-of-range condition is corrected.

2.2Janossy/Samuels Programming Taxonomy (CICS/ESA Primer, 1995, pp. 3-10)

[/I have placed the author’s comments about the specific hardware and software platforms used to implement these processing modes in smaller type and often enclosed them with slashes/]

2.2.1Batch

Batch programs accept information from processing in groups called batches and produce output grouped in sets, such as report pages or records in new files. … Batch programs are useful for tasks such as producing reports from whole files or databases, applying a file of transactions to a master file, or scanning a file to purge it of outdated information. Batch programs do not communicate with anyone as they execute. Once started, their execution is supervised by the computer’s operating system. Unless a batch program experiences a problem, it continues to execute “on its own” until its work is finished. …

Batch processing is the older of the two forms of processing. [?] The first business activities automated in the 1960s were accounting functions, which operate on regular daily, weekly, monthly, quarterly, and annual cycles. Batch processing was (and continues to be) ideally suited to much of this work. For example, a payroll system runs on a regular cycle, and by its very nature processes grouped sets of data (time sheets) into a grouped output (a set of paychecks).

/IBM mainframes were designed [originally] to support the automation of the 1960s, and as such have [or had?] a “batch” personality. These machines and their operating systems were not designed to communicate with end user terminals. In fact, computer terminals were not even a part of the computing environment when major mainframe design decisions were made in 1962-1963. [This may be somewhat of an overstatement, but does reflect the most common approaches to computing at that time.] Even [many of] today’s mainframe architectures date from this era! [One should, however, recognize the continuing efforts of mainframe vendors to keep their technologies up-to-date while still backwards compatible with existing applications and approaches.]/

/Mini- and microcomputers/ usually support some form of “scripting” language that resembles the job control language /of mainframes/, so that batch processes, like repetitive file backups, can be arranged and processed on them.

1. Primitive batch machine: The earliest vacuum tube computers, which had an operating system so primitive that only one program could be run at a time. An example was the IBM 705 of 1953.

2.2.2Interactive

Interactive programs are designed to communicate with people as they run, usually using computer terminal screens. Interactive programs issue messages, called prompts, to an end user for the entry of information, such as customer id, and retrieve and present related information on the screen.

… Interactive programs allow the end user to communicate new information or change existing information, and then put this information into external (disk) storage. You might think about interactive program processing as similar to the way a desk calculator works. You enter information, the calculator processes your inputs and immediately provides you with computed results. You do not pool or “stack up” hundreds or thousands of calculations for your calculator, then run it in batch mode to do all of your computations overnight and produce a report! …

Interactive processing is the newer form of processing /and is typical of minicomputers and microcomputers. Mini- and microcomputers are inherently interactive, since they (and their operating systems) were designed with this form of processing in mind. Word processing, spreadsheet analysis, and database information retrieval are all typical mini- and microcomputer applications. These are highly interactive and cannot be handled adequately in a batch mode./

2.2.2.1Traditional

Traditional interactive programming consists of two different approaches to the way the person at a terminal is “talked to” by the software in a shared computer.

… Interactive program logic is housed on a /mainframe or minicomputer/ host that accesses indexed files or a database on disk. End users work at terminals /or microcomputers emulating terminals/. The number of terminals the host can support is affected by the interactive programming technique used—pseudoconversational techniques let the host support many more terminals than conversational techniques. But ultimately, the arrangement is constrained by the power of the host computer, where all processing actions must be accomplished. Under traditional interactive programming, the workload is not split between the host computer and the desktop device. The desktop device is treated as being entirely dumb.

2.2.2.1.1[Platform Architectures]

2.2.2.1.1.12. Traditional multiprogrammed architecture: / Traditional Interactive Application Architecture

A mainframe or minicomputer running a capable multiprogrammed operating system with dumb terminals attached. An example was the IBM System/360 or a VAX/780. Dumb terminals are simply communications devices with no programmable logic of their own—[some types of these terminals are] also known as ASCII terminals.

In the traditional interactive system architecture, dumb terminals are connected to a processor such as a mainframe or a minicomputer, …. In this arrangement, all processing tasks associated with database access and the user interface (such as formatting the terminal screen or accepting and validating user input) are handled by the mainframe or minicomputer.

Traditional architecture is expensive in more ways than its requirements for software development. [See Language Paradigms, below] Processor costs range from millions of dollars for a mainframe to hundreds of thousands of dollars for a minicomputer. With the price of microcomputers, workstations, and Reduced Instruction Set Computer (RISC)-based machine platforms declining while their processing power increases, the difference in cost between mainframe/mini’s and these newer levels of equipment is easy to appreciate. Programming in a modern nonprocedural language and sharing processing tasks between a host computer and powerful but inexpensive desktop equipment is a natural direction to explore.

Note that the essential characteristics and expense of traditional interactive system architecture are maintained, even if dumb terminals are replaced with microcomputers emulating terminals. Having a microcomputer emulate a terminal often gains an economy of equipment, as well as slight additional flexibility in capturing, saving, or printing screen images. But terminal emulation does not allocate to the microcomputer any of the processing tasks associated with database access or interaction. The mainframe or minicomputer host is still the workhorse and, for the most part, the bottleneck. You don’t necessarily have client/server just because you access a host computer with a PC or Mac!

2.2.2.1.1.23. Freestanding microcomputer or workstation:

Only a competitor to a mainframe or minicomputer for the smallest single-user interactive processing tasks. An example is a single PC running a database such as Microsoft Access, FoxPro, Dbase IV, Paradox, Revelation, Dataease, or a spreadsheet.

2.2.2.1.1.34. Networked microcomputers or workstations with print or file server: / Networked Microcomputers (Local Area Networks)

Multiple freestanding workstations, each of which can route print to a shared printer and download software or files from a PC or workstation acting as a file server. A Novell network is an example.

… In this arrangement, PCs might communicate with a “main” PC acting as a file server, in order to share software located on the server and access an expensive peripheral device such as a laser printer. The network server may provide terminal emulation software and a connection to a host system, so that individual PCs can act as terminals and log on. The file server may be nothing more than a capable PC with a large hard disk.

A network of microcomputers, a PC, Mac, or workstation acting as a print or file server is not a client/server arrangement. [Some authors would classify this as device or file client/server, but not as application client/server.] Networks not only provide conveniences in software licensing and access control, but also greater security than individual microcomputers acting as terminals to a host. In a network, a microcomputer or workstation may receive the software to run an application over the network instead of having the software loaded on its hard disk. But the critical point is that each microcomputer executes software entirely on its own. In other words, the server in the network is simply a central storage location for programs and files. The server performs no real [application] processing on behalf of any application.

2.2.2.1.2Conversational

Conversational programming carries on a “conversation” with the end user at a terminal using a program that is active all of the time. /This form of interactive programming is typical of minicomputers and microcomputers./ It is relatively easy to program and provides acceptable support for small numbers of terminals.

2.2.2.1.3Pseudoconversational

Pseudoconversational programming gives the appearance of carrying on a conversation with a terminal user, but gains an efficiency advantage by deactivating the program that the terminal user thinks is communicating with him or her while he or she makes entries on the screen. Pseudoconversational programming logic is much more complicated than conversational logic, but it makes it possible /for even a small mainframe or minicomputer/ to support thousands of computer terminals rather than hundreds.

2.2.2.2Client/Server / How Client/Server Architecture Works

Client/server interactive programming is a newer form of programming usually involving communication between microcomputers using a local area network (LAN) and different types of software running on different participants in the network. Client/server computing /has become a topic of much interest to the industry, because it/ holds the potential to make interactive programming easier, more accessible, and less expensive. /In the remainder of this chapter, we’ll focus on client/server computing, to complete your perspective of interactive programming./

5. Client/server architecture: Intelligent devices such as PCs or workstations communicating with a database server and sharing processing tasks with the server. This could also be called “cooperative computing”, because the processing load is split between two similar or dissimilar machines (the PC/workstation client and the database server).

Programming in a modern nonprocedural language [see below] and sharing processing tasks between a host computer and powerful but inexpensive desktop equipment is a natural direction to explore.

You don’t necessarily have client/server just because you access a host computer with a PC or Mac! [This is due to the option of terminal emulation to access a traditional interactive application architecture. See above.]

Client/server architecture is a departure from the traditional way in which processing tasks are divided between devices such as computer terminals (or microcomputers acting as terminals) and a host computer. Client/server is also different from a plain local area network. In the client/server arrangement, the server is often a powerful mini- or microcomputer [or, now, even a mainframe] that manages a relational database. The server is capable of processing SQL statements, that is, statements in a standard relational database manipulation language. The server might perform all of the tasks of an ordinary local area network server in addition to acting as an SQL “engine”. …

In client/server architecture, application software resides on the hard disk of every client (microcomputer or workstation), or on the server much as in an ordinary file server network. This software manages the client’s user interface, which is often graphic in nature. The end user selects functions via a mouse, pull-down menu selections, fill-in lines, or a combination of these. From these inputs, the application software forms SQL statements unseen by the user and sends these to the database server via the local area network. The server processes the SQL statements and creates a relation (table) containing the results. The server then sends these results back to the client over the network, which stores the data in memory or on its hard disk. The client manipulates the data in any way that the client’s user desires, applying the processing horsepower of the client, not the server.

2.2.2.3Event-driven Realtime

Event-driven realtime programming encompasses the internals of graphical user interfaces (GUIs), as well as software that controls machinery.

2.2.2.3.1Windows GUI

Some aspects of modern business programming are beginning to involve GUIs as an adjunct to ordinary information acquisition and management. GUI programming is complex; business applications are often confined to making use of GUI features and access provided by modern support software. /Tools such as Microsoft Visual Basic and PowerSoft PowerBuilder provide access to the GUI interface of Microsoft Windows, while XWindows provides the same form of access under UNIX./ Most client/server tools provide high-level support for the GUI interface, so applications can be simplified and standardized. This means that while GUI is complicated, it internal complexity is hidden.

2.2.2.3.2Process Control

Process control programming, on the other hand, often involves an intimate knowledge of real-time events and software interfaces to transducers that sense pressure, temperature, location, and speed. Languages such as C and Ada are often used to translate the analog signals generated by transducers in industrial piping, storage tanks, engines, turbines, pumps, lifts, aircraft, and missiles into digital form for interpretation by software and the generation of control signals for related machinery.