Conference ulysse::rdb_vms_competition

    For what it is worth:
    
    DB2 only runs on MVS, but really needs XA (and all of the surcharges)
    that go with it to have any performance at all. Moreover, IBM is
    positioning MVS/ESA recently announced as the key to the 50%
    performance improvement in their latest release. Keep in mind that
    MVS will not yet run on the 9370, and MVS/XA probably never will,
    leaving the customer without a growth path to the departmental level.
    Silverlake is no answer either in that it has an SQL data base,
    but it is not DB2.
    
    DB2 takes an enormous amount of disk storage, as does MVS, just
    to establish working libraries. It requires 3 MVS regions to operate,
    whereas even the independent database manufacturers can run very
    well in one. This adds a LOT of overhead for the three regions to
    communicate to each other during operation.
    
    DB2 has no distributed capabilities. Rdb has remote access to build
    distributed appications and Vax Data Distributer to replicate data
    where necessary automatically. IBM has no conterpart to this. IBM
    has no communication even to different DB2 systems running on the
    same machine, let alone on different machines. 
    
    Rdb and its associated tools will run on the same platform (VMS)
    from desktop to the mainframe, taking advantage of all remote and
    distributed capabilities of the Digital architecture. IBM cannot
    even get a 100% compitable version of SQL on its different machines,
    much less get them to cooperate in a networked environment.
    
    DB2 has announced a new dictionary as the central repository for
    CASE. Today it has none. Rdb is integrated with CDD which not only
    manages the Rdb data base, but the entire spectrum of Digital data
    management. 
    
    Application development tools are very limited for DB2, namely CSP
    and 3GL's. CSP is not integrated well with DB2 yet. Field lengths
    supported, for example differ between the DB2 catalog and CSP. THis
    is likely to change, but today, CDD leads IBM.
    
    For OLTP applications, Digital price for performance is better and
    we also get more transactions per MIP than IBM.
    
    Find out what the key issues to the customer are: ease of use for
    the data base administrator, integration, programmer productivity,
    integrated growth path (VMS platform), or whatever. There are very
    few areas that they can beat us, withthe exception of raw computing
    power at the high end(at a price). Help the customer dig into the
    IBM claims in these areas and compare them to ours, I think we will
    be better.
    
    If you couldn't tell, I don't like IBM. Let me know if I can be
    of any more help.
    
    Jamey Nordby Cookie::janordby
    

    Do we (Rdb, RDO, SQL) compile data manipulation statements in a
    similar fashion to DB2. Including parsing for syntax errors, checking
    referenced elements, choosing access path and generating machine
    executable code?
    
    New to Digital,
    
    Sandy
    

    I used Rdb for a couple of years, then DB2 for a year and a half.
    From this perspective, I would say that Rdb is a far superior DBMS.
    Both systems are the DBMS developed by the hardware vendor and in
    this respect they are similar.  But differences are easy to find.
    
    Some of the differences I noticed:
    
  o DB2 uses the SQL interface, or QBF (Query By Forms) in QMF.  Rdb
    has both SQL and RDML interfaces available.
    
  o The smallest unit of locking for DB2 is an entire page of memory
    (minimum 4K bytes). This can create a lot of unnecessary contention.
    It's an even worse problem when you lock an index page.  Rdb locks at
    the record level. 
    
  o DB2 has no counterparts to constraints.  The closest thing is a
    program, recognized by DB2, which will be executed whenever
    the corresponding table/field is referenced.  This program must
    be written in assembler: no SQL!  Furthermore, it may not reference
    fields in other tables.  I can't remember what it is called, something
    like VALPROC and something similar called EDITPROC.  We quickly
    ruled out trying to use these things; besides the difficulty of
    writing them, it seemed to require the full cooperation of the system
    managers (a tough thing to secure for an IBM system).
    
  o DB2 has no counterpart to global fields, which are useful for
    implementing relational domains.
    
  o It is far more difficult to change things in DB2.  For example, if you
    want to change the data type of a field, you must UNLOAD the data, DROP
    the table, reCREATE the table with the new definition, reLOAD the data,
    perform a backup COPY before DB2 will allow access to the table (!),
    run the RUNSTATS utility so that DB2 will have any idea what size the
    table is, reCREATE any views which were based upon the changed table,
    and recreate the affected DCLGEN's (static dictionary definitions
    included in programs).  If you're lucky, you can use the LOAD utility
    or DBMAUI (migration tool) for the load and unload steps, otherwise you
    have to write a program. 

  o As implied above, DB2 does not dynamically track table and index
    statistics.  To update these, the DBA must periodically run the
    RUNSTATS utility. 
    
  o In spite of anything you may hear to the contrary, someone needs
    to know JCL.  It crops up in a lot of places.  The utilities, which
    supposedly can be run interactively, always failed.  The only solution
    was to write JCL and run them in batch mode.
    
  o The dictionary is centralized, not distributed like CDD.  This means
    that if one user is modifying a table, DB2 might lock out all users
    from the entire user during the update.  I saw processes come to
    a standstill for hours for no apparent reason, later traced to this
    cause.  The only relief from this problem is to create different
    subsystems (test, production, etc.).  Creating a new subsystem is
    not trivial, is done by the system manager, and consumes gobs of
    precious (system manager-owned) resources.  I lobbied unsuccessfully
    for months to create one new subsystem.  Within a subsystem, the
    above problem will still exist.
      
  o The BIND step is an extra step in the program development process
    (introduced for better performance).  This step is not always done
    automatically when something changes.
    
  o Data types: No segmented strings in DB2.  Until Release 3, there
    were no date/time types.  Since I never used Release 3, I don't
    know how well these were handled.  IBM made it sound, at one point,
    as though these were stored formatted.  That would not be good.
    
  o There are many objects to manage (e.g., table spaces, index spaces,
    and storage groups).  This makes it very tough to rapidly bring
    up a database for prototype purposes.  It also makes it tough to
    do anything independently of a DBA.
    
  o As far as I know, precompilers are available only for FORTRAN, COBOL,
    and PL/1.
    

    Take it from someone who's been there: Rdb is much nicer than DB2!  If
    you would like to talk more about DB2, send me mail at GUIDUK::KRUG.

    Would someone care to explain the nature of the new announcements
    by IBM on DB2 and the "future" CDD?

    Moved on the assumption that one more us of fell into the trap of
    WRITEing when we meant to REPLY.
    
    
              <<< ETC:[NOTES$LIBRARY]RDB_VMS_COMPETITION.NOTE;1 >>>
                         -< Rdb/VMS against the world >-
================================================================================
Note 130.0                       got what I need                      No replies
ZPOV01::JEFFREYCHOY "Master_of_none"                  5 lines  10-MAY-1988 03:07
--------------------------------------------------------------------------------

    Thanks for all those informative notes on DB2.
    
    Reply 4 has given me exactly what I need to fight IBM.
    
    Regards,Jeffrey Choy
    

A couple of minor self-corrections!  #<8^|)

>  o In spite of anything you may hear to the contrary, someone needs
>    to know JCL.  It crops up in a lot of places.  The utilities, which
>    supposedly can be run interactively, always failed.  The only solution
>    was to write JCL and run them in batch mode.

    The utilities always failed *at our installation when run interactively.*
    
>  o The dictionary is centralized, not distributed like CDD.  This means
>    that if one user is modifying a table, DB2 might lock out all users
>    from the entire user during the update.  I saw processes come to
>    a standstill for hours for no apparent reason, later traced to this
>    cause.  The only relief from this problem is to create different

    This means that if one user is modifying a table, DB2 might lock out
    all users from the entire *database* during the update.  

    
    Paul    

Re: .4
>>           -< Is Release 3 the new version? what impact for us? >-

    Release 3 was available June '87.  Release 4 is the new release. I'm
    afraid I lost touch before this announcement, so I don't know what it
    means for us.  Rumor has it that Release 4 includes referential
    integrity. 

    As many may know, there is a book called "A Guide to DB2" by Chris
    Date. I got a copy earlier this year, so Murphy's law of buying
    books on changing products came into effect: the second edition
    has just been published.                    
    
    It's by Date and White now, ISBN is 0-201-09428-2.
    It covers release 3. Previous replies to this note indicate that
    release 4 will be out soon.
    
    When I had the chance to take a quick look at the new edition, I
    was hoping to find a list of the changes introduced in release 3.
    But there isn't one.
    
    The only snippet of information I can offer is that release 3 offers
    precompiler support for APL and BASIC in addition to PL/1, COBOL,
    FORTRAN and assembler.
    
    	Andrew.

    re .7
    
    I got it wrong again.  IBM manuals always say something like "Release
    2" and I always assumed that was 2.0.  Actually it was 1.2!  So
    the new version of DB2 happens to be 2.0.  Oh well!

Speaking of DB2.

Does anyone have a list of DB2 components/tools that are either included with
the system (like Rdb/VMS has RDO,RDML,RDBPRE,RMU), or purchased separately like
RALLY, DTR, TDMS, TEAMDATA, etc,  and a list of limits for DB2, things like MAX
TABLES, MAX INDICES, MAX SIZES, etc. I have a few, but would appreciate getting
any and all you might have. 

Also, what are the programming languages supported?

ttfn...lc

>    I have a few

    Please post them, and any pointers to Digital Review, DEC Professional,
    or any other magazine or whatever that has done comparisons. I could
    have done with this last week....

I am currently writting 4 articles to be published in a special BUFFER
this summer. They will be feature/functionality comparsions of Rdb/VMS
versus INGRES, ORACLE, SYBASE, and DB2. 

Once completed I will post in this notesfile where the reports can be had
even before the BUFFER comes out.

ttfn...lc