Conference ulysse::rdb_vms_competition

    Take a look at the VIDA notesfile.  This topic is fairly well covered.
    
    {nova, quill, credit, debit, webstr}::vida
    
    Jim

                         Cullinet's KnowledgeBuild

  Cullinet demonstrated KnowledgeBuild in our office last week. It was 
brief, but here are the high points.

  Access to the development utilities is via menus (like Rally, but not
nearly that number of menus). Once into a menu option (build application,
modify application, etc.) the video form displays optional actions across
the bottom of the screen (like Teamdata).

  The editor used in KnowledgeBuild can be either TPU or EDT. All command
keys can be remapped to fit any users preference.

  Application development is about average --- design and create the 
database, create the forms from the database definitions (again like 
Rally), add context-sensitive options (help, pop-up windows, field 
verifications, etc.), then tie the forms together to create menus. 

  The forms creation and definition requires some front-end work. Since
field display attributes are input at the time a field is created, rather
than after the field is used, the developer needs to have at least some
of his application designed before he starts KnowledgeBuild.

  Once the application is complete, the user issues a generate command.
KnowledgeBuild then generates PDR, an intermediate 4GL. The PDR is then
used to generate structured Cobol, Basic, or Fortran (developers choice
of language) with embedded SQL statements. Hence, the user learns new
development utilities, but not a new language. That will be extremely 
appealing to the MIS people.

  KnowledgeBuild can access IDMS/SQL and RMS files. It can also access
mainframe IDMS/R databases via KnowledgeLink, Cullinet's implementation
of VIDA.

  The niceties I really noticed were in the general development style of
the product (there isn't a lot of menu navigation to remember), and the
fact that if you create pop-up windows that are context-sensitive,
KnowledgeBuild will not allow the window to accidentally overlay the 
sensitive field. That's nice. Field validation can be done from IDMS/SQL 
tables or RMS files.

  Input Forms can be used as report forms as well. The input form is copied
and its use is relabeled from "data-entry" to "output".

  As for IDMS/SQL, its release has been delayed again until March. It also
is not designed to support VAXcluster systems. We were also told something
peculiar about it. One customer asked if he could create or delete fields
in the database interactively while the database was online. The answer
was, "no, if you add or delete fields, you have to unload/reload the 
database." That would indicate the presence of pointers in the "relational" 
database (maybe like Cincom's Ultra). It also could have been a 
misstatement. I'll try to clarify it, and put an answer in here.

  The biggest feature that will sell KnowledgeBuild is the fact that it
generates a maintainable 3GL from a 4GL environment. Beyond that, it is
not particularly extraordinary or radically different from the market of
4GLs already in place.

  As I get more detail on these products, I'll put the data in here.

---- Michael Booth

I have been working on a benchmark support IDMS/SQL for about two days.
So far I have noticed:

GOOD:

- installs easily uses VMSINSTALL
- Knowledgebuild generates 3gl code in either COBOL,FORTRAN or BASIC
- Sales people are very aggressive - after laying off 25% of the company in April
  they see the VAX environment as savior of the company
- Sales people are telling customers that Cullinet is a CMP, but fail
  to mention that CMP agreement doesn't cover database or 4GL
- Two page centerfold-style ads in Digital Bash trade rags.

BAD:

- No direct VAXCLUSTER support - support only thru remote access from
  one other nodes thru DECNET.  One node in cluster does 75-95% of all the work.
  Lock management done thru mapping of global sections (OLD TECHNOLOGY)
  No word on when full VAXCluster support will be available
- Support hashing, but can't modify hashed key
- No support for "drop column". Column dropped by defining a new table
  and converting data.  This little tidbit was found out after Cullinet
  claimed to be compliant -- nice surprise.
- Support personel are refugees from IBM environment (they love VMS)   
  but are not very knowledgeable about VMS yet.

P*sses me off:

- Sales reps are telling customers that Digital isn't serious about database.
  Would someone care to argue...

STAY TUNED FOR MORE........................................................
    

    Other knockoffs that I'm aware of:
    
    - no record level locking
    - level 3 consistency (without snapshots, they must lock the entire
    	table to achieve this?)
    - a process for each user (I'm not too sure if integration with a TP 
    	monitor could be easily achieved...wouldn't work well with
    	KnowledgeBuild development environment)
    - 254 columns per table (I'm not really sure if this is significant).
    
    
    I'm no expert on relational database products, so take these
    observations for what they're worth.
    
    
    Rick C.
    

Just wait a little longer to see how serious Digital is....

On the order of "how important is more than 254 columns per table":  Ya
know that $90 Million Census contract DEC won?  Well, Rdb/VMS was the
only database system that could meet their requirement for 2000 columns
per table.

    Re: .4, .5 and the number of columns per table
    
    But *please* don't push this as a feature unless the application
    really, really needs that many fields in a column.  Just because
    it can be done, that doesn't mean it's a good idea....

Here are a few items I've observed about Cullinet. 

	1.) CULLINET SOFTWARE IS MUCH BUGGIER than any DEC product
I've ever used.   This issue, coupled with Cullinet's financial
posture, should dissuade anyone. 

	2.) Cullinet's link between IDMS/R databases and the VAX is
architecturally inferior to our VIDA solution.  With VIDA a user can
directly issue interactive queries against the IDMS/R database using
familiar tools (Teamdata, Datatrieve, SQL, RDO...).   VIDA distributes
processing between the IBM and the VAX transparently to the user. 

The Cullinet alternative requires users to undertake a cumbersome two
step operation: first copy [portions of] a data table to a VAX
IDMS/SQL database, only then can the local database be queried. 

	3.) Knowledgebuild is superficially similar to Rally, but it's
more limited than Rally in the type of applications it can generate.
As a result, developers using Cullinet spend large amounts of time
tweaking metacode to resolve situations that Rally can handle
directly.  

	4.) Rdb is much cleaner in the database administration arena. 

	5.) I believe Cullinet has told my client that we're "not
seriously committed to databases". 

    I'm wondering whether Cullinet has resolved the problem of hashing,
    Vaxcluster support and "drop column" (refer to note 69.3). 
    Also, Cullinet has claimed that they will integrate CDD/+ in their
    future release, is this true?
    Currently, we are evaluating KnowledgeBuild and it is one of the
    choice we have as the tool for the application development in our
    project.

    I don't think any of those problems are yet resolved.
    
    Yes, Cullinet claims that they will support CDD/Plus in some future
    version. But the amount of support is very uncertain. At this point, a
    good guess would be that the Cullinet tools could read Rdb data
    definitions from CDD/Plus. But when that gets done is anyone's guess.
    
    By all accounts the Cullinet tools still appear fraught with bugs.
    Until that situation improves, I have grave doubts about the wisdom of
    employing the tools for all but the simplest applications.
    
    ---- Michael Booth