Conference ulysse::rdb_vms_competition

From:	WILBRY::VOELKER      "Diane Voelker, NAS Product Marketing, 264-3899" 21-APR-1992 11:19:30.08
To:	BOB
CC:	VOELKER
Subj:	Rdb Ports to ALPHA Open VMS and ALPHA OSF/1 Press Release







    Contact:

    Brian Duggleby
    (603) 884-2423

  
              DIGITAL TO MAKE Rdb/VMS RELATIONAL DBMS AVAILABLE ON 
                      ALPHA OPEN VMS AND OSF/1 SYSTEMS


    MAYNARD, MA. -- April 21, 1992 -- Digital Equipment Corporation
    announced  today that its Rdb/VMS relational database will be
    ported to the Alpha Open VMS and Alpha OSF/1 platforms. Rdb/VMS
    is Digital's strategic relational database for mission critical
    production applications and is the  leading database on VMS,
    with over 20,000 development licenses sold worldwide.

    "Digital's Information Network strategy is to integrate
    heterogeneous data managers from multiple vendors and platforms.
    DECworld will give customers the opportunity to see the advanced
    technology that allows Rdb to integrate multiple vendors' data
    managers, residing on different platforms. By  making Rdb
    available on Alpha platforms, Digital is protecting its
    customers' investments and enhancing the Information Network for
    all present and future  customers," said David Stone, Vice
    President of Digital's Software Products Group.

    Customers who have already installed, or who are considering
    installing the Rdb/VMS database for VMS-based applications
    because of its high performance, can be assured their databases,
    tools and applications can be smoothly transitioned to Alpha
    platforms if they choose to migrate or upgrade in the future.

    "Digital has thousands of customers who rely on Rdb to run
    critical production applications on VAX systems. These same
    customers will want the ability to easily migrate their
    applications and databases to Alpha  platforms over time. Rdb
    running on both the Open VMS and OSF/1 operating systems will
    provide customers with an open production environment offering 
    industry-leading performance, functionality and
    cost-effectiveness," said David Stone.

    Digital will announce specific pricing and availability for its
    Rdb/VMS  database on Alpha platforms in the near future.
 
    Digital Equipment Corporation, headquartered in Maynard, 
    Massachusetts, is the leading worldwide supplier of networked 
    computer systems, software, and services.  The company pioneered 
    and leads the industry in interactive, distributed and 
    multivendor computing.  Digital and its partners deliver the 
    power to use the best integrated solutions - from desktop to 
    data center - in  open information environments.
         

                                ####

    Note to Editors:  Alpha, Open VMS, Rdb/VMS, VAX and VMS are 
    trademarks of Digital Equipment Corporation.


    CORP/93/



         
         

>
>                       -< What happens to RdbStar now? >-
>

	And does Rdb/VMS still get called Rdb/VMS or does
	it become DECRdb?

	Barry

	From a customers point of view, Rdb/OPEN (My suggetion) will still be 
	propitary compared to Oracle, Sybase, Ingres etc. because it will only 
	run on the ALPHA platform.

	I also think this is to late, RdbSTAR will give the customer a better
	portability (The target for RdbStar will be other then just ALPHA).

	I'm also concerned about the marketing message having to database
	products competing each other. Some marketing persons will
 	say no to that statement, but Rdb/OPEN and RdbStar will compete
	and make lot of confusion and make customers believe Digital are not 
	serious about its database strategi.

	Regards

	Ketil 

It is still too early to tell what the Rdb vs Rdbstar relationship will
be vis a vi positioning.  Pointless to speculate right now and this isn't
th forum for it anyway.

Rdb naming has to be re-examined anyway in light of the VMS name change
to OpenVMS.  Given that 99% of the time the press, analysts, customers,
and even DEC people just call it "Rdb" I have a preference for a new
naming convention....but this also isn't the right forum.  In reality,
the company has naming conventions for its products and those conventions
are evolving with the move to OpenVMS.  Rdb will have to evolve
in line with those corporate conventions, which will also dictate a name
for the OSF/1 product.

	Re. .-1

	Re: only Alpha and portability

	So what if Rdb/??? only runs on Alpha ?  If Alpha is as "hot" as
	everyone says AND if the customer can pick from OpenVMS or OSF1,
	then we may indeed have a winning hand.  On the other hand, it's
	not clear how profitable even Oracle can be by porting their
	database to every toaster that comes to market.  IMO, we may want
	to be content offering the customer his choice of "server" based
	on Alpha or VAX hardware.  Then, let the customer decide what
	kind of client he wants.  RdbStar can still be the client ...
	and, more importantly, the integrator of legacy data.

	Please read Stone's comments again.  One of his reasons for making
	this decision is to preserve the "production" database market
	share we've been working our butts off to build.  In many instances,
	"production" database requirements are far different than distributed
	database requirements.  Rdb can deliver the bacon for the "production"
	aspect of the Information Network while Star can deliver the distributed
	pieces that customer may move to in the future.

	-- gerry

	  

    
    Clearly understood they are not the same beasties!
    
    Just wondering about the name?
    
    Barry

	RE .5

	My message was no speculation, but a warning if we don't give
	the marked the right message.

	Most of the customers I know who has choosen Oracle, it was not for
	Oracle's profitt, but for the availability of porting it to IBM, HP
	SUN etc. The reason is, they want to change vendor if the service
	becomes bad. Therefore OSF/1 is important, not ALPHA-OSF/1,
	even if ALPHA becomes as hot as somne believes.

	Yes hopefully, not only Digital will sell ALPHA-OSF/1, but I'm pretty 
	sure that SUN, IBM, HP won't.  And they are the competitors who are
	able to compete with us then it comes to service.

	I will not speculate more about Rdb_Star vs Rdb/VMS, but it ain't
	profitable to maintain two good database products, when we even have
	problem to get the sales people to sell the one we have today!

	Regards

	Ketil

    I had to re-read all this several times to understand what is being
    said here. I get the strong impression that either we are calling
    RdBStar  "RdB" to try to keep customer interest, or we are going to
    offer a stripped-down version of RdBStar, and call it RdB.
    
    Why ? well, from .0
                       
>Accordingly, we have been pursuing our Information Network  strategy.

    >                              The future distributed database
>technology that we  will be demonstrating at DECworld will provide a
>data management layer that  will integrate Rdb with data managers from
>many other vendors on many platforms."
    
    Clear references to RdBStar. Why, if this is a totally new product does
    David Stone start talking about what the Information Network will offer
    ?
    
    Also, how can we talk about RdB available soon in the same context as
    RdBStar being a future technology ?
    
    Any comments from someone who has actually been asked to write RdB for
    OSF ? 
    
    Rob

This is Rdb/VMS ported to OSF, not what is currently known as Rdbstar!

-Jay

    Just testing :-)
    
    Rob

I don't know exactly how Rdb will be implemented on OSF/1 Alpha, but it seems
likely that it would be technically feasible to port the result to other
U*x-like systems.  The announcement in .0 didn't say we wouldn't do that.

Still, the customer's best approach to vendor-independence is to code to
that subset of SQL that is widely implemented, or assess the cost whenever
they use a vendor's extensions.  How many Oracle users are happy to be
hardware-independent, but locked in to their software vendor?

    re:-.1
    
    This is exactly the point of all of this (and part of the NAS message).
    
    
    Make our SQL as standard as you get.  Place the database system on an
    OS that is standard and provide complete application independence. 
    This is much more than can be said by most of our competitiors.
    
    At the current time I can not comment on the rest of the Rdb/OSF port,
    but people will be made aware of what is being done when the time is
    appropriate.
    
    -Jay
    

    
    
    
    yeah! Rdb on MSDOS !yeah!
    
    Sure hope we don't burn heretics on the stake, I smell lighter fluid..
    
    
    Simon

	We have to realize that NT/ALPHA will be more important as a 
	server for small systems then OSF/ALPHA. 

	PORT IT TO NT/ALPHA TOO.

	Ketil	

Rdb, the database, embodies a lot more than relational bits, but Digital the
company and our willingness to underwrite the applications our customers
develop with it.  Our cost structure in essence underwrites a lot of sales
support people, and I expect that Alpha prices will likewise continue this
policy.  I for one was in favor of the move, however it by itself is not the
whole solution. First the problem statement:

[1] Rdb is difficult to sell vs. Oracle, Sybase, etc. since the sales org. from
    those companies are more focused/goaled.  A quick test is ask your salesrep
    the names of 5 Rdb people in their geography they can count on.  Ask 
    yourself the names of those who know Rdb, SQL and use of products like
    RdbExpert, DECtrace and/or DECps.  These are the tools we rely on for help
    when performance is an issue; our competitors blame the hardware or o/s.

[2] Rdb is a database MANAGEMENT SYSTEM - not a development tool to supersede
    ISAM as the file access method of new applications.  Consider that companies
    like Oracle, Sybase, etc. focus on the "MS-DOS" DBA, as the level of
    expertise required to use the product.  For these customers, having an Rdb
    pocket booklet would be the ideal if coupled with the graphical schema
    editor.

[3] Our customers are less sophisticated.  I've rarely ever found anyone trained
    on relational design, etc. that didn't have an IBM background.  For these
    sites, they don't consider Rdb a product, but Digital the company, and all
    the support that goes along with it. Other, new, customers, however want
    product.  They are the ones who do the spreadsheet comparisons and are 
    initially (i.e., during the sales cycle) not interested in all the full
    strength capabilities we have to offer.  They are most interested in time
    to market and portability.  They see little value in being dbms hochos, but
    more in delivering an application early, and receiving thier bonus.

What that in mind, in steps Rdb* [sic], the integrating dbms engine/environment
for the masses.  Four of our larger dbms competitors (IBM, INGRES, INFORMIX, 
and TANDEM) have tried to being such capabilties to the mark without a proper
base and certainly but not first grooming the market to the need to which they
would fill.  They (and us I'd argue) center our functionality around integrating
isolated data into a uniform information exchange to be useful throughout an
organization.  Besides being quite a technical feat, it's an enormous political
and cultural challenge.  This challenges being inhouse.

Some would argue that the market wasn't ready for DEC to change horses midstream
in their relational product, and certainly didn't want to make the same mistake
that the ACMS vs. Intact strategy did (i.e., two products in the same space).

The major issue then, was maintaining our legacy applications, the few we have
(as it is perceived by sales visa-vis Oracle, Sybase, etc.), with Rdb and get
those customers over to Alpha.  Technically speaking, wherever there's a BLISS
compiler, there should be Rdb, so long as the price structure of the product
and/or platform supports it (and we can make a little money too;-).  I'd argue
that the language the product is writtin in, is not the determing factor, but
what monies are to be made there, and is it a 'product' vs. a 'platform'. Lots
of folks see Rdb as the 'platform' and Rdb* as a 'product'.

Our major internal issue was how to empower sales to sell 1 product, across a
number of platforms and keep the selling simple.  Some have proposed selling
Rdb* as

	a) an add/on to Rdb, 
	b) EIS service offering, or 
	c) tiered   #1 Rdb* Lite == Rdb for <platform>,
		    #2 Rdb* Integrator == No DBMS engine,
		    #3 Rdb* the whole enchilada

While we may have alured the fears of many in regards to Rdb, it still doesn't
address the major issues which are:

	[1] price Rdb (or any product) for an open systems platforms from DEC
	    Alpha) vs. 3rd parties (i.e., Intel, MIPS)

	[2] what support would we provide for our s/w on hardware not supplied
	    by us - or any support; the mindset is that we're still a h/w
	    company

	[3] maturation process for the field and customers, on the global
	    issues of integration without replication, and being polically and
	    culturally achievable without being a show stopper to todays
	    applications

	[4] can we as a company develop s/w for the 3-5 year application life
	    which focus on development speed and portability and not longivity
	    of the application.

Many of these issues are not specific to Rdb, but it seems it and probably ACMS
will lead the way for many other products.  How these two products dance thru
the 90's will say a lot about our ability to support a changing customer base
and a sales cycle we are having less and less control.  At least for time being
we've simplified our selling of a relational products on OSF/1.  How Rdb*
bits get introduced into this recipe will depend a lot on what the market 
perception is for such a technology, and it a purchaseable item or mindset.

/los