[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DEC Rdb against the World |
|
| Moderator: | HERON::GODFRIND |
|
| Created: | Fri Jun 12 1987 |
| Last Modified: | Thu Feb 23 1995 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1348 |
| Total number of notes: | 5438 |
988.0. "VAX/Oracle & ULTRIX ..." by JENEVR::RLEE () Thu Sep 12 1991 16:44
From: LJOHUB::DENAULT "11-Sep-1991 0930" 11-SEP-1991 18:30:36.68
To: @IPCINTEREST.DIS
Subj: Enhancing VAX/ORACLE database systems with DECYSYSTEM client/server
Subject: ENHANCING VAX/ORACLE DATABASE SYSTEMS
WITH DECSYSTEM CLIENT/SERVER CONFIGURATIONS
The USS DEC/Oracle team are pleased to provide you with the
following information to help you enhance your customer's
existing VAX/Oracle database system, or to help you provide a
RISC/Unix-based, homogeneous Oracle RDBMS system for customers
who are committed to UNIX.
What follows are approximately 10 pages that describe the
advantages of this client/server approach to RDBMS, the various
database front end solutions, and the criteria that apply to
database server selection. This is accompanied by a reference to
a file containing 17 separate diagrams and equipment and software
lists that cover most, if not all, possible customer configurations.
We hope this information will help you succeed in selling into
the highly competitive UNIX-based RDBMS market.
Selling DECsystems with Client/Server RDBMS
Bill Juch,
Andrei Shishov
USS Systems Engineering
Ned Berube
USS DECsystems BPM
August 28,1991
Digital INTERNAL USE ONLY
Table of Contents
1 Summary: Selling DECsystems with Client/Server
RDBMS 2
2 Selling DECsystems as Platforms for Client/Server
Relational Data Base Systems. 4
2.1 Introduction 4
2.2 Client/Server Architectures and RDBMS Vendors 4
2.3 Oracle Client/Server Architecture 4
2.4 Advantage of Distributed Client/Server RDBMS
Architecture 5
2.5 Digital's Systems: Picking the Right Hardware
Platforms for Customer Needs 5
2.5.1 The Data Base Server 5
2.5.2 The Data Base Client 6
3 Data Base Front End Solutions 7
3.1 Character Cell Terminal Configurations 7
3.2 X-terminal Configurations 7
3.3 DOS Workstations 8
3.4 OS/2 Workstations 8
3.5 Macintosh workstations 8
3.6 RISC/ULTRIX DECstation or VAX/VMS VAXstations 9
4 Data Base Server Selection 10
4.1 Existing Digital/Oracle Customer 10
4.2 New Customer 10
4.3 Data Base Servers for PCs 10
1 Summary: Selling DECsystems with Client/Server
RDBMS
Who do you sell to:
Existing and new RDBMS (Oracle, Ingres, Sybase,
possibly other) customers.
What do they need:
Existing customers need to expand their data base systems to
handle more users, more data, to add new user interfaces and
applications. They also need to obtain better performance while
protecting their investment.
New customers need the best (in terms of cost/performance)
system platform to run the RDBMS application.
What do you sell:
Client/Server data base configuration where the data base is
stored on a dedicated server (called the Data Base Server),
and the user application runs on a dedicated front end processor
(called the Application Server or Client), such as: DECsystem
application front end for terminals, or a desktop device
(PC or workstation).
How do you win:
Existing VAX customers: preserve their investment in VAX/VMS or
VAX/Ultrix; improve price/performance of the overall system
configuration without the need for system migration or changing
vendors; deploy additional applications, add users with minimum
disruption. Follow a possible UNIX mandate without replacing
current resources or disrupting production.
New customers: get a cost-effective RDBMS solution from a
reliable major vendor; true client/server solutions are less
expensive than single system solutions, have higher
availability, better scalability.
Digital wins by leveraging our expertise in networking and
system integration, by using NAS capabilities and products.
What are your resources:
Base Product Marketing contact: Ned Berube, DTN: 223-0332,
MASADA::BERUBE.
Partner with the RDBMS vendor! Oracle has a dedicated Ultrix
sales support team which will help you to work on the proposal
(call Digital BPM for contacts at Oracle).
Notesfile: BELFST::Oracle_on_unix
The configration sheets which detail 17 possible Oracle
client/server configurations, each with a list of required and
optional software from Digital and Oracle, and recommended
Digital hardware configurations.
System configuration sheets are available in POSTSCRIPT and DDIF
and can be copied from
LEDDEV::disk$user16:[public.branch]oracle_pic.ps and .doc
2 Selling DECsystems as Platforms for Client/Server Relational
Data Base Systems.
2.1 Introduction
The Relational Data Base Management System (RDBMS) market
continues growing at a rapid pace (40% in 1990), because of
continued customer demand. Unix systems have become the
largest and the fastest growing RDBMS platform.
Successful penetration of the RDBMS market is critical for the
success of the DECsystems. Preservation of the installed base of
the existing VAX customers is critical for DEC's overall survival.
This paper gives several recommendations on how to successfully
position DECsystems in existing VAX accounts, and in new
account opportunities, using Digital's strengths in networking
and distributed processing.
2.2 Client/Server Architectures and RDBMS Vendors
RDBMS products from the leading vendors are evolving towards
client/server architectures, allowing distribution of functions
across multiple processors in a networked environment.
Oracle is the leading RDBMS vendor in the Unix market. With a
commanding 53% market share*, Oracle has been particularly
effective in promoting the client/server architecture of its
products. Oracle is also the largest independent RDBMS vendor
overall, with over $1 Billion in revenue.
The following examples concentrate on selling DECsystems
running Oracle RDBMS. However, similar configurations can be
used with other RDBMS products, such as Sybase and Ingres
(Ultrix/SQL) (and possibly other vendors which provide similar
capabilities).
2.3 Oracle Client/Server Architecture
Oracle implementation consists principally of the CLIENT
process, which communicates with the user via an application
interface, and a database SERVER process, which executes the
inquiry/update requests presented to it by the client process.
* IDC estimate
These processes may reside on the same processing system or
on separate networked processing systems. In the latter
case, connection is maintained using Oracle's SQL*net
product, which is in turn linked to the network drivers.
These drivers are sometimes supplied as part as the
operating system, sometimes are supplied with the Oracle
SQL*net product, and sometimes need to be purchased and
installed separately.
The client/server approach allows system designers to
execute tasks in the parts of the computing environment
best suited for their best performance. The CLIENT
process, which provides the user interface, tends to be be
compute-intensive; and also needs to reside close to the
user. Often, the actual interface is provided by
applications other than Oracle. These applications often
use Graphical User Interfaces such as MS-Windows and
Motif.
The SERVER process performs the retrieval or update of
data in response to Structured Query Language (SQL)
requests submitted by the CLIENT process. SERVER processes
tend to be I/O intensive, and require high degree of data
availability and integrity from the underlying system.
2.4 Advantage of Distributed Client/Server RDBMS
Architecture
Distribution of CLIENT and SERVER processes across separate
networked processors achieve several benefits:
a. CLIENT process is close to the user. This
achieves better response time for the
graphics-intensive user interfaces.
b. Users with different desktop devices (terminals,
PCs, workstations, X-terminals) can share a
common database, while maximizing the advantages
of their desktop platforms;
c. CPU-intensive CLIENT processes can be deployed
on machines with lower cost per MIP.
Off-loading this processing allows the Data Base
server system to support more users without forcing
an expensive system upgrade or distributing
physical data base across several systems.
d. Separation of application-specific processes
from the Data Base server process increases
overall system availability, since most software
failures occur in the applications.
The client/server architecture is demonstrated on the
Diagrams 1 and 2, for single system and multiple system
imlementations, respectively.
Single system implementation
<-------------server--------------------->
------------------------------
| shared global area (SGA) |
| |
| ------------ |
CLIENT <-------> SERVER <---------->|DB_buffers| |
PROCESS PROCESS | | | |
| | /------------ |
| ------/------/\---------------
| / |
user / |
/ |
\/ \/
DBwrite Logwrite Pmon Smon Archive
|
| <---------server functions----------->
\/
disk
Diagram 1
Networked Implementation
<----client->| <------------------server---------------------------->
|
| ------------------------------
| | shared global area (SGA) |
| | |
| | ------------ |
CLIENT | SERVER <------------------>|DB_buffers| |
PROCESS | PROCESS | | | |
| | | | /------------ |
SQL*Net | SQL*Net ------/------/\---------------
| | | / |
network | network / |
driver | driver / |
| | | \/ \/
|-------------| DBwrite Logwrite Pmon Smon Archive
network |
connection | <-------Server Functions-------->
\/
dis
Diagram 2
2.5 Digital's Systems: Picking the Right Hardware
Platforms for Customer Needs
By offering a broad range of system platforms which can
be networked together for a complete Data Base solution
Digital is abdle to optimize components of the system to match
the user environment.
Two types of processors are involved in the client/server
configurations:
2.5.1 The Data Base Server
The Data Base Server contains the physical Data Base and
executes the Data Base SERVER processes, as well as other
"housekeeping" functions (journaling, back-up, revision
control).
It is characterized by requirements for large amounts of
Mass Storage and high I/O performance. The Data Base
server also requires a high degree of system stability,
data integrity, data back-up, and recovery functionality.
VAX/VMS systems are optimized for the use as Data Base
servers, providing large data storage capacity, system
recovery features of VMS, and reliable data storage. For
customers interested in all-U*ix solutions, the DECsystem
5500 provides large amount of Mass. Storage, and high I/O
throughput. Most RDBMS products supply journaling and recovery
features for Unix systems.
2.5.2 The Data Base Client
The Data Base front end supports the physical user
interface and executes the Data Base CLIENT processes. It
also runs user-specific applications. Data Base front end
implementation depends on the type of a desktop device.
a. Display-only desktop device.
Character cell terminals, X-terminals, or PCs and
workstations used only for terminal access fall in
this category.
These types of desktop devices are connected to an
Application Processor (as shown on Diagram 3);
the Application Processor executes the application
which provides user interface, as well as the RDBMS
CLIENT process.
The APPLICATION processor in turn communicates with
the Data Base server to retrieve and update data.
"Non-intelligent" Desktop Device
Other Data Bases
|
|
|
-------------------------------- ------------------------
| Application server | | Data Base Server |
| | | |
| RDBMS CLIENT PROCESS | | RDBMS SERVER PROCESS |
| | | | | | |
| User application SQL*net | | SQL*net |
| | | | | | |
| User Interface Network | | Network |
| | Driver | | Driver |
|_______|_______________________| |_______________________|
| | |
| | |
----------- ----------------------------
| Desktop | Network Connection
| Device |
-----------
|
User
Diagram 3
b. Intelligent desktop device.
Intelligent desktop devices (DOS, OS/2, Macintosh,
Unix, VMS workstations) support Graphical User
Interface, and execute user applications as well as the
RDBMS CLIENT process (shown on Diagram 4).
In this configuration, desktop devices communicate
directly with the Data Base server to retrieve or
update data.
Intelligent Desktop Device
Other Data Bases
|
|SQL*Net
|SQL*Connect
-------------------------------- ------------------------
| Intelligent Desktop | | Data Base Server |
| | | |
| RDBMS CLIENT PROCESS | | RDBMS SERVER PROCESS |
| | | | | | |
| User application SQL*Net | | SQL*Net |
| | | | | | |
| Graphical Network | | Network |
| User Interface Driver | | Driver |
|_______|_______________________| |_______________________|
| | |
| | |
User ----------------------------
Network Connection
Diagram 4
3 Data Base Front End Solutions
3.1 Character Cell Terminal Configurations
DECsystem 5100 is recommended for "front ending" large
numbers of VTxxx style character cell terminals. It was
designed for time sharing configurations, and can support
large numbers of terminals connected to interactive
applications, providing the user interface. An interface
could be supplied by Oracle (SQL*forms, Easy*SQL, etc.), or
written by the customer or a 3rd party using Oracle CASE
tools. User application and the run-time copy of the Oracle
RDBMS reside on the DECsystem 5100, and communicate with
the Oracle Data Base server using SQL*net facility.
The actual number of terminals supported by each DECsystem
5100 is determined by the specific application; up to a 100
terminal users can be supported under light-to- average
loads.
Physical terminal connections: first 12 terminals can be
connected to the DECsystem 5100 directly (using the DHT80
asynchronous 8 port option); additional terminals can be
connected via
Ethernet and DECservers, using LAT protocol for maximum
efficiency. Use the DECserver 90L Terminal Server for the
lowest cost solution.
Note: if split-screen functionality is used, the total
number of screen log-ins needs to be counted
as number as users.
3.2 X-terminal Configurations
X-terminals (DEC's and others) can provide a Graphical User
Interface (GUI), while the application processing is
performed by a shared system. DECsystem 5100 is the recommended
applications processor which executes application code
displayed on the X-terminals. Theses applications are
typically developed with the use of Windows development
tools available from Oracle and other vendors (eg, Ingres
Windows 4GL).
As in the previous case, the run-time copy of Oracle RDBMS
is deployed on the DECsystem 5100 application server, and
communicates with the Oracle RDBMS on the Data Base Server
system using the SQL*net facility.
Actual numbers of X-terminal users supported by the
DECsystem 5100 application server depend on complexity of
the application; approximately 20 users can be supported
under "average" load.
Note: X-terminals are often used to display multiple
character cell screens.
In this environment X-terminal configurations are
analogous to those of the character cell terminals, with
total number of screens counted as number of users.
3.3 DOS Workstations
DOS workstations can execute the MS-DOS version of Oracle
RDBMS. User applications can be developed to take
advantage of a graphical user interface (GUI) such as
(MS-Windows 3.0), using one of several MS Windows Data Base
development tools available on the market.. The user
interface may also be provided by an existing DOS
application (for example, Lotus 1-2-3 or Excel), which is
in turn connected to the Oracle RDBMS.
DOS workstations can be connected to the Data Base server on
RISC/Ultrix, VAX/Ultrix, or VAX/VMS systems using PATHworks
for Ultrix or VMS, PATHworks for DOS, together with Oracle's
SQL*net for DECnet or TCP/IP on the respective systems.
The SQL request rate and the physical Data Base size (but
NOT the overall number of DOS workstations) determine the
type of a Data Base server employed: for a smaller number
of active users, DECsystem 5100 is a good server; for
larger numbers of active users, DECsystem 5500 or a VAX/VMS
system can be used.
3.4 OS/2 Workstations
Although OS/2 has been rapidly losing ground to MS Windows
3.0 in the last several months, it is still popular in some
accounts (primarily IBM dominated ones).
Client/server configurations including OS/2 workstations
and RISC/Ultrix, VAX/Ultrix, VAX/VMS Data Base servers can
be put together using Oracle for OS/2, SQL*net for OS/2,
Ultrix or VMS, and PATHworks for OS/2 and Ultrix or VMS.
Note: DECnet is the only protocol supported by PATHworks
for OS/2.
3.5 Macintosh workstations
Using Macintosh Oracle clients with an Ultrix Data Base server
requires a third party interconnect product. Several
configurations are possible: Oracle SQL*net for Macintosh can use
either a direct Ethernet interface and a TCP/IP driver, or
an AppleTalk interface, and an AppleTalk/Ethernet Gateway.
See the system configuration sheets or contact Oracle for
details.
Connection of Macintosh clients to a Data Base server on a
VAX/VMS server can be established using PATHworks for VMS
and PATHworks for Macintosh products. We expect similar support
to be available for the Ultrix systems within this fiscal
year.
3.6 RISC/ULTRIX DECstation or VAX/VMS VAXstations
DECstations and VAXstations can implement Oracle RDBMS for
Ultrix or VMS, and execute a user application using Motif
or DECwindows interface, and a Data Base CLIENT process.
Connections to the Data Base server on Ultrix or VMS
system can be accomplished via SQL*net for Ultrix or VMS,
DECnet or TCP/IP. The selection of the Data Base server is
once again determined by the SQL request rate, and by the
Physical Data Base size, NOT by the number of
workstations.
4 Data Base Server Selection
Selection of the Data Base server is determined by sizing
and by the type of equipment
already installed.
4.1 Existing Digital/Oracle Customer
In the case of an existing VAX/VMS or VAX/Ultrix customer
using Oracle, the typical problem is deteriorating
performance due to increased workload (more users or more
complex applications). Customers are reluctant to invest in
a costly system upgrade, especially in view of strong
negative message delivered by our competitors (H-P, SUN,
IBM, Sequent, etc.) about the poor cost/performance of CISC
VAX systems. In reality, the cost/performance of the Data
Base Server function on a VAX system is quite reasonable;
the objective is to off-load the CPU-intensive front-end
functions onto RISC/ULTRIX systems with higher CPU
performance.
Improving performance of the existing VAX server by adding
DECsystem 5100 Application servers to customer
configuration protects customer investment, and helps to
achieve the higher throughput goal with a minimum of
expense and disruption of existing operations.
It may also answer the mandate to go to "Open Systems"
without replacing the existing VAX/VMS system.
4.2 New Customer
For a new customer,a combination of DECsystem Application
server can be proposed with either a DECsystem or a
VAX/VMS database Server. The choice of server is largely
determined by the customer's attitude towards Unix vs.
"proprietary" (ie, VMS) systems: DECsystem 5500 server can
be proposed to customers determined to buy an all-U*ix
solution, VAX/VMS Server can be proposed to customers more
concerned about system and data availability and recovery.
From a pure cost/performance standpoint, a combination of
DECsystem 5500 Data Base server and DECsystem 5100
Application server is the best alternative. This
combination also allows the DECsystems to compete in the
higher end of the Data Base Market, currently dominated by
Sequent/Pyramid, by offering cost/effective configurations
capable of supporting hundreds of users.
The Oracle_on_Unix Notesfile references several "wins" over
the "supermini" vendors using this Digital topoogy.
4.3 Data Base Servers for PCs
There is increasing evidence that U*ix Servers are becoming
a platform of choice for
customers implementing production Data Base applications in
PC workgroup environments.
The original configuration of choice included DOS clients
and an OS/2 Data Base server; as the requirements for
server performance, functionality, and system stability
increase, customers turn to U*ix systems as Data Base
servers.
Digital offers two hardware platforms for PC Data base
server deployment: DECsystem 5100 can be used as a server for
small/medium PC work-groups; DECsystem 5500 can be used for
larger work-groups. The need for a larger system is dictated
primarily by the physical Data Base size.
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 988.1 | Can't quite digest the flowery prose | SWAM2::MCCARTHY_LA | Now, don't get me wrong, but... | Mon Sep 23 1991 22:06 | 5 |
| Forgive me, I didn't bother to read all 660+ pages.
You're telling us all how to sell Oracle.
Is that right?
|
| 988.2 | we need a U*IX-based PC LAN server | MBALDY::LANGSTON | The secret is strong ears. | Tue Sep 24 1991 00:49 | 31 |
| Larry, Larry, Larry,
Don't be such a pessimist :-). I'm sure Bob posted that only so that
we would see just how much competition Rdb has and that it's even being
aided and abetted from within.
Our story is wearing a little thin, however, on the U*IX side of the
fence. I posted a note in the ULTRIX/SQL conference last week asking
how I can configure "our" ULTRIX-based relational database engine to
serve a PC LAN. As of a few minutes ago, six days later, guess how
many replies there are to my request?
You guessed correctly if you guessed "0." If one reads through 988.0,
and does so without a "jaundiced eye," and I must admit that I have a
difficult time doing so, one might conclude that Oracle has a decent
solution where we have none: a U*IX-based relational database server
for a PC LAN. And they have a MS-WINDOWS-based access tool for the
desktop. Too bad DECquery can't access ULTRIX/SQL, except maybe
through some back-asswards ULTRIX/SQLACCESSFROMRdb/VMS product, which
requires a VAX.
These battles are going to grow in number and, until VAX/VMS gets
price-competitive with U*IX and/or people appreciate that POSIX
compliance is really open, we will continue to lose as long as we try
to force-feed our customers expensive VAXes, where they perceive a "hot
box" with an ORACLE or (Syabase) SQL Server engine to be the perfect fit.
If you detect a bit of a flame in this reply, you're correct. (You
know it's not directed at you , though, Larry.)
Bruce
|
| 988.3 | It's a big problem... | HGOVC::DEANGELIS | Momuntai | Tue Sep 24 1991 05:58 | 29 |
| � <<< Note 988.2 by MBALDY::LANGSTON "The secret is strong ears." >>>
� -< we need a U*IX-based PC LAN server >-
� These battles are going to grow in number and, until VAX/VMS gets
� price-competitive with U*IX and/or people appreciate that POSIX
� compliance is really open, we will continue to lose as long as we try
� to force-feed our customers expensive VAXes, where they perceive a "hot
� box" with an ORACLE or (Syabase) SQL Server engine to be the perfect fit.
Is the problem price or openness? As far as price is concerned...
Isn't this what Advantage VMS or the NAS kits are supposed to fix? I see this
as being more of a marketing problem than software. If we could supply a 'hot'
VMS box running Rdb for the same price as the Sybase or ORACLE server say on
a Unix box, would we get the business? If so, then this is something we
should be telling Demmer.
If the problem is openness, then we have a problem. Digital as a company is
not perceived as 'open'. Why would we then sell open solutions? We have to
change our image, and our product set to achieve this. Changing the latter will
change the former. Also working harmoniously with complimentary solution
vendors (including Oracle) would help us promote this image. I believe we are
travelling along this path, but whether it's quick enough only time will tell.
I don't agree that writing gateway software between our two db engines is the
way to go. We need a portable SINGLE db engine, a portable integrated toolset
that works with that engine, and ORACLE/Sybase/Informix. Forget about wasting
resources getting non-profitable products to work together.
John.
|
| 988.4 | | NSDC::SIMPSON | Sit 'n' Bull | Tue Sep 24 1991 21:06 | 6 |
| A note to complement -.1
I've never known Oracle to be complimentary about Digital!
:-)
Steve
|
| 988.5 | Can/will we be price competitve *and* open? | MBALDY::LANGSTON | The secret is strong ears. | Tue Sep 24 1991 22:04 | 42 |
| If what I'm reading in Sept 15 Digital News about our end-of-month announcement
is true, then a 17-VUP "stripped-down [VAX 4000] Model 500 [at a] list
price of approximately $120,000" is still not price competitive, compared to
a 27-MIP DECsystem MIP 500-200 for $25,000.
As for Open: if we can get the message to our current and potential customers
that our definition of open is the "correct" one, then we should have an easier
time convincing them that VAXes are "open."
So you're on the edge of your seats, wondering just what our definiton of open
is, are you?
Well, as I understand it, a POSIX-based application-centric model allows the
customer more flexibility than a U*IX-based operating system-centric model.
"Ours" "Theirs"
User Network User Network
Interface | Data Interface | Data
\ | / \ | /
Application Operating
System
/ | \ / | \
Languages | Documents Languages | Documents
System System
Platforms Platforms
This is right out of the "Open Systems: The Solutions For The '90s" presentation
that all sales management received. The package included "VAX/VMS Systems:
Strategies For The '90s." They summarize our differentiating (i.e. non-U*IX)
open systems strategy. I recommend that we all get the presentations from our
managers and learn 'em.
Does this make any sense?
Then all we need is the multiplatform database that's POSIX-compliant, and we
have the right open story. Wake me from my dreamy slumber when it's reality.
:-) :-) :-) :-)
Zzzzzzzzzzzzzzzzzzzzzzzzzzz,
Bruce
|
| 988.6 | Warning, emotional response follows. | ALFAI::HENNESSY | John Hennessy, DTN 385-2476, ALF | Wed Jan 22 1992 03:57 | 28 |
| There are several problems. We (Digital) see the vast, diverse, market
out there and we're attempting to compete everywhere. Part of this is
due largely to corporate vanity: we KNOW we've got the right plan, it
just isn't fully developed yet. (Unfortunately, this weakens our
actual strength.) We also think hardware (first), and go to great
extremes NOT to lose a hardware sale. We're quick to jump to Oracle
because it makes the hardware sale easy. A Vax 4000 isn't competitive
to a DECsystem? Maybe we should spend some time selling our message,
and if we fail, work on improving the delivery of that message. If we
can, via PID's, etc., convince our customer that we have the right
vision, then configuring a VAX with Rdb and ACMS (don't bid without it
- it can greatly enhance performance and provides a mechanism to talk
to everything) might not be that much out of line. Especially when you
draw the full plan out several years. The box might make a good PC LAN
server some day. (And besides, isn't the message, in .0, "use Oracle
as an intermediate solution?" If so, why not "use a VAX as an
intermediate solution." Or did I misinterpret the message in .0?) If
the message looks bleak, put on your system integrator hats and find on
non-threatening (i.e., non-Oracle) 3rd party solution. I'd rather lose
a hardware sale than provide an Oracle solution (sorry, my SI hat
covers just so much). Once they're installed, we're out. Lost an
account for the price of a comodity box. Plus they've got another
Oracle over Rdb reference to use against us in more traditional VAX/Rdb
situations. If we want to compete for the database, let's compete. If
not, let's quit wasting our time (and money).
Sorry for the flame, but this "Oracle is our friend" nonsense chaps my
hide.
|