Conference ulysse::rdb_vms_competition

	We do have ODBC drivers for Rdb. 

	Having the capability is only half of it (arguably less). Making
	sure that we get on those lists so that people *know* we have the
	capability is at least as important.

	Roy

	; I need to talk to someone about the problem we have getting Rdb as a
	; listed supported database by PC products. An example is the Q+E
	; product. I just got an offer in the mail and all the major databases
	; are listed as being supported. We aren't one of them!
    
Lilian Hobbs has used Excel Q+E with Rdb already.  Properly speaking I 
think that Q+E is bundled with Excel.  The doc says nothing about Rdb,
and what is says about Oracle, etal. doesn't say what's required of
the host.  I've only skimmed the docs briefly, though -- the customer
opted for Oracle's Data Browser.

Regards,
rcs

	; We do have ODBC drivers for Rdb.

It was my understanding that we only have one ODBC driver for MS-Windows,
only for MS-DOS, and only for a PC using Pathworks on a LAN.  It doesn't
work with any other vendor's TCP/IP products, nor do we have ODBC on the
host end.

Regards,
rcs

    What I need is a document which tells me what Digital has tested and
    knows works. If I have this document, I could construct a solution
    based on those limitations. However, with NO information, I can't do
    anything. 
    
    Will someone from Rdb Engineering stand up and get counted on this one?
    
    Or can you suggest someone to call?

    A database magazine in The Netherlands has compiled a "connectivity
    monitor". Imagine three vertical rows of boxes. The left row of boxes
    lists quite a number of popular PC-based tools and applications. The
    right row lists quite a number of popular databases (and yes, Rdb is
    in that list). The middle row is (you guessed) middleware.
    
    All vendors in this space have this list and are requested to draw
    lines from the PC tools, via the middleware to the databases where they
    have products. They want to do this on a regular basis, although I
    think that they will restrict the scope in the future.
    
    On the phone they already complained about IBI EDA/SQL and Q&E not
    being able to restrict the number of connecting lines.
    
    Henny

I've never understood why we weren't on Q+E's list.  I even remember
asking, but I can't remember if there was a valid answer.  Q+E is more
than a part of the MS Excel kit.  It is a separate product that customers
can purchase, plus they have a library for Visual Basic applications to
use to access various databases.  And they are heavily into direct mail
marketing, with a list of databases they connect to that includes some
database systems that have lifetime sales less then what Rdb sells in a
month.  Further, Q+E is the company the folks we bought ALLY (the basis
of RALLY) from started after UNISYS bought out their first company
(Foundation).  They have some knowledge of Rdb, and I keep hearing Q+E
actually does support Rdb, so we have clearly missed something.

Bill Beauragard, the "DB Desktop" Product Manager, is running a
reasonably aggressive program to get PC client products signed up for
testing and promotion of interoperability with Rdb (et al) through the
ODBC driver.  This effort is paying off, but is slowed by the current
state of product marketing funding.  Bill was able to buy us an add in
Microsoft's ODBC catalog, which will ship to everyone buying an
ODBC-enabled Microsoft application.  That will probably be the single
most important PC connectivity message venue for the near future.

Hal

RE: .7

I have been using Q+E LIB for the past few months, and their package contains 
a whole chapter on the details of all their supported databases.  I have read 
the entire document, and have seen no mention of Rdb anywhere.  If I recall, 
there is also a READ.ME file, but I have seen nothing about Rdb in that.

Q+E have also announced a bunch of things for their version 2 which is due 
within the next few months (and which I believe includes ODBC support) and Rdb 
was not among the databases mentioned as supported.

FWIW...

Bryan

RE: .4:

	; We do have ODBC drivers for Rdb.

It was my understanding that we only have one ODBC driver for MS-Windows,
only for MS-DOS, and only for a PC using Pathworks on a LAN.  It doesn't
work with any other vendor's TCP/IP products, nor do we have ODBC on the
host end.

	We only need one ODBC driver for MS-Windows, since it provides access
	to all Rdb and RdbAccess databases.

	ODBC is currently MS-Windows specific.  That's not Digital;  that's
	Microsoft.   I haven't even heard anything about Microsoft getting
	ODBC working on Windows NT, and you would think that Microsoft would
	be interested in making sure it works there.  Of course, it could be
	that they expect ODBC to work under WIN16 emulation, but I haven't
	heard anything on that either.  I'm talking Windows NT on Intel, here.
	I would also have thought that Microsoft would be interested in making
	it work in 32-bit mode, but I haven't heard anything about that.

	Apple is supposed to be working on an ODBC for the Mac, but I don't
	know of any dates;  it isn't available yet.

	Having no 'ODBC on the host end' doesn't necessarily mean that it's
	a problem;  since ODBC only exists on MS Windows, the availability of 
	ODBC on the host end isn't limited to Digital.  What would you expect
	'ODBC on the host end' to do for us?

	Bryan

    since SQL/Services on NT is a year out, we might as well forget RFPs for
    that market for a while.
    
    I'd love to be pleasantly surprised and hear that SQL/Services will be
    on NT sooner, pretty please? A lot of the BIG RFPs with gazillions of
    clients will probably be specifying NT on the desktop, it would be
    wonderful to be able to say "our driver and our ODBC driver are on the
    shelf and available". It would also go a long way to counter the myth
    of Rdb as a 1 platform wonder. It's also good to have Rdb on NT as per
    the announced plans, but I don't know how many customers will take that
    big step first on a new operating system.
    
    Simon

	re: .9

	; ...
	; ...
	; What would you expect 'ODBC on the host end' to do for us?

Most customers want it to be a database interoperability standard
sort of like a non-DEC SQL/Services so they can make their existing
Rdb databases play with the rest of the world without the expense
of buying one of our RdbAccess gateways.  

Most customers who approach me with high hopes for ODBC and come to
me to get an understanding about it wind up leaving disappointed or
chewing me out about Digital being "proprietary."  If you list all the
facts for V1.0 up from in a terse manner like that that implies
the required conditionalities then most people can figure out whether
or not it will work for them right away.

What I meant is that most customers seem to infer from "rdb supports
ODBC" that a host running Rdb can supports ODBC access from any client
on a LAN and not that this is simply a driver/transliterator for only
Windows.  At the moment of course the only thing people can buy is
MS-Windows, and I am happy to see we're with the head of the pack in
that department.

Could ODBC be turned into a non-DEC SQL/Services ?

Regards,
rcs

	re: .7/.8

	The confusion probably centers around the fact that there is a
	Q+E library which is a standalone product for PCs as well as a
	Q+E addition to Microsoft Excel and that these are separate
	products...

	Regards,
	rcs

The kind of interoperability that customers may want was what the
original plans for the SQL Access Group (SAG) were.  SAG developed a wire
protocol (Formats and Protocols or FAP) based on the (then) draft ISO RDA
standard.  This would allow any client to talk to any server without
knowing what was at the end of the wire.  SAG has recently extended its
FAP to run over TCP/IP.  The only problem is that Digital is the only
major vendor to ship products that adhere to SAG FAP.  So Digital is THE
MOST OPEN vendor of the lot, but who cares if the standard isn't widely
adopted?

SAG went off and created a call level interface (CLI) to solve another
part of the problem, a hiding rdbms specifics from application code.
Microsoft took the SAG CLI and extended it to become ODBC.  They got
Apple signed up, so ODBC should become available across Windows, Windows
NT, and Mac.  But what about other platforms, such as UNIX servers?

Unless someone with clout in the UNIX arena, namely either USL or OSF,
step forward and commit to the ODBC dispatcher portion I don't believe
ODBC will become real on UNIX.  Maybe we can help influence them to make
that happen.  The alternative is to implement a more pure form of SAG
CLI, essentially getting us a subset of ODBC, on UNIX and other
platforms.  That is indeed our strategy at the moment, but our rollout
priorities are clearly ODBC on Windows, followed by Windows NT and Mac,
followed by ODBC or SAG CLI on other platforms.  And getting a truely
great ODBC story on Windows and Windows NT has a higher priority then
broad platform coverage.

What about the competitive picture?  Well, no one is offering an open API
across all platforms.  Everyone is proprietary, and no one is moving
faster than we are to embrace the open standards.  So, muttering
"proprietary" when talking about the Digital story seems like nonsense.
Proprietary compared to who?  Who is "open" in this area?

We, by the way, would love for ODBC to be embraced on every platform by
every database vendor.  The reason is quite simple, then we could get out
of building lots of low volume/high support cost gateways.  We could have
one piece of code coming out of our DB Integrator that just spoke ODBC
and we'd let each individual vendor supply their ODBC driver.  This is a
variation of the original SAG FAP idea where we would have built one
RdbAccess to SAG FAP and let vendors supply there own SAG FAP servers.
Digital can't make ODBC everywhere happen, though we certainly will be a
leading proponent and supporter of it.

Hal

The story with Q+E and actual support of Rdb may be that it was a
"special" that you had to purchase separately.  Rumor is that it is no
longer available.

This is all mute.  There are active efforts to get Q+E to support Rdb
through the ODBC interface.

You really have a handle on what's going on Hal; you
are one of the most poignant noters I've ever read.
Thank you.

	; ...
	; Unless someone with clout in the UNIX arena, namely either
	; USL or OSF, step forward and commit to the ODBC dispatcher
	; portion I don't believe ODBC will become real on UNIX. 
	; ...

According to the latest issue of UNIX world USL was 
dissolved by Novell and the constituents reorganized
into a new division.  Maybe Digital can use its 
clout with OSF to drive this issue the right way now ?

	; ...
	; So, muttering "proprietary" when talking about the Digital 
	; story seems like nonsense.  Proprietary compared to who?  
	; Who is "open" in this area?
	; ...

You're right -- it is nonsense: none of this is public 
domain software, the penalties for software piracy are 
equally administered for all products under the law.  
This is a management synonym for "multivendor platform 
support."

Regards,
rcs

re .15:

I don't even think its a public domain issue.  What vendor offers a
standard conformant interface that is identical on all platforms and can
talk to other database systems without going through a vendor-specific
server gateway?  None.  No one even offers a subset of the question.  So
I still don't understand the customer's comment.

Gentlepeople,

RE: .9: As it happens, I was at a SQL Access Group (SAG) meeting last
week, working on the Preliminary Specification (PS) [that's an X/Open term
meaning "stable, but not debugged enough to be a Common Application
Environment specification"] for CLI.

The Microsoft representative to SAG was, of course, there and actively
working to keep CLI and ODBC as closely aligned as reasonable.  During the
course of an internationalization side-discussion, I asked the Microsoft
representative "why doesn't the WinNT version of ODBC 'speak' Unicode,
WinNT's native character set?".  He was remarkably coy in his reply, but
the answer boiled down to "The communication between the database
organization and the WinNT organization wasn't very good and we're working
on it."  In my mind, that confirms that Microsoft has ODBC for WinNT, but
it's not quite ready for announcement yet.

In .13, Hal expressed a frequent plaint that Digital is viewed as
"proprietary" and asks "compared to whom".  My (admittedly cynical) answer
is "compared to the proprietary companies who spend their advertising and
marketing budgets/skills to convince the world they're open".  I was
initially appalled at Digital's expectation that simply renaming VAX/VMS
to OpenVMS would mean anything to anybody.  But I was wrong...it has
helped at least a little.  If we spent a bit more effort telling everybody
how open we are, compared to some specific list of competitors, we might
not be perceived to be so closed.  Customers to lecture us about being
proprietary are usually parroting things they've heard said by our most
excellent friends Oracle or someone similar.

Sigh...will we *ever* learn how to market ourselves?
   Jim

P.S., Incidentally, the ASK/Ingres representative to SAG was bending my
ear last week on the subject of getting his company to implement CLI and
RDA, too.  They are also waiting for somebody else to make the first move.
When I told him that Digital had products already, he asked "Why the heck
don't you advertise them?  That'd get my company moving to compete!"  I
could only answer that we don't do advertising, at least not of our
database products---we're too busy advertising our competitor's products.
Cynical and uncalled-for, I'm sure...

    >I could only answer that we don't do advertising, at least not of our
    >database products---we're too busy advertising our competitor's
    >products. Cynical and uncalled-for, I'm sure...

    But, none the less, true. My biggest concern is that we will soon have
    a product (DEC DB Integrator) which has the potential to be an enabling
    technology to solve many business problems. However, now that the field
    is moving away from sales support towards SI Integration there will be
    no one to market it! At the least we need to market internally to our
    own consulting organization rather who will be able to use it when they
    design solutions. However, I don't think that alone will DBI to succeed
    let alone prosper.


    - Barry

, but instead, I'd like to point out what, exactly is closed about
our ODBC driver:

It requires our proprietary SQL/Services, available only with our
proprietary PATHWORKS and works with only our proprietary Rdb.

THAT'S WHY WE'RE NOT OPEN!

I know that the ODBC Driver for IPX/SPX is going into field test, and
that's great, but it ain't here yet.

Keep up the good work!

Bruce

    re .19:
    
    Bruce,
    
    Correct me if I'm wrong but isn't every ODBC driver proprietary? ODBC
    only specifies the CLI and has no specifications for formats
    (so SQL/Services qualifies) or transports (also Pathworks qualifies).
    
    I agree fully that that is not what customers want. They want one ODBC
    interface on the PC and be able to talk to any database that has an
    ODBC server over any transport.
    
    Cheers,
    Henny

>, but instead, I'd like to point out what, exactly is closed about
>our ODBC driver:
>
>It requires our proprietary SQL/Services, available only with our
>proprietary PATHWORKS and works with only our proprietary Rdb.
>
>THAT'S WHY WE'RE NOT OPEN!

Hold it a second. All ODBC specifies is the interface used by the applications
programs to talk to database managers, so that the specifics of each database
manager are (or can be) hidden from the applications.

It says nothing about the implementation of the drivers, or the implementations
of the database managers. So, of course, our ODBC driver is proprietary, and so
is SQL/services, and so is RDB. It is just as proprietary as the ODBC driver
manufactured by Oracle, or the one that talks to SQL/Server ... 

The openness aspect of ODBC lies one notch higher. It allows people to develop
PC applications that can talk to all kinds of databases: SQL/Server, RDB, etc, 
because each database manager is accessed via a specific driver.

/albert

And ORACLE's ODBC driver requires their proprietary SQL*NET. 

Every ODBC driver out there requires some piece of currently proprietary
code between it and the network software.  That we also require Pathworks
for networking is a problem we are addressing with V6.0.

Sorry, I've been away from this conference for few days (and would have stayed
away longer, if I'd known what a beating I was taking in here ;-).

The kind of situation I was referring to in .19 is where a customer has Rdb
and NetWare (for example) and doesn't want to have to buy PATHWORKS in order
to use our ODBC driver from the PC.

Such a requirement does not position us as "open."  Adding support for other -
granted, they're proprietary as well - net transports helps us be perceived
as more "open."

I meant what I meant, not what I said. ;-)

Bruce

    Another example is PowerBuilder from PowerSoft (800) 395-3525. There is
    a review in PC Week Sep 27 which lists database management systems it
    supports. I list ODBC, Oracle, Sybase, DB2, Informix, etc.
    
    We need someone to talk to them also since PowerBuilder is a key
    component in our client/server strategy.