Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!ur-tut!sunybcs!boulder!hao!ames!amdcad!sun!pitstop!sundc!seismo!uunet!munnari!mulga!ditmela!george
From: george@ditmela.oz (George michaelson)
Newsgroups: comp.databases
Subject: Re: Unify/Accell Transaction Logging, etc.
Message-ID: <289@ditmela.oz>
Date: 13 Feb 88 01:59:01 GMT
References: <315@fairlight.oz>
Organization: CSIRO Division of Information Technology
Lines: 57

From article <315@fairlight.oz>, by gary@fairlight.oz (Gary Evesson):
> 
> 	There's one of us here! We are currently running UNIFY 3.2, but will
> be going over to 4.0 as soon as someone finishes porting it for our machine. I
> would also like to here more from UNIFY users!
> 
> 						gary@fairlight.oz
> 						Gary Evesson.

I used UNIFY extensively in the UK, doing a passwd & mail table management
system for ucl-cs unix hosts (this was before "yellow pages" were freely
available) and found it a real pain in the neck. 

I am amazed at how badly unify code ported between sun vax & pyramid
implementations  and the effect it had on the CPU.  Any non-trivial lookup 
completely floored the system. I could kill a dual processor pyramid 98x
faster than 40+ users running scheme and doing s/w development
and that is saying something. 

The fixed length string definition & the dumb use of <space> for string padding
was a complete nightmare. To do anything I had to write a whole bundle 
of wrap-up inside my code to cover for the abysmal data model. As regards the
mapping of nice names to numeric values I regard the use of non standard C
such as $define and  the binary only pre-processor code as a wicked mistake.
The C interface worked indifferently with the BSD universe compiler,
trivial changes to libcpp & inclusion of a small sysV to BSD portability
library could have covered for this problem. 

Anything less than a complete DB re-build inevitably corrupted the binary
files. I never managed to take a tapedump, only sun offered text-to DB
dumping (which is a magic way to port code between DB packages but I guess
UNIFY want to lock users in..) which was a drag. NFS use was impossible.

ACCEL I cannot speak for: nobody at ucl was remotely interested in emulating
an IBM PC screens system on their applications. 

I suspect there is no RDBMS package which correctly addresses the problems
of existing UNIX practice and has come up out of the micro world. UNIFY
was tested against a large field and we jumped reluctantly at the only
product that attempted to offer a bit of everything.  It was a the best
of a poor bunch.

If you're designing applications that use the ENTER and SQL screens stuff
extensively, have lots of PC's and staff understand them & their mode of
operation, don't want to understand UNIX or C nor do anything unusual
UNIFY and ACCEL may well address your problem. If you can program and have
used vi or emacs forget it.

	SQL sucks. even Ted Codd says so 

ACSnet:	G.Michaelson@ditmela.oz.au	DISCLAIMER: my views are my own.
Postal:	55 Barry St, Carlton, Vic 3053
Phone:	(03) 347 8644 				Fax:	(03) 347 8987
-- 
ACSnet:	G.Michaelson@ditmela.oz.au
Postal:	55 Barry St, Carlton, Vic 3053
Phone:	(03) 347 8644 				Fax:	(03) 347 8987