Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!gatech!akgua!akguc!codas!bsdpkh!latham
From: latham@bsdpkh.UUCP (Ken Latham)
Newsgroups: net.unix
Subject: Re: Transaction Processing
Message-ID: <184@bsdpkh.UUCP>
Date: Tue, 18-Mar-86 16:50:50 EST
Article-I.D.: bsdpkh.184
Posted: Tue Mar 18 16:50:50 1986
Date-Received: Sat, 22-Mar-86 05:33:53 EST
References: <1692@brl-smoke.ARPA> <152@daisy.UUCP>
Reply-To: latham@bsdpkh.UUCP (Ken Latham)
Organization: AT&T-IS (SDSS), Orlando Fl.
Lines: 54

In article <152@daisy.UUCP> wje@daisy.UUCP (William J. Earl) writes:
>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.  

WORKING on it

>A forms-control language or package would also be helpful (for handling 
>formatted screens).

YUP

>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,

WRONG

>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.

YUP

> On System V, one could use shared memory,

YUP again

>extra "I/O server" processes, and semaphores to provide asynchronous I/O
>at user level,

and again

> but one would have not protection for the data,

WRONG

We have such a DataBase system UP and Running... We're developing IT!

				Ken Latham

	I would tell you more, but it is VERY PROPRIOTORY as yet!