oage 1

MULTICS-TECHNICAL BULLETIN MTB-333
Toa

Olstrlbutlon

From•T. H. Van Vleck

DatelHarch

SubJectl

Multics Transactlon Processingzz, 1977

llitEQDUCTIQ~Transaction processlng ls what most real-world customers dowith on-line computers. Alrllne reservatlons, Insurance claims
and pollcles, medical records, and many other types of data bases
are managed by transaction processing environments.
Although
Multics ls ideal
for the support of such apolicatiors, wecurrently lack a unlfled system whlch makes such support easy.
This memo describes our plans for a transactlon processing
environment.

Host manufacturers have at least one transaction processing
subsystem available within their operating system. All suchtransactlon processing subsystems follo• thesamegeneraloat tern IoAn operator at a terminal inputs messages

oThe messages cause an applicatlon program (usual ty
to be runo

The appllcatlon program usually accesses and may modify
big data baseoThe apollcatlon program produces output which
sent back to the operatorlsCOBOL)
ausually

Thls sounds something like classical tlme-sharlng, except thatcommands aren•t allowed to read input from tre tyoewrlter.
However, because the Nlsslon of the transaction processln~ systemls aulte different from that of a generaltlme-sharlng system,transaction processing systems tend to o~tlmlze a different setof characterlstlcs.

~~~~~-·----------------·----------------------~---------Hultlcs
Project Internal working
documentatlon.
Not to be
reproduced or dlstrlbuted outside the Multics Protect.

MULTICS TECHNICAL BULLETIN HTB-333

oage 2RESPONSE
The demand for system response ln transaction processing
systems arises from a need to make operator productivity as highas possible. In some applications, the organizatlon•s Image may
be affected if clients of the organization must walt Mhile atransaction processing inquiry proceeds. Since transactions tend
to be of comparable slze, scheduling for transaction processing
must solve a different problem than that of general time-snaringscheduling. In particular, consistent response may be preferredto optimum response in some cases.

DATA BASE PROTECTION
Since operators are unskilled, and since the data basesbeing manipulated are complex ln structure and of high value,transaction processing systems take special care to insure database consistency if a transaction program terminates abnormally.
A fault ln a single orogram causes any cha~ges it has made to beundone;
recovery
afterasystemcrash backs out all
half-completed transactions• changes to the data base.
MESSAGE HANDLING
Since it may be costly to repeat or 011it a transaction which
was in progress at the time of a crash, transaction processing
systems are also designed to perform careful message bookkeeping
so that an operator can determine whether the system has sctualty
heard a reQuest, and •hether the reQuest has completed.
Transactions are often input from video terminals, ln order
to ellmlnate paper handling and because these termirals are
inexpensive. Vldeo terminals are often used in block transfer
11ode, wlth protected fields defining forms to be fll led In; asingle transaction message may therefore be Quite long.
Because operator training ls costly, transaction processing
systems provide elaborate facilities for tailoring the operator
interface.

THROUGHPUT
System efficiency ls less important than the functional
issues described above.
Eff lciency cannot be gained at theexpense of reliablllty. Nevertheless, it ls important to be able
to obtain very hlgh throughput wlth almost all system features lnuse, including the data base manager, Journallzatlon, and COBOL.
Slnce many transaction processing systems spend 80Y. of theirtime ln system code, the natural ef ficiencv of Multics gives us a-'page 3

MULTICS TECHNICAL BULLETIN MTB- 333

good chance to be cost competltlve.
(Manv other operatlngsystems cannot take advantage of multlole CPu•s, for example.)
Some orders of magnltude are ln orders
14 t/sec

USGS benchmark
Alcoa
IRS benchmark
Harketlng wish

130
100

Because the transactlor, processing envlron•ent ls wel I def!ned,
not alt the facllltles of a fully general Jser program need to beprovided for each application program•s environment.

Thls section descrlbes our plans for Multics transaction
processing.
Actual lmplementatlon may be broken into several
phases.

The Multics transaction processing l•olementatlon supolles
three i•Portant interfaces&the administrator interface, theappllcatlon programmer Interface, and the operator Interface.
ADMINISTRATOR INTERFACE
The admlnlstrator of a transaction processing subsyste~ o~Multics wll I use table compliers to speclfv the following Items:
oLines and terminals
Dialed versus dedicated; particular operator;
grouo
membership;
authorization; signon required; ID code
reQuired.

oOata Bases

Journal 1za t ion;olockln9;

audl t tral I;

open lng.

Applicatlon Programs
Permission reQulred; keyword Napping; conversational;
maximum CPU limit; prlorlty; termlnatior on deadlock;
simultaneity; error handling.

oOperators
Password;

prlvlleges;

group me•bership.

MULTICS TECHNICAL BULLETIN HTB- 333

page '+The transactlon processing admlnlstrator wil I comolle thesetables and wlll
be able to inst al I them whl le transaction
processing ls running.
The transactlon processlng admlnlstrator must also function
as a data base admlnlstrator for hls data bases. This Involves
him ln both deflnitlon and security conslderatlons.
To start transaction processing, the admlnlstrator
the coinmand

executesstart_tpln a process which the~ becomes the transaction processing masterprocess. Ourlng startup, the master process will discover lf
data base recovery ls necessary, and lf so wlll operate on thedata base and the Journal file to produce a conslstent sltuation.
Transactlons which were Incomplete at the tlme of the failure
wltt be automatically restarted, unless the admlnistrator has
soeclf led otherwise.
The master process may be started automatically by thesystem_start_up.ec on every bootload lf lt ls a permanent part ofthe svstem•s capabilities;
or a permanent absentee Job can becreated to always start the application.
APPLICATION PROGRAHMER INTERFACE
Application programs to be run under Multics transactlon
processing must obey a few simple rules. They may be written in
any language& COBOLt PL/I, FORTRAN, 0ASIC, APL, LINUS and even
ALH wlll work, as wlll user-supplied compliers and procedures
speclfled ln Multics command language via exec_com.
Apoficatlon
programs wlll obtain thelr input ln a standard fashlon. The
programs must not atte~pt to read from the terminal; attempts toread or ask Questions wll I terminate
theprogram.
Theappllcatlon programs must not use data flies other than thosedefined by the transaction processing administrator lf they wish
to have fut I failure backout protection.
The Multics Oat~ Base Manager, wlth both HIOS and HROSinterfaces, wl IIprobably be heavily used In thls envlron•ent.
Special optlons to avoid redundant openlng and closing of flies,
both MOBH and regular language I/O, will be provided.

MULTICS TECHNICAL BULLETIN MTB- 333

page 5OPERATOR INTERFACEThe operator interface to Multics transactlon processlng canbe tallored to meet the needs of theappllcation.
The
transactlon processing admlnlstrator defines what the commands.
are, how lhe operator signs on, and how messages wlll be routed.
Thestandard
Multics
terminal
softwareprovidesdevice-Independent support for all terminals.

The transaction processlng master process, defined above,causes several other processes to be created to perform theactual transaction processlng.
One or several message control processes wit I be created tohandle terminal
input/output and message Queueing. The message
they maycontrol processes manage groups ofterminal
I ines;perform demultiplexing on multidrop lines. The llnes hand I ed may
be dedicated or attached to the control process by the dlalf ac 11 i ty.
One or several worker processes wil I De created to performthe actual appl !cation execution.
The worker processes will
execute one transaction at a time, Queueing output messages which
wll I be sent to th~ operator lf the transaction completes
correctly.
The worker processes establlsh an environment which
protects against abnormal termination of an application program.
The start of each transaction causes the worker process to make amark ln the recovery Journal f11e so that cleanup operations candlscover what operations were ln progress but had not co~pfeted
at the time of a crash or fault.
The worker processes cooperate wlth the data base softwareand the transaction processing master process to protect thesubsystem from deadlock.
Batch processes may also operate on the sa•e data
which are ln use by a transaction processing application;
Processes also are protected from deadlock.

bases
batch

Figure 1 shows a simplified diagram of the relationshipsthe various processes.

ofMany other features are planned for the Multlcs transaction
processing subsystem.
Some of these wll I be oresent ln thelnltlal version, and some will be deferred untll we are sure of
the most general way of meetlng customer needs. A list of sucht 0 p l cs f 0 I I 0 WS I

MULTICS TECHNICAL BULLfTIN MTB- 333

sophlstlcated schedullng
forms termlnal support
message routing
testing Interface
tralnlng Interface
keeping multl-llne messages together
batched transactions
Inter-terminal messages
broadcast messages
starting absentee Job from transaction
transaction chalnlng
updating programs without shutdown
statlstlcs
AIM·multllevet security

Page&