Conference ulysse::rdb_vms_competition

>    In two of those cases, the primary focus of O's sales
>    effort and the user's interest is the ability to quickly/slickly
>    develop applications on a pc and then port them to whatever.

One key point could be to tell the customer that the tools have different
versions (not always compatible) on the various platforms. This, as far as I
know, is due to the fact that Oracle develops on the VAX/VMS platform first,
and then ports on the others, and this approach may lead to significant delays
in availability of key functionalities.

>    The salespeople are negative about RALLY/TEAMDATA because of problems
>    they have had with these tools on other accounts.  Now, I realize that
>    these problems do not mean that the tools are bad, but.....

My personal opinion about RALLY is that it is as good as any other Digital
product. The general problem is that many people tend to consider it "easy",
whilst my impression is that it's quite complicated to understand, and that a
developer needs an extensive training *before* using it. Lack of this training
leads to problems...

>    So, any suggestions?  What's wrong with O's tools? 

A good point is performance, even if this could be extended to any 4GL. As
far as I know, everithing is fine as long as you develop a simple
application that fits exactly into the base capabilities of the tool
(SQL*forms, for exmple). As you try to force the product to do something
that is a little more hard (from *its* point of view) performance degrades
quickly. As for SQL*report, I have a customer that developed a big report
application that hangs a 3800 with only *three* active users!!

Hope this helps a little,

Massimiliano

    Does anyone know anything about an ORACLE gateway to Rdb?  My customer
    (at Bankers Trust) mentioned that the ORACLE rep. had been talking to
    one of the developers here about a gateway that would permit the use of
    ORACLE's tools on an Rdb database.
    
    -dave

    Oracle is working on a runtime gateway to Rdb, so kind of the same
    offering they have to access DB2. In fact, they even bought a Rdb
    licence to test this out.
    
    They are definitely NOT porting any tools like SQL*Forms to work on Rdb,
    DB2 or any other database platform than their own.
    
    Henny

    ORACLE Gateway products:
    
    SQL*Connect, Oracle's gateway product, is an extraction tool.  It
    allows a user to access data from DB2, RMS, and <soon to be> Rdb
    in their interactive SQL*Plus environment.
     
    ORACLE Tools:
    
    SQL*Forms is a fun, easy-to-use 4GL tool.  The same system, with 
    basically the same interface, runs in all environments (MVS, VMS, 
    UNIX, MS-DOS, etc).  The problem is, the product is too simple.
    If your customer intends to develop production applications with lots
    of users, he'll be really upset with SQL*Forms.  SQL*Forms is great for
    applications that do simple maintenance functions (select, add, modify,
    delete) from a single table. The tool has limited functionality, and 
    each user comsumes tons of resources.  Offer the customer some RALLY, 
    ACMS, PowerHouse, or SMARTSTAR references who are running their business 
    on Rdb.  Then ask ORACLE to provide the same type of references who are 
    using SQL*Forms.  The Oracle rep will start to sweat.  

    It has been my belief that SQL*PLUS and SQL*CONNECTION were the only
    ways to access information in DB2 & RMS. SQL*FORMS, SQL*REPORTWRITER, ...
    could only utilize data stored in ORACLE databases. Is this still true?
    I have just seen an add for the new MacIntosh version of ORACLE
    showing a Hypercard user-interface. Is this just a GUI for SQL*PLUS or
    can you really build applications that access ORACLE, DB2 and RMS?
    
    _Paul

    As far as I know, Hyper*SQL is just the Macintosh -format version of
    SQL*Forms. So, can you "access" those other databases? Sure, with
    SQL*Plus just like other environments.
    
    ---- Michael Booth

Nice note from the nodemo::marketing conference. Rest of the 1212.* 
discussion is fun too.

From:	DOOZER::PENNEY       "DTN: 830 4114" 17-MAY-1990 12:09
To:	PENNEY,PENNEY      
Subj:	extraction from MARKETING 1212

================================================================================
Note 1212.85             We invited Oracle to DECWORLD?                 85 of 88
WARNUT::DUANE                                       134 lines  16-MAY-1990 08:55
--------------------------------------------------------------------------------
                           -< Oracle nice guys???? >-

What the *&$# is going on? Who was the poor sucker who woke up
at 4am worring about Oracle? I joined Digital last year. Before
that I spent 3 years developing Oracle systems, from complex
Plant systems to commercial systems on VAX's, IBM pc's and
mainframes and HP. The Oracle product set is NOT the same 
between platforms. Apart from being a subset on some platforms
there are differences in the way the product behaves. To me
it is more difficult to develop where you're not quite sure 
what's different than when you can compile etc. with switches
and look at concise documentation.
The Oracle product set is superficially nice and pretty but
you delve a little and you get some nasty surprises, sure I'm
talking functionality wise rather than deep technical arguments
but after all that's where most of the industry is. Lets take a
few examples (note these are just SOME egs. in V5.1.22) :

The Oracle environment on VMS 
        (where it was first and is continually developed). 
        We had to rewrite most of the DCL command procedures they
        were so bad - the installation, startup, setup procedures.
        For instance if you reinstalled a product it would 
        duplicate all the logical names and symbols.

The RDBMS
        Whenever you do a SQL sort it uses temp tables in the
        database, these can grow to thousands on blocks. Does it
        extend to database? No it waits for a few hours then says
        'out of space in xxx partition'. Are the differences with
        ANSI SQL documented anywhere? NO! SQL*Plus = SQL + lots 
        of non-standard stuff that'll really tie you in. Besides 
        it's toytown compared with Rdb.

SQL*Net
        I used this between and IBM pc and a VAX in it's crudest
        form, asynch comms, got lots of problems, rang Oracle and
        they said we recommend using it over DECnet and DECnet/DOS.
        In other words they leech off all the good networking we've
        done.

SQL*Forms
        Oracle's best product but to be honest functionality wise
        compared with RALLY it is far inferior. For instance in 
        Oracle you can have a single row block or a multiple row
        block taking 80 columns. In RALLY you can have them side by 
        side, going across then down, spanning limitless columns etc.
        With Oracle you're stuck to using Oracle's database. RALLY
        can access Rdb, RMS, DBMS and soon any database. Also you
        can use it for Forms and Reports. Talk about integration of
        products! If you wanted to call an SQL/Plus procedure from 
        SQL*forms you used to have to hard code the password into
        the form (okay there are other ways but it's messy).

SQL*Report
        Last year this was used heavily by all Oracle consultants
        (Analyst/programmers to you). I haven't seen it mentioned
        in any of Oracle's advertisments recently. Seems to have
        been superceeded recently by Report*Writer (which incidently
        isn't disimilar to RALLY). This is a product they bought-in
        so it can't be that well integrated. 

SQL*Menu
        This is a goody. It didn't exist on Pc's cos when you 
        selected a menu option it set off a sub-process so what they
        did was develop a SQL*Menu look-alike using SQL*Forms for the
        Pc base. It's an entirely different problem on IBM mainframes.

Pre-Compilers
        These are fun. I think we were field testing PRO*Pascal 
        judging by the problems and support we were getting. If you
        want to run a 3gl from SQL*forms (due to performance problems
        with SQL*Plus or SQL*Report) you have to link to program 
        you've developed with the SQL*Forms image (IAP). You can have
        fun with this.

CASE tools
        Admittedly I've only seen the graphical front-end but from 
        what I've seen it only makes calls to the forms and reports
        in the SQL*Design*Dictionary. I've used this for A&D work
        on a fair sized system (about 90 entities) and it is 
        cumbersome to say the least. The idea of using Oracle's
        CASE tools was to have a central source for dictionary 
        definitions across site but because Oracle generated an 
        internal seq# for each entity when you tried to merge two
        dictionaries on different systems you got big problems.

        There's an automated database generation tool. You have
        to supply all the keys, and the relationships between the
        Entities. All it does is the obvious. For a many-to-many
        it creates a intermediary entity (wow!); for a one-to-many
        to many pulls the keys of the few(wow!); for a one-to-one
        it does nothing. If you dont obey these simple simple rules
        it gives !!!!!MANUAL intervention required. There's a 
        little something for table sizing which is basically put
        in the volumes and it uses a simple algorithm to work out
        the table size. I could write something to provide THIS
        level of functionality in a couple of days. Somebody that
        knew what they're doing could write something 100 times
        better, but why bother when we've already got Rdb*Expert.
        From what I know of the system generation part it knocks
        up a few SQL*forms and you have to do the rest. We can do
        that now with RALLY or many different 3rd products.

        But, most of all Oracle really only support Oracle's
        methodology ie. Functional decomposition and Entity
        modelling. There's really basic DFD support but there's
        no proper rule definition and validation like in DECdesign.

Anyway these are just a FEW points about how poor Oracle's product
set really is and how badly they are integrated. Really our 
product set is far superior and far better integrated. If we
start including SELECTED third parties we beat them hands down.
But we don't, we give in. If we marketed the way Oracle do we'd
be well ahead. I believe we must push our products and push them
now before it's too late. We've seen what's happened on VMS are we
going to be blind and let it happen all over again on Ultrix?

I liked the anology about the foxes and the Hen house. They 
remind me of Magpies. Where I live we have a plague of Magpies.
I'm sure a lot of people think, oh! what nice birds, I think 
I'll feed them, and don't realize all the little birds are
gradually disappearing. Only one morning they wake up to see
to Magpies stealing the babies of all the little birds. It's 
only then that they realize where all the little birds have
been going. Sounds a bit like what can happen in one of our
accounts. We let them in with lots of smiles, come back a few
weeks later and find lots of Sequent boxes where the VAXes 
used to be.

Okay I know this is all very basic and probably O.T.T but
we've got to do something! We need some messages and clear
positioning from up high to stop to rot! Most of all we've
got a very good story to tell. WE MUST TELL IT!!!

Cheers,   Duane.