Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site tellab3.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!tellab1!tellab3!steve From: steve@tellab3.UUCP (Steve Harpster) Newsgroups: net.database,net.unix,net.micro.pc Subject: Unify Database Problems Message-ID: <293@tellab3.UUCP> Date: Wed, 2-Oct-85 09:26:18 EDT Article-I.D.: tellab3.293 Posted: Wed Oct 2 09:26:18 1985 Date-Received: Thu, 3-Oct-85 06:17:08 EDT Reply-To: steve@tellab3.UUCP (& Harpster) Organization: Tellabs, Inc., Lisle, IL Lines: 149 Xref: watmath net.database:93 net.unix:5778 net.micro.pc:5488 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. Brought to you by Super Global Mega Corp .com