Conference ulysse::rdb_vms_competition

�                      <<< Note 1245.0 by ODIXIE::SHARMA >>>
�                          -< ORACLE7 - Where Is Rdb? >-

�Any comments, anyone....

DEC Rdb performance figures for AXP are in the works, be patient.

There are two things to say here.  First, the corporation is making
available benchmarking systems to all database vendors for obtaining and
then publishing performance numbers.  We do not merely want to be the
fastest system out there running one relational database system, we
want to be the fastest for ALL relational database systems.  That means,
we want ALPHA to be the best place to run your ORACLE applications, your
SYBASE applications, your INFORMIX applications, as well as your Rdb
applications.  Programs are in place not only to make that fact, but to
let the world know about the results.  Some of those programs are painful
to DEC database people because they not only help DEC compete against HP,
SUN, IBM, etc. they also help ORACLE, SYBASE, etc. compete against Rdb to
a certain extent.

Second, the hardware people set an announcement date which required
that TPC-A testing start on March 1.  They felt extreme pressure to get
out a TPC-A number ASAP since competitors were using FUD to indicate that
ALPHA wasn't a good commercial machine.  For various reasons the hardware
announcement plans did not mesh with our engineering or marketing plans.
Since Oracle was ready, we were quite happy to see them go first and help
Digital make ALPHA look good.  Had Oracle not been ready, we would have
screwed up our plans to make sure that the hardware group had numbers for
their announcement.  As of right now, we are happy with how things
are working out.

As Kathy says, Rdb testing is underway and results will be made available
in a few weeks.

    Yes I see.
    
    We are a hardware company first and last.  We had Rdb on Alpha first
    and provide benchmarks last.  
    
    Thank you for making the job of selling the high margin software and
    services a success.  
    
    Hardware is the %^#% King at Digital.
    
    When will software dump this hardware low margin world?
    
    

    Re .3
    
    	I agree whole-heartedly. Hardware is becoming cheaper by the red
    cent. Our edge has always been software. We have licensed ALPHA chips
    to  Mitsubishi with a carte-blanche to produce their own variants. The
    reason VMS was sold so well was less of hardware, more so because of
    the ease of use. 
    
    On one hand we are part of the OSF, on the other the leading software
    vendor image is in jeopardy because we have other vendors making
    inroads into "our" area of expertise. If we put our many "feet" into
    many "boats" the whole system is "unstable", there is no "metacenter"
    at all to give us any stability.
    
    Re .1
    I'll wait patiently for the numbers. My goal is not to help produce
    the fastest Rdb on earth, but provide an image of a very good 
    technology and services provider who can really "help" customers.
    
    .Tushar.
    	

    I think the Alpha people did exactly the right thing here. If Oracle
    were ready with their benchmarks and RDB weren't then too bad. They
    correctly went ahead and published the Oracle benchmarks.
    
    But this doesn't say much for the RDB folks. Or is this a clever plot
    to wait and see what the Oracle benchmarks were and then a few weeks
    later publish RDB benchmarks that beat the Oracle ones. I truly hope
    this is the reason otherwise a full heartedly agree with the noter who
    said the present situation is just making software and services hard to
    sell.
    
    Dave

You may not know all the facts.

For example, there are several development groups in Database Systems that have 
*no* Alpha systems, despite having requested them some time ago.  The Rdb group 
has a few Alpha systems, but is not exactly replete with them, either.

When customers and (particularly) ISVs have precedence over our own software
engineering groups when it comes to obtaining Alpha systems, you get predictable
results.   Yes, as a previous reply said, we are a hardware company.  Don't 
expect that to change any time soon.

And despite all of this dearth of Alpha resources, the Rdb group has, by all 
accounts, done an outstanding job of keeping on their very aggressive Alpha 
schedule, while concurrently juggling countless different versions.  The 
pressures on them are enormous.  They don't need any more.

Bryan

re .6:

Bryan is wrong.  The Rdb group is awash in ALPHAs (compared to any other
layered software group in the company).  The rest of DBS is not so lucky.
Now disk drives, that's an area where Rdb is weak and has an impact on
things like performance tuning.  But that is irrelevent.

There was definite strategy behind Rdb not being "ready", although it
wasn't "let's not do anything until Oracle's numbers are out."  I'll be
happy to share that strategy more publicly once disclosing it wouldn't
jeopardize it!

Hal

I thought that Rdb benchmarks might take a while on Alpha because ACMS would have 
to be on Alpha first.  

It is a little embarrassing for 3rd party databases to be announcing the first 
TPC numbers on Alpha VMS systems.  Potential customers may question whether
Rdb is truly the RDBMS with the tightest VMS integration. 

RE: .7:

Sorry if I mislead. I was merely trying to give an example to show Dave that he 
might not be privy to all the facts. 

I thought that at one time even the Rdb group was not exactly replete with Alphas,
when they needed them.  I was aware of a fairly recent shipment of Jensens, but 
that was pretty recent.  I certainly did not think that the Alpha hardware 
situation was (yet) 'luxurious', even for the Rdb group.  
 
The lack of Alphas in the rest of DBS engineering (even those groups that ship on 
the Rdb kit) is still pretty disturbing to me, so my comments there still stand.

Bryan

.8:

The lack of ACMS is indeed a problem and it would be convenient to just
"blame" that factor.  The reason the 3rd parties don't care is that they
just run ACMS on the VAX side and use their own remote protocols to talk
from the ACMS procedure server on the VAX to the database engine running
on the ALPHA (yes, in the ORACLE test the DEC 10000-610 is front-ended by
VAXen).  With Rdb V5.0 or V5.1 you would indeed have to wait for ACMS in
order to run TPC-A on ALPHA and get reasonable performance.  The reason
for this is that what makes the "use the database systems remote
protocol" work is that ORACLE (or SYBASE) invoke a multistatement
procedure on the back end with a single RPC-like call.  Rdb has
historically not done multistatement/stored procedures because we relied
on ACMS tasks to give us equivalent capabilities.  So using an Rdb
program to access a remote database entails a whole bunch of RPC-like
calls between the application and the database system.

Obviously we have to wait for ACMS to become available on ALPHA or
implement multistatement procedures.  Since V5.1 has the start of
multistatement procedures (but not enough to get us down to a single
RPC-like call) you can guess one of the things we've been up to.

Hal

Hal has been doing an excellent job of describing issues and providing 'clues'
as to what has happened over the last few months, reread his entries carefully
and you'll find answers to most of the questions posed in this topic.

One of the reasons we have to step carefully here is we haven't officially
audited any numbers yet. This is a detailed, complicated task, any number of
things can go wrong, an audit usually takes 3-4 weeks. Until we have the
official audit we won't be able to confidently provide numbers to a large
audience. 

Anyway, here's a few more details, I hope this will clarify some issues:

It was important for Digital to release the Oracle number, 258 tps, 
because that was a direct comparision to an Oracle/HP number, which was
something like 186 tps. So theoretically, this is a comparison of the
two hardware platforms because the software is the same for the two tests.

Lack of ACMS on Alpha was a problem for Rdb tpc-a testing, but it's not anymore.

We hope to have an Rdb TPC-A number by early May. 

Again nothing is official until we audit, but we are quite pleased
with our progress.

From 1245.5:

>> But this doesn't say much for the RDB folks. 

I beg your pardon!

-peter

    Can we expect a note here sometime during the week of May 4?


    - Barry

Yup, that's the plan.

RE: FHOPAS::ECGLD3::STEWART

>    We are a hardware company first and last.  We had Rdb on Alpha first
>    and provide benchmarks last.  

The Rdb dev. group exceeded many group specific and corporate goals 
over the past year.  Yes Rdb was first on Alpha and can run on 
Alpha/VAX clusters and ...  the goal was to get the product out and 
running with 100% of the features, 100% correct with reasonable 
performance.  This was done without any schedule slips and completed months
earlier than the corporation planned.  In fact, I'm sure that although 
it is a good feather it our cap and story for DEC db oriented people 
the DEC SI people probably are still going crazy because of holes 
caused by the lack of other products that are not 'there yet'.

The next (about third on the list) goal was to make it perform at 
industry leadership levels. 


RE: SMAUG::GARROD

>    I think the Alpha people did exactly the right thing here. If Oracle
>    were ready with their benchmarks and RDB weren't then too bad. They
>    correctly went ahead and published the Oracle benchmarks.
>    
>    But this doesn't say much for the RDB folks. Or is this a clever plot
>    to wait and see what the Oracle benchmarks were and then a few weeks
>    later publish RDB benchmarks that beat the Oracle ones. I truly hope
>    this is the reason otherwise a full heartedly agree with the noter who
>    said the present situation is just making software and services hard to
>    sell.

Really, when you consider that the original plans for releasing Alpha 
performance numbers was September, 1993 yup we were ready.  When the 
corporation shifted its desires to an earlier date then we pulled in 
everything.  As one of the small group of people that worked on the 
performance enhancements for this release I'd say pulling in planned 
date by 6 months or so in a 12 month development cycle says a LOT for 
the Rdb folks. Yup the Oracle people were ready to benchmark first but 
we still had a few quirks to work out.  It wasn't a plot it just 
happened that way.  Now if we could only market a release like '7.0' 
for years without delivering a bit of code as good as our 
competition...

-Jay

    Just read this from an internal memo...
    If needed, I'll put in an acknowledgement for the name of the person
    who sent this memo.
    
Subject: FYI:  Standish Group's Comments on Oracle7 TPC-A Test Results

MAYNARD, Mass.--(15-APR-93 BUSINESS WIRE)--In an address to the Transaction
Processing Performance Council (TPC), The Standish Group International,
Inc.'s chairman, Jim Johnson, told the TPC that some of the latest
TPC-A Benchmark results are, in our opinion, not only invalid, but
seriously misleading.

Specifically, the recent audited TPC-A benchmark results offered
by IBM, HP, DEC, and others using the ORACLE7 RDBMS with the newly
introduced "discrete transaction" option serve to discredit TPC-A as a
viable commercial systems benchmark.

Last August, Oracle announced the ORACLE7 RDBMS.  ORACLE7
implements a poorly documented, special transaction model option known
as the discrete transaction model option known as the discrete
transaction.  Discrete transactions bypass many of the integrity
features and general functionality of ORACLE7, and significantly cuts
the processing "path length" of the transaction.

Curiously, the integrity features remaining in the discrete
transaction option are those just sufficient to execute the TPC-A
benchmark test - a notoriously undemanding test.  The Standish Group's
research indicates that this limited functionality option could be used
by very few, if an, users developing production applications.  This
being the case, The Standish Group believes that the discrete
transaction was implemented in ORACLE7 soley for the purpose of running
the TPC-A benchmark as efficiently as possible.  The Standish Group
also believes that Oracle developed the discrete transaction option
because ORACLE7 would not perform any better than Oracle version 6 -
thus discrete transactions were implemented to provide a system bypass
and "demonstrate" dramatically improved TPC-A results.

Coincident with the ORACLE7 announcement, major hardware vendors
unveiled incredible ORACLE7 TPC-A benchmark results - using, of course,
the new discrete transaction option.  The Standish Group views TPC as
race officials and TPC-A as a stock-car race - a race between everyday,
useful, production capable transaction processing solutions.  "Oracle
built a formula one race car to run in a race that should be for stock
cars only - cars that can be used on real roads.  IBM, HP, DEC and
others drove the formula one around the track, the benchmark auditors
waved the checkered flag, and TPC presented them with the winning cup,"
said Standish's Johnson.  "All the while, Tandem, Sybase, Informix and
others were still racing their stock cars."
The TPC benchmark A, at its best, is of limited use, but it did
have some viability.  In our opinion, Oracle has now completely
invalidated its use as a comparison of heterogeneous database
solutions.  "We are advising our clients that TPC-A is no longer a
viable commercial system comparison and is completely invalid,"
continued Johnson.

Johnson further warned the TPC to clean up their act.  "With the
fall of TPC-A, the TPC has lost credibility.  With TPC-C you get
another chance - don't blow it, again," said Johnson.  Among Johnson's
recommendations to the TPC was that they adopt a code of ethics, and
establish a user review board.

The Standish Group International Inc., 295 White's Path, South
Yarmouth, MA is a research and educational company specializing in
transaction processing.


    .Tushar.

+-+-+-+-+-+-+-+
|d i g i t a l|         I N T E R O F F I C E   M E M O R A N D U M
+-+-+-+-+-+-+-+

TO: Dennis Roberson
	     				DATE:  May 3, 1993
                                        FROM:  Steve Hagan
                                        DEPT:  Database Runtime Systems
					EXT:   264 - 1705
        				LOC:   NUO1-1/F12 
        				ENET:  NOVA::HAGAN
       
cc: Chuck Rozwat, All of Digital 

SUBJ: 	Rdb is the:


		WORLD'S FASTEST RELATIONAL DATABASE!
	

	Today, Rdb achieved 302.68 TPS on a TPC-A Benchmark, on a
	AXP 7000 uni-processor. The $K/TPS is $6610.

This is the:

	FIRST Relational database to EVER achieve 300 TPS on a uni-processor.

	FIRST Relational database to have a TPC-A $K/TPS of below $7000 on a 
	mainframe or workstation. 

Thus, an

	ALL DIGITAL SOLUTION of an Alpha microprocessor, VMS, Digital compilers,
	and Digital Relational Database, results in the BEST PERFORMANCE 
	in the world, and the BEST PRICE/PERFORMANCE in the world.

	
Note also, given our competitive world, that the Rdb test was run on the 7000,
	while the recent Oracle 258 TPS test was on a 10000, a 10% faster CPU.
	So, scaling Rdb by 10% to a conservative 325 TPS on a 10000,


	Rdb is more than 25% FASTER than Oracle, in head to head competition!


Please join me in congratulating the Rdb Engineering team in this 
world class accomplishment.

Please forward this mail widely.

Thank You

Steve Hagan
Engr Manager for the INDUSTRY LEADING Rdb and DBMS database products.

Some more details:

The 302.68 tps IS an officially audited number. It has been submitted
to the TPC council.

Oracle's number of 258 tps, was on the 10000 which employs the 5.0 ns chip.
The Rdb number of 302 tps, is on the 5.5 ns chip!!!!  This is amazing.
We broke the 300 barrier on the slower chip!

There's been some confusion about the different machines.  The 10000 is 10%
faster than the 7000. So anyone in a competitive bid be real careful about
competitors performance claims. There has already been one instance where an
Oracle representative claimed their number was on the 7000!  

All our tests have indicated that when we run on the faster chip we achieve
the expected proportional increase in throughput. So as Steve Hagan indicated
in his memo, it's reasonably safe to say Rdb is 25% faster than Oracle.
We will have this specific data some time in the future. 

A super-important fact:

We did not resort to any TPC-A 'specials' (ala discrete transactions) 
to achieve this number. All features and optimizations used will be widely
encouraged and will deliver better performance for the proper applications.

-peter

	Well, congratulations to the Rdb and the Performance Team for
	this excellent result!!

	Now, only if we can get the usually lethargic marketing folks to 
	use this result. 

	I mean, nothing less than a 2-page ad in the Wall Street Journal
	would do to announce this. 

	I've seen great engineering work being dissipated by marketing so
	often, that it's no longer amusing. 

    Amitabh,
    
      As a one of the former database marketing folks whom you've labeled as
    "lethargic", I must ask for clarification.  At what level of marketing
    are you directing your concern?  Is it corporate marketing and
    advertising or the product marketing efforts that dismay you?  Is your
    disappointment based on the recent past, today's efforts or some
    historical data prior to the reorganization?
    
      As you  know the DB product marketing group was reduced to three
    people and combined with TP marketing into a production systems
    marketing group.  I can not speak for the former TP or today's
    Production Systems Marketing group.  However, I can speak for the
    former database marketing group and those individuals who are still
    doing db marketing.  
    
      I would challenge you to find a group of individuals who got more
    mileage of their small marketing budget in terms of creativity, field
    support and training, and as much advertising as permitted by the
    corporation.
    
    Bob J.

	Re. .19

	Bob,

	My frustration is with all of DEC marketing, of which TP and DB 
	marketing are a part. 

	My benchmarks for the success of marketing are simple:

	1. look at the trade rags for advertisements of TP and DB products.

		- first, look at the sheer number of ads by Oracle and Sybase,
		the two biggest competitors of Rdb on VMS. My unscientific
		observation says that Oracle beats Rdb 100:1 in number of
		ads, Sybase probably beats Rdb 60:1. 

		- Look at those ads and see who they are comparing themselves
		against. Oracle compares itself with Sybase, or others. 
		After the TPC-B cluster result war (Fall 1991), I have not
		seen Oracle ads comparing themselves with Rdb

		- a company like IBI has more ads in these trade rags in one
		month than all the ads of all DB products combined in one
		year. 

	2. Look at the number of ads by, say, HP in the Wall Street Journal. 
	They have full-page ads for even announcing new printers. Every time
	they come up with slightly better TPC results, they invent categories
	in which they would be the best and publicise them widely. 

	3. Look at the discussion on newsgroups such as comp.databases, 
	comp.benchmarks, etc. on Usenet. Find out how many articles are
	devoted to Rdb vs. how many for Oracle, etc? Same goes for a product
	like ACMS. Most people on Usenet, or most discussions in trade rags
	talk about CICS, and Tuxedo, and Encina. They do not even give a lip
	service to ACMS. 

	4. I can say the same thing about non TP DB products, say even Alpha
	machines. How many ads have you see besides the Wright Brothers one?

	To me, this indicates that something is clearly wrong about the 
	DEC products, and in my experience as a user of these products, it is 
	not the engineering aspects, i.e., lack of functionality, poor
	performance, etc. Our products simply do not have the name
	recognition. No marketing to speak of. 

	Clearly, I'm not the only who observes these things. Many of my 
	colleagues in TP and DB engineering feel the same; most are less
	vocal than I am. Someone has to scream at the higher management to 
	provide more funds/more innovative marketing teams than what we 
	currently have. 

	IMO, the status quo clearly sucks!!

	Enough said. 

    re: last few...
    
    As Bob indicated a few replies ago...DBS Marketing WAS very good. 
    Although this was now a year or two ago Rdb had running adds in the rag
    mags and lots of interest.  Now a few reorgs and corporate policy
    changes later DBS is down to 3 people bound by various edicts on what
    can /can not be done.  As a engineer in DBS for the past 7 years I can
    not say enough about what WAS the DBS Marketing group.  I only hope
    that the new organization can hold a candle to the past accomplishments
    with the current "rules".
    
    -Jay

    Well as one who criticised in an earlier reply I'd now like to say.
    "Great work". It's really nice to see that RDB is better than Oracle.
    And as pointed out in a previous reply I hope this feat can be used.
    I really hope that Oracle lives to regret that they built database
    features specifically to look good on TPC-A. In the right hands that
    could be really used to twist the knife.
    
    Dave

    re: .20 - Alpha ads,
    
    As Mike Rubino and I were returning to the Airport from the Alpha road
    show, we someone across from us opened a Wall Street Journal and there
    was a nice Alpha ad on the back page of the first section. It had a
    stone wheel and I think it was about reinventing the wheel.
    
    michael

     DIGITAL EXTENDS ALPHA AXP DATABASE PRICE/PERFORMANCE LEAD,
                    ENHANCES ACCESSWORKS SERVERS


      ...DEC Rdb is first relational database to break through
   $7,000/tpsA and 300 tpsA barriers on a uniprocessor...Company 
enhances ACCESSWORKS client/server integrated data access servers...



SAN FRANCISCO, CALIFORNIA -- May 5, 1993 -- Digital Equipment
Corporation today added to the Alpha AXP platform's credentials as 
the database server of choice for computer downsizing by announcing 
breakthrough midrange price/performance and performance results on
the TPC-A Benchmark.  At $6,643/tpsA, the new DEC Rdb Version 6.0
running on a DEC 7000 Model 610 is the first relational database to
deliver production-quality database performance on a midrange server
at under $7,000/TPS.  At 302.68 tpsA, it offers the best performance 
in its class -- over 64% faster than HP's best tpsA uniprocessor 
offering. The company also delivered EDA/SQL enhancements for the 
ACCESSWORKS client/server integrated data access server family, and 
new versions of the RdbAccess product family. Further, the company 
outlined capabilities -- including enhanced support for very large 
databases (VLDB) and multivendor database integration -- that it
will roll out over the next several months as part of its ongoing
delivery of the Information Network data delivery strategy. 


    "The evidence is mounting that the Alpha AXP server is the 
server of choice for customers planning computer downsizing," stated 
Sharon Keillor, vice president of software business and product 
marketing management at Digital. "On April 6th Alpha AXP delivered 
the world's fastest sort -- establishing that AXP systems outperform 
mainframes even in areas where customers felt they had no choice but 
a mainframe. On the same day we also delivered industry-leading 
uniprocessor performance on a DEC 10000 running the ORACLE7 
database.  Today's announcement not only confirms AXP's outstanding 
performance and client/server integrated data access capabilities, 
it firmly ranks DEC Rdb on Alpha AXP as the most cost-effective 
transaction processing platform in the industry." 

NEW VERSIONS OF DEC RDB FEATURE ENHANCED MULTIMEDIA AND VERY LARGE 
DATABASE SUPPORT
    Announced today are new features for DEC Rdb Version 5.1 and 
details of DEC Rdb Version 6.0.  DEC Rdb Version 5.1 delivers 
enhanced SQL multimedia support, including performance improvements 
to support full-motion video. This capability gives an enterprise 
the opportunity to explore new ways of providing products and 
services to their customers from within the proven DEC Rdb 
environment. 
    DEC Rdb Version 5.1 also provides ODBC (Open Database 
Connectivity) support, thus making it easy for customers running 
ODBC-compliant applications to access data in a DEC Rdb database.  
DEC Rdb also takes full advantage of the recently announced mixed 
cluster environment of both OpenVMS for AXP and OpenVMS for VAX 
systems.  


Additionally, DEC Rdb Version 5.1 is fully compatible with the 
Multivendor Integration Architecture (MIA) user specification 
sponsored by Nippon Telegraph and Telephone, including 
internationalization support that makes it easy to tailor 
applications for use worldwide.  DEC Rdb Version 5.1 ships in 
August, with prices ranging from $1,130 to $349,800. 
    In addition to the outstanding price/performance and sheer 
throughput demonstrated by the TPC-A benchmark, the next major 
release of DEC Rdb, Version 6.0, will provide enhanced on-line 
back-up and new multithreaded restore capabilities that make it 
practical for an enterprise to maintain very large databases.  DEC 
Rdb Version 6.0 will ship in December 1993, with prices ranging from 
$1,130 to $349,800. 

ACCESSWORKS ADDS ACCESS TO MORE THAN 50 DATA SOURCES 
    The ACCESSWORKS family of client/server integrated data servers
provides users of desktop applications easy, transparent, and secure
access to corporate databases. New ACCESSWORKS products and 
enhancements announced today provide users with more choices and 
capabilities than ever before. The new ACCESSWORKS/EDA option and 
ACCESSWORKS/EDA family of servers (ACCESSWORKS/EDA V1.0) will enable 
end-users to access more than 50 relational and non-relational data 
sources from their desktops -- more than eight times the number that 
they could previously access. 
    Featured in the ACCESSWORKS/EDA V1.0 server is the EDA store 
option, enabling the user to choose one of four databases -- DEC 
Rdb, ORACLE, SYBASE and Ingres -- to store data. That capability 
allows the user to use any desktop application the database 
supports. 


    Also announced today is ACCESSWORKS V2.0, which enhances the 
basic capabilities of the initial, or "classic" ACCESSWORKS (V1.1) 
solutions.  

ACCESSWORKS products introduced today are
    - ACCESSWORKS Version 2.0.  New features in the "classic" server 
      configuration include write access to DB2 and Oracle       
      databases, as well as support for Microsoft's ODBC client       
      driver, which enables ACCESSWORKS to support many additional
      desktop applications.  ACCESSWORKS Version 2.0 will ship in       
      July, with prices starting at $9,016. (Please see the       
      ACCESSWORKS fact sheet for more information.)

      Customers who prefer to purchase components rather than the 
      full ACCESSWORKS solution can gain write access to DB2 and 
      ORACLE databases from PCs and Rdb databases with new versions
      of the standalone products DEC RdbAccess for DB2 and DEC 	    
      RdbAccess to Oracle products.  Available in June, prices for  
      Version 2.0 of these products start at $1,408 and $1,390,     
      respectively. 

    - ACCESSWORKS/EDA Option.  The EDA Option is available as an
      add-on to existing classic ACCESSWORKS solutions. It adds
      read access to all of the EDA-supported databases.  Customers 
      choose this solution when they need the leadership 	    
      capabilities provided by the classic ACCESSWORKS solution and 
      also need to be able to read data stored in EDA-supported 
      databases, typically for decision support applications.  
      ACCESSWORKS/EDA Option will ship in July; prices for the 	    
      add-on option start at $13,379. 
     
    - ACCESSWORKS/EDA Version 1.0.  This new set of ACCESSWORKS 
      solutions is for customers who need read access to the many   
      databases supported by EDA/SQL from multiple desktop devices, 
      typically for users working with decision support 	    
      applications. ACCESSWORKS/EDA also provides the EDA Store     
      feature, which enables users to choose one of four databases  
      to use to store their data:  Rdb, ORACLE, SYBASE, and Ingres.  
      ACCESSWORKS/EDA Version 1.0 products will ship in July in     
      three configurations -- ACCESSWORKS/EDA 4100, ACCESSWORKS/EDA 
      4600 and ACCESSWORKS/EDA 7610 -- ranging in price from $69,104 
      to $261,305.
    

    "End-users now have greater flexibility to do their jobs and 
increase their overall productivity with more access to key business
information," said Digital's Keillor.  "With the introduction of
ACCESSWORKS/EDA, customers now are able to benefit from the 
integration of applications and data across diverse databases,
networks and platforms. No other vendor can reach more data 
sources." 

 
    These new EDA/SQL-supported data source offerings for 
ACCESSWORKS customers are a result of a strategic partnership 
Digital announced last December with Information Builders, Inc. 
(IBI) of New York.  Digital and IBI will provide services and 
support for all ACCESSWORKS/EDA customers. 
    "We are pleased to be bringing the scalability and open 
architecture of EDA/SQL to ACCESSWORKS customers," said IBI Senior 
Vice President John Senor. "The combination of ACCESSWORKS and 
EDA/SQL delivers a high-quality preconfigured solution that anyone 
looking to implement client/server solutions should seriously 
evaluate," Senor continued. 

COMPANY UNVEILS NEXT STEPS FOR INFORMATION NETWORK DELIVERY
    Digital also continued the rollout of its Information Network 
data integration software framework by disclosing plans to deliver a 
very advanced multi-database integration capability.  Specifically, 
the company stated its intent to offer by the end of the year a 
product that will provide a single view of data stored in multiple 
databases in distributed locations and with multiple data formats.  
This capability will make it much easier for an enterprise to 
optimize all of its information sources.  A technology demonstration 
of this capability is running in the Digital booth on the DB Expo
show floor. 
    Additionally, the company introduced AXP versions of the 
following database products:  DEC Data Distributor Version 5.1 for 
the automatic distribution of data, which will ship on AXP systems 
in June with prices starting at $1,400; and DEC Rally Version 3.1, 
Digital's 4GL for the development of DEC Rdb applications, which 
will ship in August with prices starting at $685.


    Digital Equipment Corporation, headquartered in Maynard, 
Massachusetts, is the leading worldwide supplier of networked 
computer systems, software and services. Digital pioneered and leads 
the industry in interactive, distributed and multivendor computing. 
Digital and its business partners deliver the power to use the best 
integrated solutions - from desktop to data center - in open 
information environments.
                                ####

Editorial Contacts: 

For DEC Rdb and general database:
Chuck Malkiel
Software
(603) 881-0684
     or
Linda Pugliano
Software
(603) 881-0811

For ACCESSWORKS:
Jennifer Janson
(508) 264-5207


Note to Editors:  ACCESSWORKS, Alpha AXP, AXP, the Digital logo, DEC 
                  OSF/1, OpenVMS, Rally, Rdb, and ULTRIX are 
                  trademarks of Digital Equipment Corporation.  

		  OSF and OSF/1 are registered trademarks of the 
                  Open Software Foundation, Inc. 

		  EDA/SQL is a trademark of Information Builders, 
                  Inc. 

		  Microsoft, MS-DOS, Windows, and Windows NT are
		  registered trademarks of Microsoft Corporation.  

		  SYBASE is a registered trademark of Sybase, Inc.  
                  
		  ORACLE and ORACLE7 are registered trademarks of 
                  Oracle Corporation.  

		  Ingres is a registered trademark of Ingres 
                  Corporation.  

		  TPC Benchmark and TPC-A are trademarks of the 
                  Transaction Processing Performance Council.


CORP/93/117