Conference ulysse::rdb_vms_competition

Max,

If they are Oracle Advocates do not be too negative about Oracle.  Talk about 
the things that Rdb does well.  Most of the stuff that is in the Rdb 
Presentation (863).  Focus on the areas that Rdb has strength over Oracle.
Talk about client/server capabilities of SQL Services vs. the same database
on multiple platforms.  Often customers want access to a large database from
other platforms and SQL/Services provides this.  Discuss the multiple 4GLs and
CASE tools that will work with Rdb.

I really believe that if you try to give a presentation about the bad things
Oracle does, Oracle supporters will not receive it very well. 

I hope this helps some,

Steve Farlow @STO 

    The new (August '91) 863 is available at 
    NOVA::PM01:[dbs_help.public.present]p863*.*
    
    Steve gives good advice.  Say stuff like "ORACLE is good for (and think
    up something benign)... and Rdb let's you interoperate in a
    heterogeneous environment."  Talk about Rdb's strengths (tuning tools, 
    Digital support, etc.) and talk about NAS big time!  We all need to
    become NAS experts, the sooner the better.  It's our big advantage over
    the competition.                              
    
    Bruce 
    
    

    I printed out the latest 863 presentation and read it over. In general,
    I think it is an excellent presentation, but in the interests of
    accuracy I do have some comments on the script.
    
    First, it should be run through a spelling checker - there are some
    spelling errors and they grate against some of us :-). The following
    refer to slide nos.
    
    5) Having been on the CODASYL committee back in the early 80's (as an
    "ISV" rep), I can certainly state that CODASYL is/was not a standard,
    but a body that constructs a proposal to ANSI for a standard. The
    database standard was always in such flux that they never did propose
    an official standard (to the best of my knowledge). They were moving
    (in my time) closer to a relational model :-).
    
    16) On SQL Module Language - "Once compiled they are a subroutine and
    any VAX language can call them". True in some sense, but the language
    does have a LANGUAGE construct to make the binding easier.
    
    78) The text doesn't match the slide - it says that NETWORK is granted
    SELECT, but the ACL clearly states NONE for NETWORK.
    
    84) The acronyms MAC and TCB are not explained (the following slide
    provides a good guess for MAC, but TCB?
    
    91) The text has absolutely nothing to do with the slide shown on the
    page.
    
    Again, thanks for a great job.
    
    Peter

>    5) Having been on the CODASYL committee back in the early 80's (as an
>    "ISV" rep), I can certainly state that CODASYL is/was not a standard,
>    but a body that constructs a proposal to ANSI for a standard. The
>    database standard was always in such flux that they never did propose
>    an official standard (to the best of my knowledge). They were moving
>    (in my time) closer to a relational model :-).

I believe that ANSI eventually standardized what they call the Network
Database Language (NDL), which is the official "Codasyl Database"
standard.  No vendor, to my knowledge, ever bothered to make their
Codasyl dbms conform to the NDL standard.  Instead, they pretty much
stuck to the Codasyl reports of the early 80s.

Hal

With respect to some of Peter's comments:

    5) Having been on the CODASYL committee back in the early 80's (as an
    "ISV" rep), I can certainly state that CODASYL is/was not a standard,
    but a body that constructs a proposal to ANSI for a standard. The
    database standard was always in such flux that they never did propose
    an official standard (to the best of my knowledge). They were moving
    (in my time) closer to a relational model :-).

Hal's comment in .4 was correct. ANSI X3H2 eventually completed work on
the Network Database Language (NDL) standard, ANSI X3.133.1986.  ISO also
published a corresponding document (word-for-word identical, except for
such obvious editorial matters as the name and number of the standard),
but I don't have the ISO number directly to hand.  The NIST representative
to X3H2 has been surveying the Federal Government bureaus to see if any of
them currently depend on any product that claims conformance (even partial
conformance) to the NDL standard; last time I asked about his progress, I
was told that he had uncovered no such dependencies.  As a matter of fact,
the NDL standard must be 1)reaffirmed, 2)replaced, or 3)withdrawn by the
end of this year (standards must have one of those three actions every 5
years); unless I hear something *soon* from within Digital, I will vote to
withdraw the NDL standard.
    
    16) On SQL Module Language - "Once compiled they are a subroutine and
    any VAX language can call them". True in some sense, but the language
    does have a LANGUAGE construct to make the binding easier.

Well, Peter, there's really a more fundamental reason why the LANGUAGE
clause exists.  Digital is in an almost unique position with our VAX
architecture and its calling standard.  In the standards world, and in the
world of most vendors, code written in one language cannot call or be
called by code written in another language.  Because of that, SQL module
language provided the LANGUAGE clause so the database system could
"emulate" a subroutine in the specified language---e.g., if LANGUAGE
FORTRAN were specified, then the resulting module would "look like" it had
been written in FORTRAN as far as the calling program was concerned.

Regards,
   Jim    

    Thanks, Hal and Jim, for your very informative and interesting
    comments.
    
    My main concern was the use of the term "CODASYL" to reflect a
    standard; that term was widely bandied about in the 80's by DB sellers
    and meant very little since there really was no standard. From your
    comments the actual standard do not appear to have had a large effect
    :-).
    
    And I do realize the benefit of the SQL Module LANGUAGE clause. I guess
    my real objection was to the "Once compiled" term. In actual use, you
    would probably decide what language you wished to use, add/alter the
    LANGUAGE clause and *then compile*.
    
    Peter