hargrove@harlie.sgi.com (Mark Hargrove) (08/18/89)
Over the last 2 million years (well, 9 months actually, but we've been dealing with salesmen, so it seems longer...), we've heard a LOT about the various strategic directions that the major 6 or 7 DB suppliers will be taking. Several common themes have emerged, and one interesting dichotomy. One group of vendors (most notably DEC and Tandem) are making very strong arguments that most, if not all, of a DB engine should be embedded in the operating system. Tandem is basically in the state already; DEC insists they will be. Both argue that high performance DB's *require* this approach. The other group of vendors argue that this is just not so -- except for extreme cases, even heavy OLTP applications can be run with the DB engine as a "normal" process, running on top of an OS. Their arguments are generally based on the notion that MIPS (and to a lesser extent, disk I/O's) are cheap -- and getting cheaper fast. Performance can always be increased by throwing cheap MIPS and faster disks at the problem. [well, the argument is more sophisticated than this, but you get the drift]. Our own evaluation team is religiously divided on this subject. What are your thoughts on this issue? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark Hargrove Silicon Graphics, Inc. email: hargrove@harlie.sgi.com 2011 N.Shoreline Drive voice: 415-962-3642 Mt.View, CA 94039
jkrueger@dgis.daitc.mil (Jonathan Krueger) (08/19/89)
hargrove@harlie.sgi.com (Mark Hargrove) writes: >One group of vendors (most notably DEC and Tandem) are making very strong >arguments that most, if not all, of a DB engine should be embedded in the >operating system. Tandem is basically in the state already; DEC insists >they will be. Both argue that high performance DB's *require* this approach. I remember, not so very long ago, hearing that operating systems had to be written at machine level, or performance would be unacceptable. And that shells had to be part of the operating system. And that records had to be hardwired into file manipulations and record structure imposed on all i/o. Oh yes, and that database programming had to refer to specific tracks and cylinders when defining and accessing data. Have we learned nothing? -- Jon -- Jonathan Krueger jkrueger@dgis.daitc.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33?
tim@binky.sybase.com (Tim Wood) (08/22/89)
In article <HARGROVE.89Aug18004754@harlie.sgi.com> hargrove@harlie.sgi.com (Mark Hargrove) writes: > >The other group of vendors argue that [the DBMS need not be embedded in >the OS] -- except for >extreme cases, even heavy OLTP applications can be run with the DB engine >as a "normal" process, running on top of an OS. Their arguments are generally >based on the notion that MIPS (and to a lesser extent, disk I/O's) are >cheap -- and getting cheaper fast. Performance can always be increased by >throwing cheap MIPS and faster disks at the problem. [well, the argument >is more sophisticated than this, but you get the drift]. There's an implicit assumption in your point: that OS's must impose a considerable performance penalty on DBMS operation. That need not be the case. The challenge in designing an OS-hosted DBMS is to use only the most basic OS functions (such as user-buffered disk I/O and basic front-end/backend IPC services). "Just throw more cheap (memory|CPUs) at the problem," used to be the rejoinder of some RDBMS companies to complaints of slow performance and high memory usage, which were consequences of OS-process-per-user architectures. Today, client/server architectures have invalidated that argument. That is, added resources should not be used up by overhead such as OS scheduling and heavyweight process state, they should be used directly by the DBMS to run applications faster or keep more of the database memory resident. Client/server architectures that use only the OS primitives for I/O and IPC offer this cost/benefit relationship because they can make more efficient use of system resources. This organization offers maximum flexibility too, in that an OS-hosted DBMS is more likely to be portable across several platforms, whereas an OS-embedded DBMS is likely to be a proprietary solution supported only by a single vendor's OS and hardware offerings. That usually translates into extra $$, fewer application choices and a less open system. Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim Voluntary disclaimer: This message is solely my personal opinion. It is not a representation of Sybase, Inc. OK.
miket@blia.BLI.COM (Mike Tossy) (08/24/89)
In article <HARGROVE.89Aug18004754@harlie.sgi.com>, hargrove@harlie.sgi.com (Mark Hargrove) writes: > > (Stuff deleted) > > One group of vendors (most notably DEC and Tandem) are making very strong > arguments that most, if not all, of a DB engine should be embedded in the > operating system. Tandem is basically in the state already; DEC insists > they will be. Both argue that high performance DB's *require* this approach. > > The other group of vendors argue that this is just not so -- except for > extreme cases, even heavy OLTP applications can be run with the DB engine > as a "normal" process, running on top of an OS. Their arguments are generally > based on the notion that MIPS (and to a lesser extent, disk I/O's) are > cheap -- and getting cheaper fast. Performance can always be increased by > throwing cheap MIPS and faster disks at the problem. [well, the argument > is more sophisticated than this, but you get the drift]. >>> WARNING! I work for a vendor! (Who agrees with DEC and Tandem.) <<< (1) Even in the era of "cheap MIPS" it tends to be more cost effective to efficently use a resource than to waste it. Remember both the efficent and the wasteful use the same hardware. (2) Since the development cost of integrating the dbms and operating system together is paid once by the dbms vendor vs the alternative strategy where all users pay for extra MIPS and disk speed. For the society as a whole is is cheaper to integrate the dbms and o/s, assuming that the system will be replicated a significant number of times. (3) ShareBase Corporation maintains atleast a 4 to 1 price/performance advantage over Oracle on VAXs largely due to the dbms/operating system integration in our database servers. (There are other tricks not relevant to the discussion at hand.) This has been true since 1981. The explosion in cheap MIPs hasn't changed the ratio; because the hardware improvements help us too. (4) DBMS & O/S integration probably only really pays off if you've got a significant database problem. If database work is taking 100% of your resources (as it does in a database server) it is logical to optimize how you do database. If database isn't a major factor then find out what is and optimize that! (5) tim@sybase.com writes "The challenge in designing an OS-hosted DBMS is to use only the most basic OS functions (such as user-buffered disk I/O and basic front-end/backend IPC services). ... ... That is, added resources should not be used up by overhead such as OS scheduling and heavyweight process state, they should be used directly by the DBMS to run applications faster or keep more of the database memory resident." By that, I think, he means that they have built an integrated dbms & o/s that runs on top of a regular o/s that they don't really use. I place Sybase in the DEC / Tandem / ShareBase camp on this one. (No big suprise to anyone who knows the ShareBase / Sybase history.) (6) jkrueger@dgis.daitc.mil writes: > I remember, not so very long ago, hearing that operating systems had to > be written at machine level, or performance would be unacceptable. And > that shells had to be part of the operating system. And that records > had to be hardwired into file manipulations and record structure > imposed on all i/o. Oh yes, and that database programming had to refer > to specific tracks and cylinders when defining and accessing data. > > Have we learned nothing? How about network protocols running as user processes, or windowing systems without operating system support? Sometimes integration makes sense. Assume that you are doing a significant amount of DBMS work. Who should decide when is the correct time to do read-ahead? The O/S could guess or the RDBMS (which *knows* when it is using a scan and when it is using an index) can tell the O/S. Who should decide what buffers to page out? The O/S could guess or the RDBMS (which *knows* the contents of the buffer) can tell the O/S. (7) I predict this will become a less important "religious issue" as evolving operating systems like UNIX continue to improve their RDBMS support. -- Mike Tossy ShareBase Coropration miket@blia.bli.com 14600 Wichester Blvd (408) 378-7575 ext2200 Los Gatos, CA 95030 (Formerly: Britton Lee, Inc.) The preceeding might be (probably is - in fact) close to the opinion of ShareBase Corp; but if you think I bothered to clear it with anybody other than myself you're crazy.
jkrueger@dgis.daitc.mil (Jonathan Krueger) (08/24/89)
miket@blia.BLI.COM (Mike Tossy) writes: >(3) ShareBase Corporation maintains at least a 4 to 1 price/performance > advantage over Oracle on VAXs largely due to the dbms/operating > system integration in our database servers. Can you tell us how you measured this? -- Jon -- Jonathan Krueger jkrueger@dgis.daitc.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33?
hargrove@harlie.sgi.com (Mark Hargrove) (08/24/89)
In article <8951@blia.BLI.COM> miket@blia.BLI.COM (Mike Tossy) writes: >>>> WARNING! I work for a vendor! (Who agrees with DEC and Tandem.) <<< You know, I forgot about Britton-Lee (oops, Sharebase :-) ). Frankly, I'm in the other camp with respect to products like the Sharebase servers. I think they're a great idea. I also think that there's a difference: Sharebase doesn't pretend (I don't think) that they sell a full fledged OS, and oh yeah, it has DB built in. They sell a database hardware platform, which is much more honest. Tandem leans more in this direction also, although not quite as cleanly. With respect to DEC, I think they're just waving their hands around. Can anybody really convince me that you can have a fully general OS which makes perfect sense for engineers, scientists, AND heavy OLTP DB applications? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark Hargrove Silicon Graphics, Inc. email: hargrove@harlie.sgi.com 2011 N.Shoreline Drive voice: 415-962-3642 Mt.View, CA 94039
gupta@cullsj.UUCP (Yogesh Gupta) (08/25/89)
In article <8951@blia.BLI.COM>, miket@blia.BLI.COM (Mike Tossy) writes: $ In article <HARGROVE.89Aug18004754@harlie.sgi.com>, hargrove@harlie.sgi.com (Mark Hargrove) writes: $ > [...] $ > One group of vendors (most notably DEC and Tandem) are making very strong $ > arguments that most, if not all, of a DB engine should be embedded in the $ > operating system. [...] $ > Both argue that high performance DB's *require* this approach. $ > $ > The other group of vendors argue that this is just not so -- except for $ > extreme cases, even heavy OLTP applications can be run with the DB engine $ > as a "normal" process, running on top of an OS. Their arguments are generally $ > based on the notion that MIPS (and to a lesser extent, disk I/O's) are $ > cheap -- and getting cheaper fast. Performance can always be increased by $ > throwing cheap MIPS and faster disks at the problem. [well, the argument $ > is more sophisticated than this, but you get the drift]. $ No, we do not argue that you can throw cheap MIPS and faster disks at the problem. The buyer is really interested in the price that needs to be paid for the whole solution, and that includes the hardware, the software, the implementation cost, and the maintenance cost (BTW, the later 2 quite often dominate the first two!). Independant software vendors would not be in business if they could not provide competetive solutions. $ (1) Even in the era of "cheap MIPS" it tends to be more cost effective $ to efficently use a resource than to waste it. Remember both the $ efficent and the wasteful use the same hardware. I agree with the above. But I do not agree with the fact that you have to integrate the DBMS into the OS to achieve high performance. $ (2) [more stuff on why we should not waste resources deleted] $ (3) ShareBase Corporation maintains atleast a 4 to 1 price/performance $ advantage over Oracle on VAXs largely due to the dbms/operating $ system integration in our database servers. (There are other tricks $ not relevant to the discussion at hand.) This has been true since $ 1981. The explosion in cheap MIPs hasn't changed the ratio; because $ the hardware improvements help us too. Now that we are touting products, I know of instances where customers who ran their business with Sharebase went to an independent vendor *because* of cost effectiveness of the DBMS engine. To get the required performance on the Sharebase system would have cost more than to use stock hardware and OS with a third party RDBMS. $ (4) DBMS & O/S integration probably only really pays off if you've got $ a significant database problem. If database work is taking 100% $ of your resources (as it does in a database server) it is logical $ to optimize how you do database. If database isn't a major factor $ then find out what is and optimize that! Optimizing the database work does *not* mean picking an RDBMS/OS integrated solution. $ (6) jkrueger@dgis.daitc.mil writes: $ > I remember, not so very long ago, hearing that operating systems had to $ > be written at machine level, or performance would be unacceptable. And $ > that shells had to be part of the operating system. And that records $ > had to be hardwired into file manipulations and record structure $ > imposed on all i/o. Oh yes, and that database programming had to refer $ > to specific tracks and cylinders when defining and accessing data. $ > $ > Have we learned nothing? $ $ How about network protocols running as user processes, or $ windowing systems without operating system support? Sometimes $ integration makes sense. The issue is not whether you need some operating system support for the efficient implementation of a certain functionality. It is whether current OSs provide enough support and capabilities that the independent software vendors can provide efficient solutions. That is true for many OSs today and is becoming more and more true for the others. The original questioner (hargrove@harlie.sgi.com (Mark Hargrove)) asked whether the claim by HW vendors that the DBMS has to be embedded in the OS for it to be efficient was correct. As you can see on the Dec platform today, it is not true. $ Assume that you are doing a significant amount of DBMS work. $ Who should decide when is the correct time to do read-ahead? $ The O/S could guess or the RDBMS (which *knows* when it is using $ a scan and when it is using an index) can tell the O/S. $ Who should decide what buffers to page out? The O/S could guess $ or the RDBMS (which *knows* the contents of the buffer) can $ tell the O/S. An OS that allows the "user" (in this case the DBMS) to specify certain buffer management and I/O policies would do very well, thank you. $ [...] $ -- $ Mike Tossy ShareBase Coropration ------- -- Yogesh Gupta. | The opinions expressed in this article Cullinet Software, Inc. | are those of the author and do not | represent those of Cullinet Software | or the plant on my desk.
tim@binky.sybase.com (Tim Wood) (08/25/89)
In article <8951@blia.BLI.COM> miket@blia.BLI.COM (Mike Tossy) writes: >In article <HARGROVE.89Aug18004754@harlie.sgi.com>, hargrove@harlie.sgi.com (Mark Hargrove) writes: >> >> [Basic topic:] >> One group of vendors (most notably DEC and Tandem) are making very strong >> arguments that most, if not all, of a DB engine should be embedded in the >> operating system. > >(5) tim@sybase.com writes "The challenge in designing an OS-hosted DBMS > is to use only the most basic OS functions (such as user-buffered > disk I/O and basic front-end/backend IPC services). ... > ... That is, added resources should not be used up by overhead such > as OS scheduling and heavyweight process state, they should be used > directly by the DBMS to run applications faster or keep more of the > database memory resident." > > By that, I think, he means that they have built an integrated dbms > & o/s that runs on top of a regular o/s that they don't really use. > I place Sybase in the DEC / Tandem / ShareBase camp on this one. > (No big suprise to anyone who knows the ShareBase / Sybase history.) Mmm, close enough. But there's an important difference. The Sybase database engine can be run on several different hardware+OS platforms, and the number is growing. This design gives the advantage of DBMS-managed resources plus the advantage of multi-vendor compatibility. DEC, Tandem and ShareBase (if I'm not mistaken) all require use of their own hardware in order to use their database solution. But we've shown that that limitation is not necessary to have performance, functionality and high availability in a DBMS. An OS-hosted server can take advantage of the hardware advances of all vendors' hardware to which it has been ported. A proprietary DBMS only has one vendor's growth path open to it. For those that don't know the history, Sybase was formed in 1984 by two executives and two development managers from then-Britton-Lee. Our Executive VP, Robert Epstein, was a lead designer of Berkeley INGRES, of the Britton-Lee IDM database machine and in 1984-85, of the Sybase SQL Server. I am employee #8 at Sybase counting the founders, and have been here 7th longest. All but one of the first dozen or so people to join are still here. > >(6) jkrueger@dgis.daitc.mil writes: >> I remember [not so long ago] hearing that operating systems had to >> be written at machine level... [and other scary examples of device and >> application dependence] >> Have we learned nothing? > > How about network protocols running as user processes, or > windowing systems without operating system support? Sometimes > integration makes sense. Not sure whether you're pro or con these. User-domain network protocols are of some interest, especially in secure systems development. Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim Voluntary disclaimer: This message is solely my personal opinion. It is not a representation of Sybase, Inc. OK.
robinson@todd.med.unc.edu (Gerard A. Robinson) (08/25/89)
In article <8951@blia.BLI.COM> miket@blia.BLI.COM (Mike Tossy) writes: >In article <HARGROVE.89Aug18004754@harlie.sgi.com>, hargrove@harlie.sgi.com (Mark Hargrove) writes: >> >> (Stuff deleted) >> >> One group of vendors (most notably DEC and Tandem) are making very strong >> arguments that most, if not all, of a DB engine should be embedded in the >> operating system. Tandem is basically in the state already; DEC insists >> they will be. Both argue that high performance DB's *require* this approach. >> Hmmm...I'd expect that perhaps *only* for high-performance DBs would one need to do this. But for general system use and general business use one perhaps need only look at the (lack of) penetration that the Pick system (a very nice OS where the file system IS the DB and vice versa) has had in the market. Here's a system that had relational views of data with embedded business rule checking, and other now re-emerging features back in 1978 when I first was exposed to it. It was the basis for Prime's Information and Cosmos (?) PC-DB Revelation. It now is offered in versions layered/embedded in host OSs. But as a combined OS/DB its basically a side stream entity despite is (remembered) niceness. Generally an application mix is what's required by users, and most developers can't afford to gamble on a 'single point of failure' for their livelihood. DEC and TANDEM would argue against this as that's a portion of *their* livelihood. So while the argument might have some technical merit, it is (in my mind) mostly self-serving. After all, both RDB and RMS are layers over the VMS kernel. Gerard Robinson
forrest@phobos.sybase.com (Jon Forrest) (08/25/89)
I worked at Britton Lee for two years and now I work for Sybase.
I think the Britton Lee approach is doomed because of the cost and the
time it takes to develop hardware. When I started at Britton Lee
in 1986 work was already underway on what I believe is called the
Sharebase 8000 (it had the codename "Omega".) At the time, if its
design goals had been met, it would have been faster that anything
else available at a similiar cost. But, it took so long to develop
the hardware, and the hardware specific software, that it's just now
shipping in any quantity (correct me miket if I'm wrong). Meanwhile,
you can buy off the shelf hardware that, when running Sybase software,
will, if I'm not mistaken, out perform the 8000 (I don't have any
specific proof, this is conjecture) at a cost no greater than the 8000.
This isn't due to any failing on the part of Britton Lee. The people
there are some of the smartest (and nicest) people I'll ever have the
honor of working with. But, there's no way a small company like Britton
Lee can keep up hardware wise with the MIPS and SPARCS of the world.
This is where I see the fundemental difference between Britton Lee
and the rest of us that do client/server database systems.
Whether or not the db engine is embeded in the OS (which it isn't,
either at Sybase or Britton Lee) is not the key question, in my
opinion.
Jon Forrest
forrest@sybase.com
{pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest
415-596-3422joshua@athertn.Atherton.COM (Flame Bait) (08/26/89)
>>> [Basic topic:] >>> One group of vendors (most notably DEC and Tandem) are making >>> very strong arguments that most, if not all, of a DB engine should be >>> embedded in the operating system. Buying an DBMS embedded in a propriatery operating system like DEC's or Tandem's is making a faustian deal with the devil: The devil says: "I will give you 20% better performance now, but you must give me your application for all eternity." (Evil laugh in the background). Joshua Levy joshua@atherton.com home:(415)968-3718 {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822
miket@blia.BLI.COM (Mike Tossy) (08/26/89)
Re: various perf claims I don't think this is the forum to get into "my box is faster than your box" arguments. (My earlier comments about another DBMS company's performance were intended to be an specific indication of the kind of advantages available to DBMSs when they are able to control specific functions (like I/O, scheduling, and data cache management) which have traditionally been the domain of the O/S. As to whether you *CALL* this "embedding the DBMS in the O/S" or you call it "providing additional controls in the O/S that the DBMS can exploit" I find to be a silly semantic argument of little technical interest. (It will be a matter of marketing life and death to the independant dbms vendors and so I understand why it is important to them.) I thank Jon Forrest for his kind words about the people at ShareBase. We miss you Jon and you're welcome to come back if you-know-who goes belly up! :-) (Unfortunately) In article <5743@sybase.sybase.com>, forrest@phobos.sybase.com (Jon Forrest) also writes: > ...Sharebase 8000 ... But, it took so long to develop > the hardware, and the hardware specific software, that it's just now > shipping in any quantity (correct me miket if I'm wrong). Meanwhile, > you can buy off the shelf hardware that, when running Sybase software, > will, if I'm not mistaken, out perform the 8000 (I don't have any > specific proof, this is conjecture) at a cost no greater than the 8000. Sorry Jon, I haven't seen ANY evidence to prove your claim and I've seen studies to indicate that the Server/8000 has better price performance than Sybase (at least for some classes of problems). They also indicate Sybase has better price / perf than "The big O" - so don't sell your stock yet! :-) I, for one, have great respect for the Sybase product and development team (well maybe one or two exceptions :-> ) and wish them luck. I don't think that ShareBase and Sybase compete much in the market and when I see a prospect that seems better suited to Sybase I tell them to look you guys up. Mike Tossy ShareBase Coropration miket@blia.bli.com 14600 Wichester Blvd (408) 378-7575 ext2200 Los Gatos, CA 95030 (Formerly: Britton Lee, Inc.) The preceeding could be close to the opinion of ShareBase Corp; but if you think I bothered to clear it with anybody other than myself you're crazy.
forrest@phobos.sybase.com (Jon Forrest) (08/27/89)
In article <8976@blia.BLI.COM> miket@blia.BLI.COM (Mike Tossy) writes: > >I thank Jon Forrest for his kind words about the people at ShareBase. We >miss you Jon and you're welcome to come back if you-know-who goes >belly up! :-) > Thanks Mike but would there be anybody left? >(Unfortunately) In article <5743@sybase.sybase.com>, >forrest@phobos.sybase.com (Jon Forrest) also writes: > [.....various statements about Sybase vs. Britton Lee....] I don't unfortunately have any specific benchmarks to back up my feelings but deep in my heart I know they're right. But, in any case, one thing that should be obvious is that as hardware technology changes our (Sybase's) marginal costs to keep up are much less than yours. In other words, it costs less and takes less time for us to make our stuff run on X (where X is the latest greatest chip or processor) than for you. This means that even if it is true today that the 8000 is "faster" than our stuff on a platform of similiar cost, it won't be true for long. I bet that few RDBMS acquisition decisions are made that only consider the short term benefits that you might be able to claim with the 8000. Also, as an ex computer systems manager, the thought of yet another hardware manufactorer to have to deal with, especially one whose financials haven't been all that great for the last couple of years, would make me feel uneasy. One area where Britton Lee is better than Sybase is in your multi protocol support. The fact that the IDM (I can't get used to the new names) can simultaneously talk to hosts running TCP/IP, DECNET, XNS, RS-232, IEEE, IBM Channel, and probably others I don't know about is a real plus for you and is something I'm surprised hasn't been stressed more in Britton Lee's marketing. Sybase is aware of this weakness and will have a solution in the future. As far as I can see, the only hope for Britton Lee is if you stop making hardware and port your wonderful software to off the shelf hardware. (Needless, but maybe necessary, to say, all this is my personal opinion and is in no way an official statement of Sybase policy). Jon Forrest forrest@sybase.com {pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest 415-596-3422
davek@rtech.rtech.com (Dave Kellogg) (08/28/89)
In article <12003@joshua.athertn.Atherton.COM> joshua@atherton.com (Flame Bait) writes: >>>> [Basic topic:] >>>> One group of vendors (most notably DEC and Tandem) are making >>>> very strong arguments that most, if not all, of a DB engine should be >>>> embedded in the operating system. > >Buying an DBMS embedded in a propriatery operating system like DEC's or >Tandem's is making a faustian deal with the devil: I think this debate with respect to systems like Rdb is somewhat off the mark. While I can't speak about Britton-Lee systems, I can say that Rdb is certainly not "embedded" into the VMS operating system. "Bundled" would be a better term-- that is, when you *buy* VAX/VMS you get some kind of runtime Rdb license. However, this is not to say that Rdb itself is part of the VMS executive. Rdb, until recently at least, was a "layered product." Just because DEC may now be selling it with VAX/VMS, it doesn't mean that any major technical changes occurred behind the scenes. In my opinion, Rdb is about as "embedded" in VAX/VMS as is any third-party DBMS. Server-based systems, on the other hand, like INGRES or even Sybase are not embedded in the operating system either. They are, in fact, bypassing or replacing certain parts of it-- like memory management or scheduling. Techno-wise it's not "embedding the DBMS into the OS, it's embedding an OS subset into the DBMS." Marketing-wise it's simply "buy this, and this comes along free/cheap." There is a difference. None of the examples I've seen in this debate that I know of (Rdb, Oracle, Sybase or INGRES) are in any way "embedded" in the operating system. The simple issue is replace things like memory management and scheduling or don't. Dave Kellogg # include disclaimer.h