steve@tellab3.UUCP (Steve Harpster) (10/02/85)
The following is a memo written by a co-worker describing the problems
we have found with the Unify database system. I thought it would be
of general interest.
Tellabs, Inc.
subject:
In Search Of...
A Better Database
date:
October 2, 1985
from:
Michael Skowronski
IL Engineering
C243 x2788
_E_N_G_I_N_E_E_R_'_S__N_O_T_E_S
1. Introduction
This paper describes the problems that we are currently
having with the commercial database UNIFY, and suggestions
as to what should be done about it.
2. The Problems With UNIFY
We have found some major flaws with the database UNIFY,
as well as finding some irritating bugs. The problems are
categorized into several different groups:
o+ Problems due to bugs in either UNIFY and/or XENIX.
o+ Problems due to the way that UNIFY is implemented.
o+ Problems that can be overlooked, worked around, or just
plain ignored.
2.1 UNIFY bugs
The biggest problem with UNIFY is that it just doesn't
always do what we need it to do. The first major bug that
we found was that the record locking scheme that is used to
handle multiple processes just does not work. This means
that semaphores have to be used to make sure that we don't
collide when reading a record. UNIFY will not admit that
the bug exists.
We have found that UNIFY does not check itself when
attempting to access a record, which have caused countless
segmentation violations or illegal instruction traps. This
is not a very helpful way to fail; one would expect their
code to trap the error and then return to the caller with an
error.
When UNIFY does trap an error, instead of returning to
the caller, UNIFY instead calls exit() with a status of 99
- 1 -
October 2, 1985 Tellabs, Inc.
(database error). Again, this is not very helpful, since
our code must try to recover from any problems gracefully.
2.2 Implementation drawbacks
Minor bugs have been encountered that show a sloppiness
in the implementation of UNIFY. These problems include not
allowing an underscore in the names of records or fields
(the manual says that UNIFY does handle underscores), b-
trees cannot use a COMBINATION field as an index, numeric
fields are restricted to 9 digits, etc. Many of the 'C-
callable' routines that are included in UNIFY are either
duplicates of other subroutines with a different set of
variables, or are so specific that they can only be used
under certain circumstances. An example of this would be a
routine that is used to read the _f_i_r_s_t record in the
database, and then have to use another routine to read
_a_l_l__o_f__t_h_e__o_t_h_e_r__r_e_c_o_r_d_s in the database. This is workable,
but very kludgy.
The database records are stored at random, using the
first available record in the file for storage. Keys are
kept for each record, but the keys are not kept in an ISAM
order, causing long delays when searching back in time,
since each record must be read before determining if it is
what is wanted.
2.3 Poor Implementation and Support
This final section is what really stings about UNIFY.
Many of the routines supplied for sorting and searching just
don't work as documented. I have made some test routines
that are supposed to print out _e_v_e_r_y record in the database,
but they will only print out some of them. Other routines,
when used, cause segmentation violations.
The support service included when buying UNIFY was poor
at best. The people that I talked with had very little
knowledge about the way UNIX worked, and in some cases the
personnel refused to admit that a problem existed. When I
discovered that the database was not successfully locking
out requests while updating the database, the response I got
from the service manager was that the locking mechanism
_a_s__d_e_f_i_n_e_d__b_y__U_N_I_F_Y worked great, and that I should send in
our code so that their experts could debug _o_u_r problem.
- 2 -
--
...ihnp4!tellab1!steve
Steve Harpster
Tellabs, Inc.bob@luke.UUCP (Bob Speray) (10/10/85)
In article <293@tellab3.UUCP> steve@tellab3.UUCP (& Harpster) writes: > >The following is a memo written by a co-worker describing the problems >we have found with the Unify database system. I thought it would be >of general interest. The quoted memo was a real indictment of the Unify dbms product. "Problems with Unify", "major flaws", "irritating bugs". Its tone was -massive troubles with that Unify system-. This response is to balance the thrust of the original memo. Unify does not have the "major flaws" that were claimed. record locking? WHO has this problem solved on Unix? Every variant solution around has its limitations. Unify uses John Bass locking in our environment( Plexus P60, sys3) - an absolutely exclusive lock that locks out reads as well as writes. It works fine, AS DEFINED, but has severe limitations on concurrent reads. It's ok for concurrent writes. Unify not checking itself? I think this describes the documented misuse of access/gfield. You request a record by key without checking the return code, then attempt to get data out of the record. The gfield call aborts because there is no record to get data from. You want Unify to check that the record exists at the gfield call and return an error code to you then. You didn't look at the return code after the access. You've got an application bug. poor error recovery? Unify returns error codes for recoverable errors and exit(99)'s on non recoverable errors. We had a similar criticism but learned that non recoverable errors were of two sorts - corrupt database or application program error. Both type errors should disable continuation of a process in a production environment. Unify does define a way to load local error handling routines but they should never return, only exit. Our error handling routines produce a core dump on the way out. underscores in field and record names? A real bug. Supposedly fixed in the latest release. no b-trees on combination fields? Yup, just as defined. A limitation of course. limit of 9 digits in numeric fields? Only on display, using Unify screen utilities. The data is stored as a long and contains valid values. This display limitation is a bother. different calls for reading first record and for reading rest of records? This observation is similar to the observation that Unix defines different calls for opening a file and for reading it. Is this a valid criticism? records stored in random order? I don't understand this point at all. The phrases, "long delays when searching back in time", must refer to a particular function that takes a long time to run. I don't see the connection to record storage strategies. sorting and searching routines don't work? We use some of the sorting and searching routines and have no trouble with them. A simple test program that doesn't work properly demonstrates a bug in Unify or a bug in the application. Seems straightforward to discover the fact of the matter. you claim you've discovered a bug in the Unify record locking implementation? and Unify support wants to see your test program in order to duplicate the problem? so what's the issue? "ha ha, i found a bug but i wont help you fix it cause you don't think there is one." poor support? Sounds more like a personality conflict. I'd prefer support persons who are highly qualified programmers, intimate with the coding details of the system, and anxious to find bugs in the system and correct them, but I'll accept someone who listens to my problem, conveys the problem to the development staff, and follows through with a recommendation to me on how to continue. Our interactions with the Unify support office have been adequate. Are there real problems with Unify? We have been using Unify for several years now in a complicated multi-user application. We have discovered some unusual aspects of Unify but have been relatively happy with the product and the support. In fact Unify provides the best dbms product in the Unix market for our application, by far. We have 150+ record types in our schema, 200Mb of data, and a stringent response time requirement. Other vendor products might be ok for other applications but none I know of can provide this capacity or performance. Robert Speray Benetics Corp
pavlov@hscfvax.UUCP (840033@G.Pavlov) (10/11/85)
We ran into a number of problems with Unify during a trial period as well. Unfortunately (for Unify) most were different from yours. I did have a decent support person, though. One thing that I can't understand: how can someone purchase a DBMS without testing it first ???
jerry@uwmcsd1.UUCP (Jerry Lieberthal) (10/11/85)
> > We ran into a number of problems with Unify during a trial period as well. > Unfortunately (for Unify) most were different from yours. I did have a > decent support person, though. > > One thing that I can't understand: how can someone purchase a DBMS without > testing it first ??? We also ran into problems with Unify, but not during a trial period. Actually, there was only one candidate for a DBMS at the time (UNIFY), and the price for a University was *appealing*, so we got it without a trial period. In retrospect, though, it will probably serve the simplistic needs of our users (as long as it doesn't keep on dumping core, etc.). -- ------------------------------------------------ - jerry University of Wisconsin-Milwaukee Computing Services Division {ihnp4, uwvax, uwmacc}!uwmcsd1!jerry uwmcsd1!jerry@wisc-rsch.ARPA
goldman@ucsfcca.UUCP (Eric Goldman) (10/13/85)
[] In article <134@hscfvax.UUCP> pavlov@hscfvax.UUCP (840033@G.Pavlov) writes: > > We ran into a number of problems with Unify during a trial period as well. > Unfortunately (for Unify) most were different from yours. I did have a > decent support person, though. > > One thing that I can't understand: how can someone purchase a DBMS without > testing it first ??? What problems with UNIFY did you have? --Eric S. Goldman, MD University of California, San Francisco School of Medicine
steve@tellab3.UUCP (Steve Harpster) (10/14/85)
> ...how can someone buy a DBMS without testing it first.
Easy. UNIFY wouldn't let us test it first. They sold us the manuals
ahead of time and according to those, UNIFY looked pretty good. I hear
they will give you demos but these don't show the full functionality of
the system (the C interface anyway which is what we primarily use).
--
...ihnp4!tellab1!steve
Steve Harpster
Tellabs, Inc.mikes@3comvax.UUCP (Mike Shannon) (01/01/86)
In article <340@luke.UUCP> Bob Speray writes > record locking? WHO has this problem solved on Unix? Every variant > solution around has its limitations. Unify uses John Bass locking > in our environment( Plexus P60, sys3) - an absolutely exclusive lock that > locks out reads as well as writes. It works fine, AS DEFINED, but > has severe limitations on concurrent reads. It's ok for concurrent writes. What's the nitty gritty on 'John Bass' locking? How about some history, tradeoffs, etc? thanks, -- Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikes