Unify Database Problems

[Steve Harpster]

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.