Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site bu-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!bu-cs!bzs
From: bzs@bu-cs.UUCP (Barry Shein)
Newsgroups: net.unix
Subject: UNIX for transaction processing and DP
Message-ID: <267@bu-cs.UUCP>
Date: Sat, 15-Mar-86 11:48:52 EST
Article-I.D.: bu-cs.267
Posted: Sat Mar 15 11:48:52 1986
Date-Received: Mon, 17-Mar-86 03:24:22 EST
Organization: Boston Univ Comp. Sci.
Lines: 47


I believe when people say that UNIX is not appropriate for transaction
processing and DP they are generally referring to some of the huge systems
out there that are used for these applications, not that you can't do it
at all, just perhaps not economically.

Consider for example the IBM system of the late 70s which had 15,000
(yes 15,000) terminals attached to a reliable transaction processor.
The main trick was to absolutely minimize code paths for each transaction.
Similarly, consider the IBM mainframes used for things like the 76 million
(approx, at some point in the recent past when I heard about it) entry
MasterCard data base. A major factor in solving a DP problem like that
is to use heavy hardware approaches, like IBM disk channels being able
to search for keys in a database on various conditions, and raw speed
and power and of course an O/S tuned to take advantage of the hardware,
like efficiently posting and dispatching many I/Os on different disk arms
asynchronously from the application level (even the clean split between
application and system under UNIX would be considered a disadvantage for
these systems, jumping directly into O/S routines with our own register
settings (eg) might be employed to squeeze out that last cycle.)

Another consideration is that the application software to do all that
just doesn't exist. And the UNIX file system as is does not present
optimal solutions to some of these very high performance needs, like
the ability to put your data base on the disks precisely so as to
optimize disk head motion (you know, things that are needed together
go on one cylinder vertically, splitting files across several disk
arms each capable of simultaneous memory access etc.)

It doesn't mean UNIX could not be made to do this, of course it could,
it's just a similar statement to "pascal does not support variable
length strings", it doesn't mean it couldn't or that a particular variation
might not (some do) just that as presented in its 'standard' form(s) it does
not support such processing for some very fundamental reasons, and if it
did it may not be 'unix' (if we changed the file system on you to make
it similar to MVS data sets would you still call it UNIX? I don't think
so.) Fortunately for the rest of us, most of these very heavy usages can
support special customized systems (big bucks involved), we *can* do
such applications for light use on a general purpose system like UNIX
and (best of all in my opinion) enough of us don't do this sort of processing
at all that we can support an O/S for other reasons.

It doesn't mean that UNIX systems have not been used to develop these
systems, they probably have, but for production runs you probably want
something else.

	-Barry Shein, Boston University