Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!ut-sally!pyramid!nsc!daisy!wje
From: wje@daisy.UUCP (William J. Earl)
Newsgroups: net.unix
Subject: Re: Transaction Processing
Message-ID: <152@daisy.UUCP>
Date: Fri, 14-Mar-86 17:20:47 EST
Article-I.D.: daisy.152
Posted: Fri Mar 14 17:20:47 1986
Date-Received: Mon, 17-Mar-86 03:24:07 EST
References: <1692@brl-smoke.ARPA>
Reply-To: wje@daisy.UUCP (William J. Earl)
Organization: Daisy Systems Corp., Mountain View, Ca
Lines: 40

In article <1692@brl-smoke.ARPA> larry@jpl-vlsi.arpa writes:
>"Unix is terrible for transaction processing and DP processing by banks and 
>insurance companies."
>I've heard this before.  Why is this so?  And does putting a U**x on top
>an OS that does do good transaction processing solve the problem?  Would a 
>native Unix with a kernel optimized for TP fall down on program-development
>functions?

    UNIX is not fundamentally terrible for transaction processing.  Rather,
it simply lacks certain facilities which would make typical applications
efficient and easily implementable.  What is required is fast indexed record 
access (as in a good database system), atomic transactions with respect the 
above accesses, and good communications support, including BISYNC and X.25.  
A forms-control language or package would also be helpful (for handling 
formatted screens).  It turns out that a database system which includes
atomic transactions in a clever way, such as IBM's IMS FASTPATH, can provide
very high transaction rates, with a declining cost per transaction as the
transaction rate rises.  There is nothing in UNIX which prevents the 
implementation of such a database system, at least on 4.2 BSD, but unless
it is added to the kernel, perhaps as a simulated "character device driver",
it must pay a high overhead for disk accesses.  The problem is that UNIX only
provides asynchronous I/O via the block cache, but a database system needs
to manage its own cache.  On System V, one could use shared memory,
extra "I/O server" processes, and semaphores to provide asynchronous I/O
at user level, but one would have not protection for the data, since
it would then be visible in all applications.  

    Putting UNIX on top of most of the transaction-oriented operating
systems with which I am familier would likely lead to unsatisfactory 
UNIX performance.  An exception would be in a virtual machine environment,
as on VM/370 with MVS and UTS running in parallel virtual machines.
On the other hand, such a system allows only cross-development,
in that one cannot debug the application under UNIX.

    A UNIX with a transaction-processing kernel should certainly
be feasible, but the kernel would be substantially different from a normal
UNIX kernel.
-- 
	William J. Earl
	Daisy Systems Corporation, Mountain View, CA