Conference ulysse::rdb_vms_competition

    Pretty impressive results, but out our way we usually show it as
    SYBASE on top, followed closely by RDB and Oracle.  Don't see much
    Cullinet.  I have my doubts about who ever ran the benchmark, as
    SYBASE's caching usually shows the best results when given enough
    memory (at this point in time).
    
    This points out the problems with non-standard databases benchmarks
    and non-knowledgeable salesmen and customers.  I shall be looking
    forward to the entry of the Cullinet people onto the scene as they
    will be interesting to actually benchmark against.  Please keep
    us posted as you hear more.

    First of all, the benchmark is a debit/credit. That's about as standard
    as they get. I can see the field day the Cullinet reps will have
    with the graphic data. It's sort of "open season" on the competition.
    
    The reality of the situation is that Cullinet tested on an 8550.
    Typically, vendors will benchmark the low and high-end. Cullinet
    went for the middle. So their benchmark is on a different machine.
    However, claiming that they outperform Sybase by 3:1 will get them
    in trouble early. Claiming that Rdb performance is one ninth as
    much as IDMS/SQL will put them deeper into the hole.
    
    It's sad to say, but these performance claims sound like the ravings
    of a desperate organization.
         
    
    ---- Michael Booth

First of all, if this information was provided to your customer under a
non-disclosure agreement they should not have given it to you, and you
should not have posted it.  If this is non-disclosure information, then
the base note should be set hidden.

Cullinet doesn't mention if this is pure batch DebitCredit (ie,
database only) or is the full OLTP DebitCredit (forms, tp-monitor,
communications, response-time constraints, etc.) called for by the
official DebitCredit definition.

Depending on the exact criteria and tuning used, VAX Rdb/VMS V2.3 can do
from 2-9 DebitCredit TPS on an 8700 (same performance as an 8550).
Remember that Cullinet is talking about an unannounced product and that
our own unannounced product does substantially better than V2.3 (and
better than IDMS/SQL's claimed performance).

Basically, I think that Cullinet is either playing games or had a group
of people not competent in tuning the competing products run the competitive
benchmarks.

Hal

Ps: I noticed the plug about all this performance, and a V1 product no
less.  It should be remembered that IDMS/SQL is a buyout of an already
existing database system.  It is not a from-scratch new product.  Also,
Cullinet has been talking about this product for over a year and has
twice slipped its official announcement date.  IDMS/SQL is a reworked
buyout that they have had substantial difficulty bringing up to the
level necessary to be a serious contender on VAX.

    
    re: .3
    
    This information on IDMS/SQL was brought up during a joint Cullinet/DEC
    meeting (with a customer interested in their warehouse distribution
    software).  Since xerox copies were distributed to everyone present,
    including the DEC sales rep, its definitely not nondisclosure
    information.  My reference in the base note to "confidential" was
    only imply that at long last Cullinet is beginning to show their
    plans for the product.
    
    I apologize for the initial wording.
    
    George
    

    i attended the march 22 idms/sql seminar held in ny by cullinet;
    the following is a dump from my notes just what they told us; in
    the audience were mostly dec folks, sprinkled in were some of the
    top database dba from a number of our key account here in the city.
    One thing i'd like to point out, is the number of sex (marketing
    sizzle) words like "mission critical" applications.
    
    From Cullinet:	John Calania		District Manager
    			George Van Scoik	Regional Sales Manager
    			Joe Penta		?
    			Bruce Daily		Technical Support
    			{ a host of others that did not present }
    
    They presented the following products:
    a) idms/sql - a database based dictionary, integrated data management
    system for the vax/vms line of computers
    b) knowledge build - a 4gl (which generates 3gl code into languages
    like basic, cobol<only one shown>, fortran, C and "ADS") system
    builder under the idms/sql umbrella
    c)application expert - an expert system integrated into the above
    two products providing rule based decision making and direct linkages
    to outside communication thru DECtalk<demod>
    
    they (cullinet) presented they're approach to the vax/vms line
    (differently than before as)
    
    1. "3x3" selling approach; Corporate, Departmental, Personal; different
    than other 3rd parties, they will develop systems and tools for
    the VMS line thru development and aquisition, and will not provide
    a generic set of products across a number of hardware platforms;
    they will put the additional R&D into developing specific products
    that capitalize on the hardware and system at each level; 
    
    when i pressed them on this point offline, they alluded to the fact
    that they would not use any of our products, and that in their eyes
    the idms/r product is short lived; they would be providing a higher
    speed access protocol to/from the ibm side through knowledge link,
    which a data access protocol more specific and performance conscience
    than decnet, being a general purpose protocol not specific to
    relational database needs (more on this later)

    what they described running across these three levels were different
    types of tools needed by different individuals; a graph they put
    out was (excuse my drawing)
    
    Platform:	
    	Corporate	|  Database---->
                        |
    	Departmental    |              <----Tools---->
                        |
    	Personal        |                        <----Applications
                        |
    			----------------------------------------
    
    						      	Tools Required
    
    showing that their tools would be available across all platforms;
    this is very different than saying that all tools would be the same
    however; so that the corporate level:IBM, at the department level:DEC
    VAX, and personal level IBM PCs.; the interconnection would be
    KnowledgeLink a proprietary data access protocol

    2. support from cullinet comes in four levels:
    	a) consultative selling - what we call sales support
    	b) online tech support - like QARs, dialup & download new fixes
    	and have access to notes like conferences
    	c) CBI based instruction as well as lecture/lab courses
    	d) Extended Services - our PSS equivalent
	e) the cullinet users group (ala DECUS) to provide even more
    	support

    3. products feature an 'open architecture' spanning capabilities
    from 3gl -> 4gl -> 5gl as:
    
    				     -----------  Application Expert(5gl)
                                     |                     |
    		    ----------	KnowledgeBuild            /
                    |                                    /
    		IDMS/SQL                                /
		    |                                 /
                    ---------------------------------- 
    
    They called Application Expert a "rule based programming environment"
    which is fully integrated with KnowledgeBuild and IDMS/SQL.
    
    They then went into a discussion of each product:
    
    I IDMS/SQL - only DEC relational database for mission critical
    applications; modular in approach and design:
    
    
    			    Ad Hoc ------->  /	SQL parser
                                            /
    			    Applications   <--	Query Optimizer
                                            \
    					     \	Database Engine
    
    
    in TP1 benchmark, outperformed competitors by a 3 times (named ingress
    oracle and rdb offl;
    
    IDMS/SQL features the following:
    
    ->Automatic rebuild of stored compiled queries when there is a change
    in the database structure
    
    ->Bulk record (stream) transfer
    
    ->SQL extensions (over ANSI) for TP support <asked for a copy, will
    post if i ever get them>
    
    ->SQL safe points (aka periodic commmit retaining) the example used
    was: "If running a transaction over several hours, would commit
    changes ever 100 or so records"
    
    ->Automatic Priority Deadlock Resolution ? highest priority wins
    
    ->Compiled queries across a network
    
    ->Dynamic database restructuring requiring no unload/load
    
    ->Sophisticated journaling (dual) to disk; i asked if this included
    periodic highwater marking to tape (i.e. spool to reel after a certain
    size); No
    
    ->Automatic Online Recovery (roll forward of archived journals)
    
    ->Referential Integrity
    
    ->Null values (not missing!)
    
    ->Column level security
    
    ->Group level authorizations (i.e.  all members of a particular
    group get/don't a particular access)
    
    ->Distributed database with location transparency
    
    ->Single engine stream performance "...performance goes down as
    you add addtional processors in a multi-image environment<aka cluster>;
    best performance is in single engine performance<made an allusion
    to DEC themselves realizing this with the introduction of larger
    uniprocessors running SMP as the TP focal point, not CLUSTERS>
    
    ->Link between IBM and DEC is KnowledgeLink, a database based data
    protocol specific for relational databases, designed for high volume
    online performance
    
    ->Hash key support;
    
    
    II KnowledgeBuild - a 4gl environment with 3gl performance and 5gl
    productivity; graph used:
    
    
    	Run-Time        |  3GL				KnowledgeBuild
    	Performance	|
                        |		PowerHouse
                        |               Ingres
    			|               VIA
    			|               Oracle
    			|
    			--------------------------------------------------
    
    							Development
    							Efficiency
    Product is actually a number of smaller utilities all under the
    same global name:
    
    ->Application Generator - Generates 3gl code for performance(basic,
    cobol, fortran, C, "ads")
    
    ->Common user interface (across all tools)
    
    ->Form and report builders
    
    ->Field level masking and pattern editing (i.e. define a field as
    numeric $$99.99- and this mask/picture would carry thru to forms
    and reports from the database field definition)
    
    ->Forms Painter - automatic by table input (ala rally) or by scratch
    (ala FMS); allows field level UARs
    
    ->40x efficiency improvement in application builder; 40:1000 lines
    ratio from 4gl -> 3gl code (cobol in this example)
    
    ->Menu Maintenance System (used by all applications)
    
    ->security level option tagging (each item can be tagged by user
    security level <each user has own profile defining level>
    
    ->password level security
    
    ->Interactive SQL utility (ANSI compliant DDL, DML)
    
    ->SQL Precompilers (Cobol, Fortran, C)

    ->List of Values support (fixed, popups created using EDT); not
    data driven as in RALLY
    
    
    Hope this info is in some sort of readable format. As I said at
    the start, they mentioned just about every buzz word associated
    with 'relationa', and 'sql' databases; 
    
    it was kinda nice to be in the audience for a change, but i couldn't
    help feeling it was their last gasp; they left you with the impression
    that they're committed to provided the best product at each platform
    unlike Oracle or Ingres;
    
    it was on this note that i pressed them about IDMS/R and this products
    relationship to VIDA; was told that IDMS/SQL is where they're paying
    all their attention, and not their existing ties with DEC over the
    current product set; they aim to be direct competitors over this
    space (IBM <-> DEC database interfaces)
    
    hope this helps
    
    /los

    I got a call from a specialist who had a copy of a letter from
    Cullinet.  The letter compares Rdb/VMS with IDMS/SQL and it's not
    very friendly, to say the least.  Product management has been notified.
    So you have some advance warning, just in case, these are the bits
    I can remember:
    
    1)  Poor performance in multi-user mode:  Farther into the letter,
    they claim that if you have two users trying to update the same
    table at the same time, they will deadlock.  It's possible, true,
    but rare with intelligent (or even half-intelligent) design.
    
    2)  Not SQL native:  Not sure what this means or how it's relevant.
    
    3)  Not 24x7:  Possibly they don't have v3.0
    
    4)  Ad hoc requests are interpreted:  In reference to callable RDO,
    I think.
    
    5)  (In big letters) No automatic recovery:  Wrong, wrong, wrong
    
    6)  Can't store compiled requests:  In a data dictionary, they mean.
    If your cardinality changes significantly over time, this isn't
    such a bad idea.  With Rdb/VMS, your requests are optimized for
    the current state of the database (as of the attach).  Except with
    callable RDO, I believe requests are held in memory for the duration
    of the database attachment.
    
    7)  Only btree indexes:  Not anymore.
    
    8)  A "lock pig":  I'm not sure how undeserved this is.  However,
    our use of locks means our cluster support is that much more robust.
    We also have ALG and other algorithms to reduce locking.
    
    9)  Must recompile after database restructure:  This includes, say,
    dropping an index, according to Cullinet.  Recompile only when you
    change relations/fields that the program references.
    
    10)  Table-level locking only:  Wrong, wrong, wrong
    
    11)  No dual-journalling:  They go on to say that the RUJ journal
    must be created at database define.  I think they've gotten confused
    with AIJ and RUJ.  Regardless, they're wrong.  We do, in fact, have
    dual-journalling.  (It's a requirement of DebitCredit, I believe.)
    And for good measure, AIJ can be turned on at other times besides
    database creation.  They missed the boat on this one.
               
    12)  In the summary, they claim that since Digital is not really
    a software house, Rdb/VMS is not a strategic product for us and
    won't be handled as one.  Improvements will be made according to
    engineering whim rather than market needs:  Wrong, wrong, wrong

    Interesting.  Many of the claims in .6 come down to "here are some
    reasons why Rdb/VMS *ought to be* slower than IDMS/SQL."
    
    But in fact I think it turns out to be significantly faster, no?
    

I have no knowledge about whether IDMS/SQL is faster than Rdb/VMS V3.0.
(Has anyone done any actual apples-to-apples measurements ?)

However, it's all in the perception.  I met a guy at the recent ACM SIGSOFT
(IDE3) conference in Cambridge, MA. who claimed that he was benchmarking a
variety of database systems (he mentioned Rdb/VMS (and claimed that it was the
slowest of the lot), ORACLE, etc.)  When I said that Rdb/VMS V3.0 should be able
to more than hold its own against the competition, he said "Even against
IDMS/SQL?".  I tried to be positive, but I don't have any basis for that
particular comparison.  So maybe Cullinet is getting a message through --
is it pure perception, or do they really perform ? 

The only IDMS/SQL performance numbers I've seen were from field test
IDMS/SQL.  They were run BY CULLINET and showed IDMS/SQL beating Rdb/VMS
V2.3 in I/O, and Rdb/VMS blowing the hell out of IDMS/SQL in CPU.  They
were working to get the IDMS/SQL cpu times down before release.  Now,
Rdb/VMS V3.0 uses less CPU than V2.3 most of the time, and uses
less I/O than CULLINET claimed the IDMS/SQL field test software used.

So, I don't know what the absolute answer is (*), but I do know that
CULLINET is passing around lots of misleading information.

Hal

(*) - There isn't an absolute answer.  You can always construct a
benchmark to prove you are faster.

    I have a customer evaluating IDMS/SQL with tools. Cullinet has told
    them that their tools (enterprise) don't support V3.0 RDB. These
    tools are listed on the lastest ISV support list and Cullinet is a CMP.
    
    Could it be true? 
    
    If so, we in the field are being given bad data about who supports
    RDB.
    If not, Cullinet is REALLY getting desperate for business.
    Also, will the Enterprise tools run on Runtime RDB alone or is some
    greater level of support needed.

    We are working with them th get RDB runtime and just the tools from
    Cullinet. Any information is needed fast. Sales has those end of year 
    blues again.

    			Thanks for the time,
    				Hunter.

    The Cullinet Tools for Rdb V3.0 are not yet available in a "production"
    version. However, outside the U.S., Cullinet is supplying some type of
    version to Rdb customers.
    
    ---- Michael Booth

�< Note 104.10 by SDOGUS::SMITH >
    
    Hunter, if you don't mind a comment from New Zealand;
    
    A customer of mine spent a couple of weeks evaluating the Cullinet
    tools that do (only just) support Rdb.  My customer has decided
    AGAINST using these tools due to their immaturity.  Some of the reasons
    for this decision I mentioned in the Rally Competition conference.
    
    We are currently working on explaining the benefits of ACMS/DECforms
    and RALLY.  This might be a better TACK.
    
    Hope the rest of your project is plain sailing :-).
    
    Cheers, Martin