PICK dbms/os on UNIX

PICK dbms/os on UNIX

Post by G. Philippe Men » Wed, 12 Jun 1991 01:09:41



I'm seeing a demo of the Advance Library System, which
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
manner...  or any comments on PICK for that matter.

I hope I'm not addressing this to the wrong newsgroup.  If there's a
more appropriate place to ask this question, please tell me by e-mail.

[I support computing applications within the Princeton University
Libraries.]

Phil

 
 
 

PICK dbms/os on UNIX

Post by Gary Eckhar » Wed, 12 Jun 1991 07:30:18



Quote:>I'm seeing a demo of the Advance Library System, which
>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
>manner...  or any comments on PICK for that matter.

I worked with PICK running on a Honeywell platform for 3 years.  In my opinion,
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.

The biggest problem with PICK that I saw was it's file structure.  For some
reason, the process of reloading dictionaries and data from tape (i.e.
a full restore with modulo and separation expansion) took a silly amount of
time.  

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
it running on a Unix platform.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
"Phasers and Photon torpedoes are locked on, sir"
"Excellent, Mr. Worf.  You may fire at will."
"Firing...  Sensors report all strategic Iraqi positions are destroyed, sir"
"Captain, I sense a great sense of -- relief -- and joy on the planet..."
"That's good to hear, Counselor...Mr Crusher, set course for Beta-Alpha Psi,
  Warp Seven.."
"Course plotted, sir."
"Engage..."
--------------------------------------------------------------------------------

 
 
 

PICK dbms/os on UNIX

Post by G. Philippe Men » Wed, 12 Jun 1991 21:16:50




>>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.

Quote:>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

 
 
 

PICK dbms/os on UNIX

Post by dohe.. » Wed, 12 Jun 1991 17:47:57



Quote:> I'm seeing a demo of the Advance Library System, which
> 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
> manner...  or any comments on PICK for that matter.

> I hope I'm not addressing this to the wrong newsgroup.  If there's a
> more appropriate place to ask this question, please tell me by e-mail.

> [I support computing applications within the Princeton University
> Libraries.]

> Phil

Here at TCD we use Dynix running ounder PICK on a board in a VMS machine.
We will this summer switch over to running Dynix , under Pick on a DEC
UlTRIX computer. Dynix is a widely used library system which runs under the
PICK/UNIX combination on IBM, HP, MIPS and DEC machines.

Michael Doherty, Computer Lab, O'Reilly Institute, University of Dublin,
                 Trinity College, Dublin 2, Ireland

 
 
 

PICK dbms/os on UNIX

Post by Gary Eckhar » Thu, 13 Jun 1991 07:44:03




>>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

An Example:  In PICK, you use the dictionary approach to data, specifying
what that data looks like via formats, etc.  The only limitation was that
a dictionary could not go beyond the boundaries of the data file, i.e. I
could not include a dictionary item that was actually a data element from
another data file.  To me, that was limiting, and obsolete, because with
SQL you can develop Views that will let you do just that.

Quote:>>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.

The database was approximately 80 Megabytes or so.  We were close to
filling up a 100 meg disk.  This inefficiency has been demonstrated
to be the same across two different platforms that I've seen it run
on.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

 
 
 

PICK dbms/os on UNIX

Post by Jerry M. Carl » Thu, 13 Jun 1991 12:48:39



Quote:>An Example:  In PICK, you use the dictionary approach to data, specifying
>what that data looks like via formats, etc.  The only limitation was that
>a dictionary could not go beyond the boundaries of the data file, i.e. I
>could not include a dictionary item that was actually a data element from
>another data file...

Pick for many years has had the "T-file translate" that would do exactly
that. You include a field in the "master" file that points to a subsidiary
file and then you can do what in SQL terms would be a 'join' using the
key field.

Quote:>The database was approximately 80 Megabytes or so.  We were close to
>filling up a 100 meg disk.  This inefficiency has been demonstrated
>to be the same across two different platforms that I've seen it run
>on.

A couple of things would cause this slowness. The basic cause is typically
choosing a bad 'modulo'. All Pick files are hashed and if the size of the
primary area is too small everything goes into a doubly-linked list and
this can cause horrendous slowness. The other cause of slow restore times
is resetting the 'modulo' which causes a lot of recalculation.

Actually the primary performance problem I used to have was lack of
secondary indicies which caused a long delay for each retrieval. I
believe this is now fixed.
--

To dream the impossible dream. To fight the unbeatable foe.

 
 
 

PICK dbms/os on UNIX

Post by Geoff Mill » Fri, 14 Jun 1991 11:55:21



[...stuff about translates from other files deleted...]

Quote:>>The database was approximately 80 Megabytes or so.  We were close to
>>filling up a 100 meg disk.  This inefficiency has been demonstrated
>>to be the same across two different platforms that I've seen it run
>>on.
>A couple of things would cause this slowness. The basic cause is typically
>choosing a bad 'modulo'. All Pick files are hashed and if the size of the
>primary area is too small everything goes into a doubly-linked list and
>this can cause horrendous slowness. The other cause of slow restore times
>is resetting the 'modulo' which causes a lot of recalculation.
>Actually the primary performance problem I used to have was lack of
>secondary indicies which caused a long delay for each retrieval. I
>believe this is now fixed.

Prime "Information" (Pick as a software package rather than an OS) now has
what Prime call a "dynamic" file structure, in which choice of modulo and
resizing are basically automatic.  This works very well for us.  Also,
Prime offer a facility to create alternate key indexes, which can be
on calculated values or the individual values of multivalued fields.  Such
indexes are updated automatically.  Given that these things have been
done, I wonder when they will be (or if they are already) available in
other implementations of Pick under Un*x.


Computer Centre, Australian Defence Force Academy

 
 
 

PICK dbms/os on UNIX

Post by Martin Goldi » Fri, 14 Jun 1991 04:26:05





>>>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
>An Example:  In PICK, you use the dictionary approach to data, specifying
>what that data looks like via formats, etc.  The only limitation was that
>a dictionary could not go beyond the boundaries of the data file, i.e. I
>could not include a dictionary item that was actually a data element from
>another data file.  

Yeah, you could. Use T (translate) in the correlative or conversion field.
My (VERY small) experience with SQL is that Pick dictionaries have more
computing power but SQL is dynamic. For reasearch and experiment, SQL
wins easy. For software development, it's a tougher decision.

Quote:>>>Working with a 9-Track tape drive on the Honeywell system, it took more than
>>>72 hours to complete a file restore.
>The database was approximately 80 Megabytes or so.  We were close to
>filling up a 100 meg disk.  This inefficiency has been demonstrated
>to be the same across two different platforms that I've seen it run
>on.

This is indeed one of the problems of the Pick database design: the data
itself is hashed into the files. Another database would be faster by the
ratio of the index size to the data size, much faster if the index is
small enough to be cached.

The tradeoff is the speed with which individual records are accessible:
no file extents, no index blocks, just name.the.address.and.point.

The stuff the Pick system REALLY lacks is transaction management and
crash protection.

Martin Golding    | sync, sync, sync, sank ... sunk:
Dod #0236         |  He who steals my code steals trash.
A poor old decrepit Pick programmer. Sympathize at:

 
 
 

PICK dbms/os on UNIX

Post by Mark Booke » Fri, 14 Jun 1991 02:34:56







   >>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

   An Example:  In PICK, you use the dictionary approach to data, specifying
   what that data looks like via formats, etc.  The only limitation was that
   a dictionary could not go beyond the boundaries of the data file, i.e. I
   could not include a dictionary item that was actually a data element from
   another data file.  To me, that was limiting, and obsolete, because with
   SQL you can develop Views that will let you do just that.

This is not quite true. The use of a 'correlative' data dictionary
item: "Allows am attribute value to translate through another file.
The attribute referenced in line 2 of the dictionary definition item
is assumed to be an item-id in the specified filename."

This feature allows you to, say -- store a customer-id in a invoice
master file and using a 'correlative' dict item look-up the customer
master record by item-id and retrieve any field with-in that file, say
customer name.

   >>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.
   >
   >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.

   The database was approximately 80 Megabytes or so.  We were close to
   filling up a 100 meg disk.  This inefficiency has been demonstrated
   to be the same across two different platforms that I've seen it run
   on.

I also worked with 9-Track tape drives on Honeywell systems, Ultimate
to be exact and I never say any even close to what you have described
here. An 80MB disk was in the neighborhood of 1.5 hours. Maybe many of
your files were VERY poorly allocated with a large number of extents?

--
____________________________________________________________________________

J.T.S. Computer Systems Ltd.                |  uunet!jtsv16!mark
Toronto 416-665-8910 FAX 665-8258           |  ...![sun!]suncan!jtsv16!mark

 
 
 

PICK dbms/os on UNIX

Post by Ray Daignau » Fri, 14 Jun 1991 05:06:18




>>I'm seeing a demo of the Advance Library System, which
>>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
>>manner...  or any comments on PICK for that matter.

>I worked with PICK running on a Honeywell platform for 3 years.  In my opinion,
>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.

This was, I believe, an ULTIMATE machine.
Quote:

>The biggest problem with PICK that I saw was it's file structure.  For some
>reason, the process of reloading dictionaries and data from tape (i.e.
>a full restore with modulo and separation expansion) took a silly amount of
>time.  

Correct, under older versions of PICK and ULTIMATE, to expand a file system
required a save/restore procedure.  And, because the processor was fairly
slow, this was a very long process.

Currently, under the offerings by Vmark, Prime, and Unidata, the products have
auto-resizing files.  You should never have to reload data from tape unless
you have a system problem.

>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
>it running on a Unix platform.

>--------------------------------------------------------------------------------


Un

Quote:>--------------------------------------------------------------------------------
>"Phasers and Photon torpedoes are locked on, sir"
>"Excellent, Mr. Worf.  You may fire at will."
>"Firing...  Sensors report all strategic Iraqi positions are destroyed, sir"
>"Captain, I sense a great sense of -- relief -- and joy on the planet..."
>"That's good to hear, Counselor...Mr Crusher, set course for Beta-Alpha Psi,
>  Warp Seven.."
>"Course plotted, sir."
>"Engage..."
>--------------------------------------------------------------------------------

--
Raymond Daignault
...uunet!merk!uvmark!ray
 
 
 

PICK dbms/os on UNIX

Post by Dave Mee » Fri, 14 Jun 1991 03:11:34





>>>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.

I think you will find this statement in and of itself obsolete.  PICK when
it was originally developed was a great idea for a database system and more
often than not was much easier to use in it's grammer and logic than Oracle
style DBMS's.  A couple of the main problems with PICK were:
1) It didn't run on many machines, but on a limited number.  PICK was
originally a complete OS, not just a DBMS. This caused some problems as well.
2) Lack of communications.  About the only way to transfer data was by doing
tape saves and restores.
3) Lack of extended features and interoperability, such as Graphics, SQL,
interfacing with other products, etc...

However, about 5 years ago, VMark Software (the company who developed UniVerse)
came out with a version of PICK/Prime Information on Unix Platforms.  And,
though they have been the leader in PICK-based database/developement systems,
many other PICK companies are moving over to running on Unix based platforms.
In fact, UniVerse currently runs on over 35 different vendors hardware and
over 100 different types of machines.  So, it is truly an "open" application.
And in the last year or two, many versions of PICK, most notably UniVerse,
Unidata, and Ultimate (using a modified UniVerse product) have taken great
strides to remove any of the problems it may have had.  For example, VMark
Software, with their latest release, will have a networking package, Graphics,
WordPerfect interface, etc... with an SQL interface currently being developed.
Unidata has had an SQL interface for a while.  And, since both run on many
Unix boxes, both eliminate many of the previously perceived problems with
PICK.  I think you will find that, given the current state of the PICK
marketplace (especially with VMarks UniVerse, Unidata, Ultimate, and Prime
Information Plus), PICK is nowhere near an "obsolete" product, but instead
is a very stable, efficient, open-systems solution to software problems with
great features found in traditional Oracle based DBMS as well as features
those DBMS systems do not supply.  You will also find that products of
VMark as well as others are evolving very rapidly and many are offering
lots of new technological advances, such as GUI support, Networking, etc..
You will also find great performance (to the person who had problem with
the Honeywell tape, I have seen  complete file restores take less than an
hour on some systems.) and, in some cases, a more "open" environment.
And you will also find 4000+ proven, existing applications.  And all this,
usually for much less than other "traditional" DBMS.  

Quote:

>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

--
===============================================================================
David T. Meeks                    || "To bleed the lyrics for this song,
Software Engineer                 || to write the rites to right my wrongs.."
VMark Software, Inc.              ||
 
 
 

PICK dbms/os on UNIX

Post by G. Philippe Men » Fri, 14 Jun 1991 21:23:43



>The stuff the Pick system REALLY lacks is transaction management and
>crash protection.

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.

Thanks in advance for your thoughts.

Phil Menos
Systems Administrator
Princeton University Library

 
 
 

PICK dbms/os on UNIX

Post by G. Philippe Men » Fri, 14 Jun 1991 21:19:44


Although I addressed one of the two original questions on PICK, I
haven't said much since then, with the exception of one note asking for
clarification on the term "obsolete."  But I want to thank all those who
are contributing to this discussion:  I am reading it all with great
interest.  Thanks for the education.  

Phil Menos
Systems Administrator
Princeton University Libraries

 
 
 

PICK dbms/os on UNIX

Post by Jim Todhunt » Fri, 14 Jun 1991 08:45:25




>>Thanks for your views.  I wonder if you could elaborate on the term
>>"obsolete."  Could you give me some practical implications.  Later you

>An Example:  In PICK, you use the dictionary approach to data, specifying
>what that data looks like via formats, etc.  The only limitation was that
>a dictionary could not go beyond the boundaries of the data file, i.e. I
>could not include a dictionary item that was actually a data element from
>another data file.  To me, that was limiting, and obsolete, because with
>SQL you can develop Views that will let you do just that.

This is not correct.  PICK does allow the specification of dictionary items
that reference fields (columns) in other files (tables).  Also, both the
Vmark's uniVerse and Prime's Information products allow virtual field
definitions to include arbitrarily complex (or simple) application source
fragments.  This ability allows one to avoid some of the costly join operations
that must be done when using SQL as an access method.

--
 James W. Todhunter, Manager, Software Development
 Vmark Software, Inc., 5 Strathmore Road, Natick, MA  01760, USA

 Phone: (508) 655-3700, Fax: (508) 655-8395, Telex: 5101011619 VMARKUNIVERS

 
 
 

PICK dbms/os on UNIX

Post by Martin Goldi » Sun, 16 Jun 1991 01:32:10



Quote:>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:

 
 
 

1. Oracle Server on OS/2 versus UNIX: DBMS magazines Conclusion

"Conclusion

As you can see from Figure 1 [:-)], our tuned run of UNIX Oracle for
the batch transactions ran roughly twice as fast as it had under OS/2.
While there was an anomaly during the run -- transaction 30 overflowed
temp table space, which is why it does not appear in the graph -- we
think this general range of performance improvement will hold up when
we resolve that problem.

Things are far muddier with the accounting mix performance (Figure 2).
[...]
So what's the cause of this muddiness and the partial reversal of the
general trend of better performance under UNIX?  In a phrase: We needed
more time to tune, but we had to ship it.  [...]

Finally, we're quite sure that adding 16 more megabytes of memory,
which UNIX could make good use of while OS/2 could not, would not only
eliminate the anomaly but greatly widen the performance gap between
UNIX and OS/2 versions of Oracle Server."

(don't yell at me -- I'm just the messenger.  DBMS plans an extensive
survey/benchmarking of rdbms on several server kinds of platforms over
the next few issues.  DBMS is published by M & T Publishing, 501
Galveston Dr, Redwood City, CA 94063.  subscription inquiries to
(800)456-1859.  I've no relationship to this periodical.  I just read
it)

--


--


2. ASP and SQL Server (Converting varchar to money)

3. Pick and Pick-like for OS/2?

4. Select table with Isolation Level UnCommited/Commented?

5. Comparison of Pick and Pick/Unix requested

6. Developer2000.com online bookstore.

7. Which PICK, PICK-UNIX did you choose?

8. What's the equivalent of Oracle's decode function in Sybase?

9. need a DBMS Win+OS/2

10. Looking for a DBMS used with VRTX32 OS.

11. DBMS for OS/9

12. Picking correct DBMS