bzs@bu-cs.UUCP (Barry Shein) (03/15/86)
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
cycy@isl1.ri.cmu.edu (Christopher Young) (03/18/86)
It's definitely possible to have such applications running for smaller systems. The company I used to work for put out a Dibol compiler for quite few different UNIX systems. The main use for Dibol is transactions and DP. One company switched their entire reservation package from the TSX system to UNIX running on AT&T 7300s. We had (they have) other customers buying the compiler for UNIX systems, too.
geoff@desint.UUCP (Geoff Kuenning) (03/18/86)
In article <267@bu-cs.UUCP> bzs@bu-cs.UUCP (Barry Shein)
does a really good job of summarizing the realities of doing TP under
UNIX. I have only a couple of small points to add:
(1) There are several vendors selling a Unix that has been enhanced
to support real time or TP. I think most of them are actually in the
hardware business, so you're stuck with their hardware. There are also
several Unix lookalikes that can do TP.
(2) AT&T has an internal version of Unix, Unix/RT, that supports
real time. They have never made this into a product, however, possibly
because it has problems that make nonviable commercially.
(3) Depending on your particular application, standard Unix may be
able to serve perfectly adequately. It is also possible to modify the
standard kernel to support TP better; my consulting firm recently did
this for a major manufacturer. (We welcome inquiries from anyone who
is interested in a similar service).
--
Geoff Kuenning
SAH Consulting
(213) 545-4413
{hplabs,ihnp4}!trwrb!desint!geoffblm@chinet.UUCP (Brad L. McKinley) (03/18/86)
If your going to need to manage a HUGE data base then why not get a machine designed to do just that? True, UNIX does not handle TX processing very well as is. But if you used the UNIX machine as the front end to a data base engine you could get the best of both worlds: UNIX as a development environment with support facilities AND a dedicated, high performance data base engine. Britton-Lee for example builds such a computer. The B-L machines handle data base work exclusively. Host CPUs communicate with the data base engine typically through an Ethernet. As I understand it (which I admit is limited) a protocol converter runs on the host CPU(s) and talks to the data base engine over the Ethernet. The B-L engine optimizes the data base in the best manner while not having to worry about 1200 baud printers, 9600 baud ttys, etc. With this scheme, non-UNIX computers (God forbid) can even have access to the data base. This makes all sorts of sense to me. Guaranteed, 2 years from now there is going to be another hot language/operating system/CPU out on the and lots of people are going to groan when they want to move up to new equipment but they can't afford/justify scraping the existing stuff. With this approach, all that is needed is for the new equipment/OS to talk to the data base engine. I know there are those of you on the net who passionately hate mentioning specific vendors but I have have my fire retardant suit on. Flame me if you want. If there are other companies that build similar systems I'd like to here from (about) them. ----- Brad L. McKinley -- ihnp4!chinet!blm OR ihnp4!chinet!mdr!blm -- (503) 889-4321 USMail: M D R Professional Software, Inc., 915 SW 3rd Avenue, Ontario, OR 97914 "First you say it, then you do it" -- Bill Cosby
jph@whuxlm.UUCP (Holtman Jim) (03/19/86)
> It's definitely possible to have such applications running for smaller > systems. The company I used to work for put out a Dibol compiler for quite > few different UNIX systems. The main use for Dibol is transactions and DP. > One company switched their entire reservation package from the TSX > system to UNIX running on AT&T 7300s. We had (they have) other customers > buying the compiler for UNIX systems, too. I have several hundred UNIX(tm) systems in the field that run s transaction/data base system. This is running both on PD 11/70s and VAX 8600. We support a DBMS that has record locking, concurrency and recovery. We support 30-50 BISYNC lines on an 11/70s. If you would like more details on this system, see the July-August 1982 (Vol 61, no. 6, part 2) issue of the Bell System Technical Journal. On the 11/70s, we are processing about a transaction/second (5 reads/5 writes), while at the same time handling all the BISYNC lines without the aid of KMCs or external processors. All the short comings of UNIX as a transaction base have been overcome in our implementation. We do not use the UNIX file system; our DBMS uses raw I/O. New drivers were added to support the BISYNC lines (we are both master and slave - we can be a 3271 controller to an IBM host) and the management of shared memory was enhanced. The system has now been ported to an 8600 and make a fairly impressive system when you consider that we are probably handling on the order of 800-900 users on the system.