gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) (06/10/91)
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
geckhard@ringer.cs.utsa.edu (Gary Eckhardt) (06/11/91)
In article <10595@idunno.Princeton.EDU> gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) writes: >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. -------------------------------------------------------------------------------- Gary B. Eckhardt Univ. Of Texas at San Antonio geckhard@ringer.utsa.edu -------------------------------------------------------------------------------- "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..." --------------------------------------------------------------------------------
doherty@vax1.tcd.ie (06/11/91)
In article <10595@idunno.Princeton.EDU>, gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) writes: > 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 Doherty@VAX1.TCD.IE
gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) (06/11/91)
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
geckhard@ringer.cs.utsa.edu (Gary Eckhardt) (06/12/91)
In article <10628@idunno.Princeton.EDU> gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) writes: >In article <1991Jun10.223018.26414@ringer.cs.utsa.edu> geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes: >>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. >>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. -------------------------------------------------------------------------------- Gary B. Eckhardt Univ. Of Texas at San Antonio geckhard@ringer.utsa.edu --------------------------------------------------------------------------------
jmcarli@PacBell.COM (Jerry M. Carlin) (06/12/91)
In article <1991Jun11.224403.9172@ringer.cs.utsa.edu> geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes: >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. >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. -- Jerry M. Carlin (415) 823-2441 jmcarli@srv.pacbell.com To dream the impossible dream. To fight the unbeatable foe.
mark@jtsv16.jts.com (Mark Booker ) (06/13/91)
In article <1991Jun11.224403.9172@ringer.cs.utsa.edu> geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes: In article <10628@idunno.Princeton.EDU> gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) writes: >In article <1991Jun10.223018.26414@ringer.cs.utsa.edu >geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes: >>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? -- ____________________________________________________________________________ Mark B. Booker Customer Support Manager | mark@jtsv16.jts.com J.T.S. Computer Systems Ltd. | uunet!jtsv16!mark Toronto 416-665-8910 FAX 665-8258 | ...![sun!]suncan!jtsv16!mark
davem@uvmark.uucp (Dave Meeks) (06/13/91)
In article <10628@idunno.Princeton.EDU> gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) writes: >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. >> 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. > >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. ||
martin@adpplz.UUCP (Martin Golding) (06/13/91)
In <1991Jun11.224403.9172@ringer.cs.utsa.edu> geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes: >In article <10628@idunno.Princeton.EDU> gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) writes: >>In article <1991Jun10.223018.26414@ringer.cs.utsa.edu> geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes: >>>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. >>>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: {mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp
ray@uvmark.uucp (Ray Daignault) (06/13/91)
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: >>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. > >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. > >-------------------------------------------------------------------------------- >Gary B. Eckhardt Univ. Of Texas at San Antonio geckhard@ringer.utsa.edu Un >-------------------------------------------------------------------------------- >"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
jim@uvmark.uucp (Jim Todhunter) (06/13/91)
In article <1991Jun11.224403.9172@ringer.cs.utsa.edu> geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes: >In article <10628@idunno.Princeton.EDU> gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) writes: >> >>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 Internet: uvmark!jim@merk.com, UUCP: uunet!merk!uvmark!jim Phone: (508) 655-3700, Fax: (508) 655-8395, Telex: 5101011619 VMARKUNIVERS
ghm@ccadfa.adfa.oz.au (Geoff Miller) (06/13/91)
jmcarli@PacBell.COM (Jerry M. Carlin) writes: >In article <1991Jun11.224403.9172@ringer.cs.utsa.edu> geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes: [...stuff about translates from other files deleted...] >>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. Geoff Miller (ghm@cc.adfa.oz.au) Computer Centre, Australian Defence Force Academy
gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) (06/13/91)
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
gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) (06/13/91)
In article <797@adpplz.UUCP> martin@adpplz.UUCP (Martin Golding) writes: > >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
martin@adpplz.UUCP (Martin Golding) (06/14/91)
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
bsms@hippo.ru.ac.za (Malcolm Sainsbury) (06/15/91)
In <1991Jun11.224403.9172@ringer.cs.utsa.edu> geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes: >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. Sorry you are way off on this one. We have used PICK for about ten years and this is precisely one of its strong points. Including a dictionary item that is an element of another file is about the easiest thing you can do in the PICK database. The range of 'correlatives' extends way past that kind of simple operation. You have been misinformed on that one. I seriously doubt that you have actually used PICK if you couldn't manage to do this. >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 >.... 5 days > >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. Again this is strange to me. I dumped out 150 MB onto a pretty slow streamer tape on a PC version of PICK this afternoon and it took about 30 minutes. That is slow admittedly, but *nothing* like the figures quoted here which are bizarre. I simply don't believe them. -- Malcolm Sainsbury - Dept of Business Information Systems - Rhodes University Internet: bsms@hippo.ru.ac.za Phone: +27 [0]461 22023 xt 244 uucp: ..!uunet!m2xenix!quagga!hippo!bsms Fax: +27 [0]461 25049
jim@uvmark.uucp (Jim Todhunter) (06/15/91)
In article <2431@ccadfa.adfa.oz.au> ghm@ccadfa.adfa.oz.au (Geoff Miller) writes: > >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. > >Geoff Miller (ghm@cc.adfa.oz.au) >Computer Centre, Australian Defence Force Academy Vmark's uniVerse product also supports a dynamic linear hashed file structure. UniVerse also supports a btree structure. In the uniVerse environment, alternate indices maybe used with any hashed, dynamic or btree file. As in the Prime Information environment, the indices may be defined as real or virtual fields. -- James W. Todhunter, Manager, Software Development Vmark Software, Inc., 5 Strathmore Road, Natick, MA 01760, USA Internet: uvmark!jim@merk.com, UUCP: uunet!merk!uvmark!jim Phone: (508) 655-3700, Fax: (508) 655-8395, Telex: 5101011619 VMARKUNIVERS
jhagen@talos.npri.com (Jarom Hagen) (06/17/91)
doherty@vax1.tcd.ie writes: >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. Is the library you refer to a callable interface? Can I build a front end and use PICK on the back end on a Unix system? Jarom -- ------------------------------------------------------------------------------- *Not paid for and/or endorsed by National Political Resources Incorporated. 602 Cameron St, Alexandria VA 22314 (UUCP: ...uunet!uupsi!npri6!jhagen)