Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ogicse!cvedc!mcspdx!adpplz!martin
From: martin@adpplz.UUCP (Martin Golding)
Newsgroups: comp.databases
Subject: Re: PICK dbms/os on UNIX
Message-ID: <808@adpplz.UUCP>
Date: 14 Jun 91 16:32:10 GMT
References: <10628@idunno.Princeton.EDU> <1991Jun11.224403.9172@ringer.cs.utsa.edu> <797@adpplz.UUCP> <10709@idunno.Princeton.EDU>
Organization: ADP Dealer Services R&D, Portland, OR
Lines: 25

In <10709@idunno.Princeton.EDU> gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) writes:

>Martin, Could you please elaborate on this.  I'm interested in both
>issues, but your reference to a lack of "crash protection" made me take
>an extra dose of coffee.

Real Pick systems are pure virtual memory. The memory resident files contain
both data and structure information (the pages of memory are doubly linked
lists).  There's no provisions for uncommitted transactions. So when a Pick
system gets a _hard_ crash, the database can be considered trash. (Actually,
only the active parts :-). This doesn't necessarily apply to the Pick-like
systems, BTW; I'm sure the Prime and Universe and Unidata marketing people
would be more than glad to describe their methods.

This may not be a problem, if the MTBF and MTTR (reload save and reapply
a days activities) are acceptable. In exchange for a certain amount
of vulnerability, _small_ systems are _cheap_ (eg, we used to run up
to 32 users on 128k machines) and _simple_ (we support several thousand
machines that have no operators or administrators).


Martin Golding    | sync, sync, sync, sank ... sunk:
Dod #0236         |  He who steals my code steals trash.
A poor old decrepit Pick programmer. Sympathize at:
{mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp