Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!phoenix!gpmenos
From: gpmenos@phoenix.Princeton.EDU (G. Philippe Menos)
Newsgroups: comp.databases
Subject: Re: PICK dbms/os on UNIX
Message-ID: <10628@idunno.Princeton.EDU>
Date: 11 Jun 91 12:16:50 GMT
References: <10595@idunno.Princeton.EDU> <1991Jun10.223018.26414@ringer.cs.utsa.edu>
Sender: news@idunno.Princeton.EDU
Organization: Princeton University
Lines: 32

In article <1991Jun10.223018.26414@ringer.cs.utsa.edu> geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes:
>In article <10595@idunno.Princeton.EDU> gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) writes:
>>uses PICK running on UNIX, using Univers, I think.  Does anyone have any
>>opinions on the wisdom or "non-wisdom" of running PICK on Unix inthis
>
>PICK was a good idea at the time it was developed, leading the way for
>other database systems like itself, but it has grown sorta obsolete.
>

Thanks for your views.  I wonder if you could elaborate on the term
"obsolete."  Could you give me some practical implications.  Later you
mention some operational inefficiencies.  But what else do you have in
mind by the term obsolete?  Are there, for example, implications for the
development of imaging applications?  Are you saying that newer dbmss,
like Ingres, are more modern because they are more open, by virtue of
SQL?  And, how would you compare PICK with --say-- Ingres, or some other
relational dbms?  I would appreciate any further comments you may have
to offer.

>The biggest problem with PICK that I saw was it's file structure.  For some
>...
>Working with a 9-Track tape drive on the Honeywell system, it took more than
>72 hours to complete a file restore.  Working with a 9-Track tape and the
>PC version of PICK, it took closer to 5 days.  I have had no experience with

This does sound excessive, to say the least.  But could you tell me the
approximate size of the database in question, so I have a better idea of
of the scale of this inefficiency.

Thanks,
Phil Menos
Systems Administrator, Princeton University Libraries