Conference ulysse::rdb_vms_competition

    Interestingly enough, you may wish to contact one of the members
    of the VAX ATTRACT HP Conversion Team in Colorado Springs.
   
    They are dealing with the tools CINCOM produces to migrate HP IMAGE
    access to VAX ULTRA so have first hand experience. I have discussed
    ULTRA vs RDB at least once with them. The point I remember is that
    we do not loose in performance. Seems VAX ULTRA is a bit of a pig.
    
    Hope this helps

    Digital is currently involved in a cooperative marketing agreement with
    Cincom. I have had an opportunity to work with Cincom's ULTRA database
    management system.  Here is a summary of what I know about the product.
    Note that this discussion is only concerned with the current release of
    ULTRA for VMS.  It would be inappropriate for me to discuss or
    speculate about CINCOM's intentions for future enhancements.
    Nevertheless, I hope that this will give you a general overview for
    ULTRA, and how it contrasts with other database management systems,
    such as RDB. 

    ULTRA is a layered database management system.  The lowest layer deals
    with the physical implementation of the database files. Superimposed on
    top of this "physical" layer are a "logical" layer and a "view" layer.
    The Database Administrator (DBA) must define the database at all three
    layers. The disadvantage to this layered approach is that ULTRA is not
    as easy to use as other products, such as RDB, which assume control of
    their physical implementations without user involvement.  In
    particular, the DBA must be acutely aware at all times of the physical
    implementation of the database, which, as I describe below, may not be
    particularly "relational". 

    On the other hand, at least in theory, the database at the highest
    level is independent of the specific physical implementation, thus
    giving the DBMS a certain level of flexibility. In this case, the
    layered approach requires the interface between the physical and the
    various higher layers to be staticly defined prior to run time. Ultra
    provides software for the user to define this static implementation. 

    There are currently two supported physical layers.  One of these is
    essentially the same as CINCOM'S old "TOTAL" database management
    system.  This makes extensive use of physical pointers, and thus
    requires the database designer to think in non-relational terms. There
    are two kinds of files in the physical layer: "Master" files, which
    have hashed keys, and "Variable" files, which are linked off the master
    files by physical pointers. The only way to perform a sorted traversal
    is by combining a master file with a variable file; hashed keys do not
    permit sorted traversals.  The current version of ULTRA does not
    support ISAM master files. 

    The other supported physical layer is simply the use of RMS files. This
    includes support for indexed sequential files.  However, there is
    currently no journalling or recovery built into the RMS physical layer.
    My experience with ULTRA has been exclusively with the "TOTAL" physical
    layer, so most of my comments pertain to that implementation, rather
    than RMS. 

    The physical layer of the database is not dynamically changeable. If
    the DBA wants to modify the physical definition of the database, he or
    she must first define the intended changes, then shut down the database
    (i.e., make it inaccessible to all users), and "recompile" it, which
    can take some time for a large database.  You cannot define new files
    in the database "on the fly".  Clearly, this approach is not
    particularly "user-friendly".  On the other hand, it is possible that
    the static nature of ULTRA helps performance, but I do not have any
    information on that issue. 

    At the physical layer, the DBA lays out the locations and sizes of
    fields in each file, but does not define any of the field attributes.
    It is at the next, "logical", level, where this takes place.  An
    example of a field attribute defined at the logical level is whether or
    not a field is text or numeric.  In addition, the DBA assigns a logical
    name for a field at this level.  No two fields in a given database can
    have the same logical name. Not all fields defined at the physical
    layer need have a corresponding logical name assigned to it at the
    logical layer, but they must if they are to be accessed by user views,
    which do not know about physical field names. Logical names are always
    defined in terms of physical field names; a DBA cannot define logical
    names in terms of other logical names. 

    The final, highest level of the database is the definition of the
    Logical User Views.  Views are defined in terms of the fields in the
    "logical" level.  Views can bring together fields from more than one
    file, using hash key lookups or physical file pointers as necessary. By
    defining the file access in this way, a program using views need not
    worry too much about the physical layout of the database, nor the
    traversal required for retrieving the data; instead, the program
    requests a "record" from a view, and the view definition pulls together
    the physical files, traversing any pointers or performing any hashed
    lookups, as necessary.  That's the theory, anyway; in practice, the
    programmer sometimes *does* sometimes need to know about the physical
    implementation, particularly when debugging the software. 

    All database file navigation is defined within view definitions. With
    views you can define pointer relationships between physical files. Any
    of the various ULTRA primitives (INSERT, DELETE, etc.), when invoked by
    a program, use the view navigation definition to automatically update
    or traverse the keys and pointers between files. Correctly defining
    file navigation in a view can be extremely difficult, because it
    requires knowing the often mysterious (and undocumented) rules that
    ULTRA follows when processing a view.  Trial and error seems to be the
    only approach. Views also support various classes of access protection
    for physical files. 

    ULTRA comes with a preprocessor for various programming languages. The
    preprocessor translates ULTRA database statements embedded in the code
    into native statements of the source programming language. ULTRA
    operations are also integrated into CINCOM's 4GL, Mantis.  In all
    languages, including MANTIS, the basic operations are the same.  All
    operations act on the database through a view--programs do not interact
    with the physical layer--and only one record at a time; the GET
    operation, for example, retrieves a single record from a view.  To the
    programmer, this is not fundamentally different from how one would
    process RMS files.  On the other hand, this approach is radically
    different from the approach of many relational products, such as
    Ingres, which operate on collections of records at a time. 

    Ultra provides some very basic support for restricting database queries
    to specified selection criteria. View definitions can specify exact
    matches of a field against some constant value.  Alternatively, the
    query itself can contain exact values of key fields to match against.
    This only applies to key fields, however, and the matches must be
    exact.  There is no support for any other type of selection criteria,
    such as partial keys or comparisons like "greater than", "not equal
    to", etc. I consider this a significant limitation.  The use of hashed,
    rather than ISAM, "master" files is a major factor in this set of
    limitations.  One small useful feature is that, because variable files
    are doubly linked off their master, it is possible to read through them
    in reverse order. 

    ULTRA comes with a utility, DBAID, for defining and performing ad hoc
    operations on views. Another utility, SPECTRA (which I am not familiar
    with), is an ad-hoc reporting tool. There is another utility for laying
    out the physical and logical layers of the database, DBA. 

    ULTRA is the VMS implementation of Cincom's product for the IBM, called
    SUPRA. One of the strongest selling points for CINCOM is the
    compatibility of the database architecture across both systems. CINCOM
    also adheres to this principle of compatibility in its application
    software.  The current drawback is that ULTRA currently lacks many of
    the highly touted "state of the art" features of some of its
    competitors; however, and I believe that future releases will address
    many of these issues, thus improving its competitive position. 
    
    -- Mike 

I found your writeup quite educational!

    Thanks for the good information in the earlier notes.  I'm in a
    competitive situation with Cincom at present.  We are bidding into
    an IBM account where MANTIS is used extensively; however the CINCOM
    database software is not being used.
    
    The project were are bidding for is to be realised on relational
    database and as usual I'm plugging for Rdb.  Now it is very unlikely
    that we can dislodge MANTIS because of multi-vendor, trained staff
    etc. issues.  We do have a chance with the underlying db.  Now my
    questions!
    
    Has anyone had an Rdb/Mantis experience?
    
    Is it totally unlikely that Cincom would build a DSRI interface?
    
    Would we (local office) be ill-advised in building a DSRI interface?
    
    
    One other point, our customer has been informed that Cincom intend
    making Supra available on the Vax in the very near future.  Has
    anyone else heard this? 
    
    Many thanks,
    
    -Dermot

    It is totally unlikely that Cincom would build a DSRI interface
    to Mantis.
    
    I would think it would be futile to attempt to design one yourself.
    Mantis is a real language. It is quite complete. Designing an interface
    for such a product would not be a small undertaking.
    
    Cincom has been talking about VAX Supra for about 18 months. The
    exact release date has not been mentioned. But it appears that this
    summer is probable.
    
    ---- Michael Booth

	I deleted Note 70.3 at the moderator's request because it
    contained some futures information on RALLY/Rdb.  This is an
    edited version.
    
    

	Review of Cincom Systems ULTRA, MANTIS, and SPECTRA Products


Sources:

		The information used for this review is taken from product
	literature, and from the Cincom course "ULTRA General Concepts".
	The course covered database design using ULTRA, as well as
	application development under MANTIS, and end user database
	querying using SPECTRA.

		This information should not be taken as the "gospel truth", but
	rather should be used to indicate points which should be further
	investigated particularly in a competitive situation.  Where possible
	I have compared ULTRA/MANTIS to Rally/Rdb as well as to the
	general capabilities offered by most relational database products
	and application development packages.

		Finally, I would ask that you not divulge the source of this
	information since I was required to sign a statement indicating
	that the information would only be used for educational purposes.
	Also, you should be aware that Cincom is a CMP, and thus any
	criticism of their products needs to be dealt with delicately.


Overview:

		In general, I was very unimpressed with ULTRA, MANTIS,
	and SPECTRA.  For the software developer, I thought the user
	interface was cumbersome.  For anyone familiar with relational
	databases, they will find a great deal of functionality
	missing from ULTRA.  However, for someone coming from a
	hierarchical or network database, ULTRA will probably make
	them feel more comfortable than a relational database.  The
	products also have major performance problems, and are
	riddled with inconsistencies and a few bugs.  Few, if any,
	features of VMS are utilized by Cincom.  The fact that these
	products were ported from IBM to Digital shows through in many
	areas.  The software is around 3 to 8 years behind other
	competing products in most areas.

		On the plus side, I would expect that a customer who is
	now using a 3GL without a forms package will still see a
	productivity boost during application development.


User Interface:

		ULTRA, MANTIS, and SPECTRA applications development
	and administration are run from a menu based system.  For the
	novice user this can be an advantage.  However, for the experienced
	user the menu interface is cumbersome.  The situation is
	aggravated by the lack of command stacking (such as in Rally or
	ALL-IN-1).  Thus, to traverse menus you must go one screen at
	a time.  The only accelerator is a "go-to-the-top-menu" function.
	Most software developers would prefer a command line interface.

		Perhaps the most annoying facet of the interface is the
	total inconsistency of key functions.  Each of the three products
	uses a different layout of keypad functions, and none of these
	follows either the EDT or ALL-IN-1 style.  Thus, as the user moves
	down different menu trees (and thus into different products),
	the key mappings change.  In fact, under SPECTRA the Enter key
	must be used as a command line terminator instead of the Return
	key which is used in all of the others.  Under SPECTRA, the Return
	key just leaves the user sitting at his command thinking "gee, the
	system is sure slow!".  The products do not allow key mappings
	to be modified.

		In several sections the user must enter many lines of
	text (e.g. for database definitions).  To do this, the user must
	use the provided single line editor.  Only when developing
	MANTIS programs may the user elect to use a standard VMS full screen
	editor.  Even here however, one must be cautious since unless the
	program is explicitly saved (by choosing a separate menu
	item), the program will be lost when leaving that menu (without
	any warning).

		Of the three products, only SPECTRA provides any indication
	that the software has accepted a command.  In some parts of
	the software a "working" message is displayed when substantial
	processing is occurring;  in other parts, there is no indication.

		MANTIS, ULTRA, and SPECTRA maintain user accounts such
	that one must login to its system in addition to logging into
	VMS.  There does not appear to be a way to tie the VMS account
	into the Cincom account to avoid this double login.


Database design:

		Despite all of the product brochures hyping ULTRA as a
	great relational database, it is NOT a relational database.  Cincom
	has added the concept of logical views to their hierarchical
	database TOTAL.  One good point is that they have done a nice
	job in placing referential integrity into the database
	definition itself.  An example of referential integrity would be
	an employee database where a department must exist for each employee.

		Because of its hierarchical basis, the amount of effort
	required to design the database is substantially greater than
	with other relational products.  The database developer must
	layout both the conceptual normalized tables, and the logical
	views.  This is the same as with most other relational databases,
	except that know naming convention is exploited to fill out
	an initial logical view.  In many products this is done to
	keep the programmer from having to manually enter the same
	information twice.  In addition, ULTRA requires the database
	designer to explicitly define the links between key fields in
	the various relations.  This is required because of ULTRA's
	hierarchical base.


Database maintenance:

		Ultra supports both before and after image journaling.
	The database may be split across several files.  Currently, the
	addition of new fields to a relation (or increasing the size of a
	field) requires that the database be unloaded/reloaded unless
	sufficient extra buffer space has been pre-allocated.  In the
	future, Ultra is supposed to get an active data dictionary so that
	this will not be necessary.  There is no automatic way to determine
	which Mantis programs have been effected by a change.

		Rdb also supports before and after image journaling.
	However, it allows fields to be modified or added to a relation
	without reloading the database.  

		Security is done on a view by view basis.  Since queries
	may only be done on pre-defined views, this is sufficiently
	restrictive.  Note however, that it requires the database
	administrator to define many views.  Security information is
	maintained within Cincom's own user accounts.  Cincom does
	not make any use of VMS Access Control Lists (ACLs).

		I do not know what capabilities ULTRA has for access
	of databases across the network.  Cincom does not have a
	product similar to our Data Distributor.  Currently, I do not
	know of any database product which can handle atomic
	transactions across the network.  This is a difficult problem
	although most database vendors are researching it.


Database query language:

		The database query language is derived from Ultra's
	hierarchical base.  Currently, queries may only be done on
	primary key fields.  A query only retrieves a single record.  Thus,
	to get all the required records, one must loop doing repeated
	database queries.  Since non-key searches are not allowed,
	you must do a sequential search through all records.  In the
	near future, Cincom is supposed to support indexing on non-key
	fields.  However, the queries will still be restricted to exact
	value matches.  There is no method (beyond reading all records
	in a loop, and doing your own checking) to retrieve all of the
	records which fall within a range of values.

		Queries may only be performed on a logical view; a
	query may not retrieve records based on values in multiple
	views.  This can result in an explosion of view definitions
	particularly in situations where you wish to allow the user
	to perform ad hoc queries on a desired subset of the fields.
	Each and every logical view must be pre-defined by the
	database administrator.  In addition, each user of the
	view must be given the security privilege to use it.


Interactive query tool (SPECTRA):

		SPECTRA is similar to our DATATRIEVE product.  It
	provides an interactive database query language.  I am not
	sure whether it may be run from batch.  The results of the
	query are displayed on the screen.

		SPECTRA allows for the type of queries traditionally
	associated with a relation database.  One can do joins,
	selects, and projects involving multiple relations.  Ranges
	are allowed as well as matching between values in different
	relations.

		Cincom does not provide any spreadsheet capability,
	nor any graphing functionality.  Since the database is not
	DSRI compliant, these capabilities can not be picked up with
	third party products.

		Cincom does not provide any query-by-example product.
	This powerful capability is built into RALLY and requires
	no additional programmer effort.


Forms package:

		Cincom touts MANTIS as a 4GL.  However, MANTIS is
	actually only a forms package and programming language.
	The forms portion of it is similar to our FMS product with
	the added capability of data mapping to a variable (as
	provided with our TDMS or 3GL with CDD).  Another nice
	feature of MANTIS forms is that range checking may
	be done on fields.  I believe, however, that type checking
	(i.e. whether the input is character or numeric, for example)
	is tied to the field so that mixed type fields are not
	supported.

		MANTIS defines the viewing area as a 255 column by
	255 row workspace.  Only one segment of this area is
	displayed at a time.  To overlap forms, the programmer can
	define them elsewhere in the larger area.  Also, one can define
	a single form which is multiple screens horizontally or
	vertically.  Keys are defined to allow the user to move
	one screen worth at a time within the larger area.

		Scrolling is done differently than with Digital forms
	products.  There is a direct correspondence between an
	array of records and what is displayed.  Thus, a 20 record
	array has 20 "scroll" lines on the screen.  Should the user
	move beyond the number displayed, the MANTIS program must
	shift array elements around and re-read data from the database.
	In FMS or TDMS, the programmer would typically define an
	record array much larger than the displayed number of records
	and change the portion of it that is displayed.  This minimizes
	or eliminates the need for re-querying the database.

		Using RALLY, the programmer is relieved of having to
	build forms and menus.  These are built by RALLY using the
	data definitions, and the specification of what data should
	occur on the screen.  RALLY also uses the concept of a
	larger than one screen display work area.  RALLY's concept
	of scrolling follows the normal Digital method (which by the
	way takes advantage of hardware scrolling features in VTxxx
	terminals).  Since RALLY takes care of much of the tedious work,
	new applications may be prototyped much more quickly.  Then
	once the functionality has settled, the programmer may go back
	and using a form editor make the displays more visually
	appealing.

		If you are interested in comparing MANTIS to Digital
	products, you should also investigate the as yet unannounced
	DECforms product (aka VAXforms).


Programming options:

		The MANTIS programming language can best be described
	as similar to interpreted BASIC.  Since it is an interpreted
	language, there is a large performance penalty.  This is
	particularly true since the database querying limitations
	often force the programmer to perform looping functions.  I do
	not know if MANTIS keeps a partially interpreted form of each
	line for somewhat faster execution in loops (such as is done
	by DATATRIEVE).

		MANTIS does provide a method of calling programs
	written in other languages, though I do not know how this is
	done or what performance penalty may be paid.  It does not
	look like MANTIS supports any data structures beyond simple
	arrays, integers, character strings, and floating point
	numbers.  Thus, there does not appear to be something akin
	to Fortran structures.  Also, there does not appear to be
	support for global variables.  In particular, the lack of
	complex data structures means that in many applications
	much more code will need to be written as the logic must
	be placed in the code instead of being driven by more
	powerful data structures.

		By choosing MANTIS, the customer must train his
	programmers in a non-standard language.  In addition, the
	customer gives up the ability to use any of the VaxSet program
	development tools, and the VMS symbolic Debugger.  This is
	a substantial penalty, and should not be overlooked since the
	VMS development environment is considered by most to be the
	best in the industry.

		The main advantage of MANTIS is that it is available
	across both Digital and IBM systems.

		RALLY provides higher performance applications since it
	is not interpreted but is in effect table driven.  I have
	heard estimates that RALLY is only 10% slower than a well
	written application in a 3GL.  RALLY also provides its own
	development language.  However, RALLY does much more before the
	programmer need write any code.  RALLY also provides a
	facility to call 3GL programs.


Performance:

		As mentioned, the combination of interpreted MANTIS and
	single record query retrievals causes MANTIS/ULTRA applications
	to run slowly and use a great deal of resources.  ULTRA was
	designed for use in traditional database processing/transaction
	processing applications where information is queried based
	on key fields.  In these situations, it is likely to perform
	well.


Futures Considerations:

		If the customer is at all interested in workstations,
	it is doubtful that Cincom will support DECwindows even in the
	medium to long range.  Thus, any applications written in MANTIS/ULTRA
	would need to be run out of terminal emulation windows -- using
	a non conforming user interface style.

		It is doubtful that Cincom will add support for parallel
	processing to ULTRA.

		Cincom has been promising for a long time that they will
	deliver a MANTIS compiler.  It is yet to be seen when (or if)
	this will be delivered, and whether the code produced would
	comply with the VMS Calling Standard.

    
    	My understanding is that SUPRA is the equivalent of ULTRA but
    on IBM systems.  Thus, VAX SUPRA is most likely just a renaming
    of the ULTRA product at the next scheduled release.
    
    	As for DSRI interfaces, one of their Sales Support people had
    indicated that this was being worked on, but was several years away.
    Note also that Cincom is often very late in delivering functionality
    so it may be quite awhile before they are DSRI compliant.
    
    Kevin @STO

    Supra is a full featured truly relational database. It is based
    on the 1977 ANSI SPARC model (three-schema model). Supra has competed
    quite effectively against DB2 in the IBM market. I think Supra has
    about 7% of that IBM market.
    
    Supra is far superior to Ultra, and will be more difficult in
    competitive situations.
    
    ---- Michael Booth

    Supra is based upon three schema architecture. Although Cincom would
    have you believe that Ultra is just a release behind Supra, it is
    actually just a different interface to the old TOTAL data base system.
    As such, it is based upon an entirely different two schema
    architecture. Supra was over 5 years in the making. Converting Ultra
    and maintaining compatibility with existing customers would be
    extremely time consuming and expensive. I would encourage anyone
    to looke deep under the covers at a 'Supra' release for VMS. The
    best that they will be able to do is to maintain application level
    transparency between IBM and VAX via Mantis. 
    
    Actually, Cincom barely registers any market share in the IBM world.
    They have won a few strategic accounts, but the way that they abandoned
    their old Total customers will prevent a mass conversion to Supra
    (and I hope Ultra). If someone is looking at Cincom, make them dig
    up a pile of references..... if they can.
    
    Jamey Nordby
    

    The last Computer Intelligence survey (12/87) for buying intentions
    in the IBM database market showed:                   
                               
    IBM 55%                                                            
    Cullinet 9%                                                        
    Information Builders 7%                                            
    ADR 6%                                                             
    Cincom 5%                                                          
    Software AG 5%                                                     
                                                                       
    So while Cincom is not super-successful, neither is anyone else.   
    Cincom is nonetheless generally as successful as its third party 
    competitors. 
    
    ---- Michael Booth              
    

    CI's buying intentions are almost worthless
    
    for the past 5 years, they have missed Software AG's actual results
    by almost 100%. This is becuase those who intend to by do not hear
    about them until the evaluation is already under way. IBM, Cullinet
    and Cincom traditionally get less than the published intentions.
    Jamey

    	Yesterday, I attended a meeting with Cincom to discuss how
    Cincom would recommend solving the customers problem.  First some
    background on the application.  To be brief, the crux of the problem
    is to display a form with 20-40 fields and allow someone to enter
    information in any of these fields.  Some of the information may
    define a range of values.  The application then searches through
    the database to find any matching occurences which are then listed
    in a scrolled form.
    
    	Such an application presents a real challenge to Ultra/Mantis
    since it currently does not support indexing or ranged searches.
    Cincom's approach was to in effect use indexed RMS files as indexes
    into the Ultra database which stores the actual information.  Thus,
    for each field which is likely to be often used for searching, setup
    an RMS file with field values as the key yielding an id which can
    be used to get the information from Ultra.
    
    	In the future after the release of Vax Supra, they indicated
    that it would provide support for indexed fields.  However, there
    will still be no way to specify ranges in your database query. 
    Thus, the developer will need to do looping and checking of indiviual
    records (in an interpreted language no less!).  Either of these
    implementations sounds messy enough that development and maintenance
    are likely to be atrocious.
    
    	Note also that Ultra does not have recovery capabilities for
    the RMS files.  I am not sure whether RMS Journaling could be used
    here since there would need to be synchronization between the Ultra
    and RMS journaling.
    
    	As a side note, I also learned that Mantis has a limitation
    that no array subscript reference may exceed 256.
    
    Kevin
    p.s. Also posted in the Rally Competitive Notes Conference

    I've had some feedback from a customer who had Mantis on loan and
    then sent it back.  The forms handling was unbelievable with virtually
    no cursor control possibilities.  He found that while it may have
    compared well in an IBM environment, it just did not match the
    competition on the VAX.
    
    This customer is an Ultra user (previously Total) and he has now
    purchased Rdb/Rally for new applications.
    
    Also he was of the opinion that Supra is no more than Ultra + LUVs
    (Logical User Views) + Spectra (query language).  Can anyone verify
    this.
    
    LUVs  - Too expensive on resourses, although the flexibility which
    is equivalent to an updatable view is impressive.  Customer decided
    against using the feature because of performance and risk of lost
    data.
    
    SPECTRA - An unreliable query language which in some cases gave
    different results to identical queries!  I believe Spectra is due
    for replacement.
         
    -Dermot
    
    I'll also put this in Rally competition.

    
    	Hi,
    
        I'd like to know if ULTRA is now working with SQL ?
    
        My guess is that it should, as a SQL access to a relational
     database (or so-called for ULTRA) seems mandatory now. 
     Can anybody confirm ?
    
     Thanks a lot
    
     Pierre-Yves
     

You appear to be labouring under the impression that because SQL is 'standard'
that something written against a 'SQL interface' can access any 'SQL database'.

This is far from the case.  You have to ask each vendor whether they support
SQL, and if so, which products they support SQL access to.

    
    	I was only meaning that today a vendor, commercialy speaking,
    'has'to propose a SQL interface. (You are right, any SQL access layer
    is not expected to work on any 'SQL database').
    
    I should have asked:
    Does Sincom propose a SQL interface working on an ULTRA data base ?
    
    Thanks
    
    Pierre-Yves