comp.databases.pick

Long-form reference · 9,460 words · about a 41-minute read

A group named after an idea rather than a product

Almost every group in the comp.databases.* branch is named after something you could buy. The branch list reads like a trade-show floor plan of the 1990s: Oracle in four groups, and then Sybase, Informix, Ingres, Progress, Paradox, FileMaker, Btrieve, Adabas, DB2, MySQL, PostgreSQL, Microsoft Access and SQL Server, dBASE and its imitators. A few break the pattern: comp.databases.theory for the academic argument, comp.databases.object and comp.databases.olap for approaches rather than products, and this one, which is named after neither a vendor nor a product but after a family of systems that share a way of thinking about data.

The one-line description distributed with the group in 1993 has never been rewritten. In the newsgroups file that the Internet Systems Consortium maintains for the world's news servers — the copy consulted for this page was retrieved on 26 August 2026 — the entry still reads exactly as it read in the control message that created the group:

comp.databases.pick Pick-like, post-relational, database systems.

The group is also still present in the companion active file, flagged y: unmoderated, posting permitted. Thirty-three years after the vote, no administrator has troubled to revise either line, which is a fair summary of how the Pick world was treated by the rest of the industry — not hostility, simply an absence of attention.

Readers reach this page from the comp.* hierarchy page, which covers the hierarchy itself and its group-creation machinery, and from an older address for the same group under the gateway's earlier URL scheme. That second address is kept because external links still point at it; it canonicalises here and carries no article of its own. What follows is the group's own documented history, and then the honest bulk: what the Pick system it discussed actually was, where it came from, who owned it across five decades, and why a platform running a great deal of the world's routine business computing generated so little printed trace.

The paperwork, and it is complete

Group creation in the mainstream hierarchies in 1993 left a paper trail, and for this group the trail survives intact in the news.announce.newgroups archive: a Request for Discussion, a Call for Votes, a second Call for Votes carrying a mass acknowledgement of votes received, and a Result. All four were posted by the same person, David Ruggiero of Seattle, and all four were approved into news.announce.newgroups by David C. Lawrence, who was then the moderator of that group and the issuer of its control messages. One point of period vocabulary is worth fixing before going further: in 1993 comp.* and its six siblings were the Big Seven. They became the Big-8 only in April 1995, when humanities.* passed its own vote.

The sequence ran as follows.

• 4 May 1993 — RFD posted to news.announce.newgroups and news.groups, and cross-posted to comp.databases, comp.os.misc, comp.sys.prime and comp.sys.stratus. The choice of cross-posts is itself the argument for the group, and is discussed below.
• 27 May 1993 — first CFV, opening a ballot that ran from the appearance of that posting. The second CFV, looking back, dates that appearance to 26 May.
• 11 June 1993 — second CFV combined with a vote acknowledgement listing the ballots received so far.
• 17 June 1993, 23:59:59 GMT — close of voting.
• 21 June 1993 — RESULT posted: the group passes 198:17.
• 1 July 1993, 21:04 GMT — the newgroup control message goes out over the network, after the standard five-day period for corrections. It carries both the description line for the newsgroups file and the charter again, and it was reissued unchanged in August 1994 and May 1995.

The charter that the voters approved is short, and its wording matters enough to give verbatim. The CFV, the second CFV, the RESULT and the control message all carry it identically:

"comp.databases.pick" will be a newsgroup for the discussion of the creation, administration, and use of the multitude of databases, operating systems, and applications environments which are generally known as "Pick-compatible", "Pick-like", "Pick-inspired", or "post-relational".

The charter then names the systems it means — "These include, at the least" — and the list is a snapshot of the market in the middle of 1993:

• The Pick Operating System, which the charter glosses as also known as Pick R83 and Advanced Pick — the standalone article, sold by Dick Pick's own company.
• "Vmark's Universe environment", as the charter spells it — the Unix-hosted implementation later written UniVerse.
• "Unidata's Unidata" — its closest competitor, from a Denver company of the same name.
• Revelation Technologies' Advanced Revelation and its Rev G products — the PC branch of the family.
• "Prime Computer's Prime Information system" — the minicomputer branch.
• "The PI/Open environment (developed by Prime, now owned by Vmark)" — a parenthesis that records a corporate transfer completed the previous year.

A second paragraph sets the scope of discussion:

This discussion will include, but not be limited to, programming theory and practice, database design techniques, efficient construction of application systems, practical system and database administration, experiences with and differences between various Pick-type products and implementations, technical questions and advice, and announcements of upcoming conferences, trade shows, and new products relevant to the Pick marketplace.

The CFV also restates the arithmetic every proposal in these hierarchies had to satisfy: the group would be created "if at least 100 more YES votes than NO votes are received, with at least 2/3 of the valid votes received in favor of the group". The full machinery of RFDs, votetakers and waiting periods is set out elsewhere in this directory and is not repeated here; what is worth noting is that this proposal cleared both conditions with room to spare, for a subject the wider network had barely heard of.

The RESULT records 215 valid votes counted with Ron Dippold's UseVote software — 198 in favour, 17 against — and the tally table prints the two tests side by side, both answered "Yes". The votetaker's own commentary is a small masterpiece of anticlimax: "The voting was remarkably uneventful." Five ballots arrived in an invalid or undecipherable format and were bounced back; all five were returned correctly. Four duplicates were received after the second CFV and resolved by the published rule that the later vote counts. Counting the names printed in the RESULT confirms the tally: 198 lines under the YES heading, 17 under the NO.

The word in the description line

The description line the world's news servers still carry calls these "post-relational" systems, and the charter puts the word in the same list as "Pick-compatible" and "Pick-like". It is not a neutral term, and the fact that a group's founding document adopted it is informative in itself.

"Post-relational" implies a sequence: relational databases came, and then something came after them. The MultiValue data model did not come after the relational model. Codd's paper defining the relational model was published in 1970; the work that became Pick was written for the United States Army in the middle 1960s and was running on real hardware before Codd's ideas reached any product. Calling it post-relational is a claim about where the industry ought to be going, dressed as a chronological description. Practitioners used it anyway. A UniVerse training course written by a working Pick engineer in the years after Dick Pick's death disposes of the word in a parenthesis, describing PICK as one of the "typeless, 'post-relational' (which means basically 'non-relational')" databases; the reference works that classify these systems note more carefully that they are usually filed under the post-relational heading although the data model in fact pre-dates the relational one.

The alternative labels have their own difficulties. "Pick" is a surname, and by 1993 several of the systems in the charter's list contained no code written by Dick Pick or licensed from his company; calling them Pick systems was accurate about lineage of ideas and inaccurate about lineage of code, which was precisely the subject of the litigation described later on this page. "MultiValue", the term the community settled on afterwards and the term the base description of this page uses, is the most honest of the set: it names the one feature that all the implementations share and that no relational product of the period had. The MultiValue database is now the usual encyclopaedic heading, with Pick as the historical name underneath it.

A small archival irony: on the English Wikipedia today the title post-relational database is a redirect, and it points at object-relational mapping, a different subject entirely. The name was a slogan, and slogans age badly. The description line in the newsgroups file, being administrative rather than promotional, has outlived it.

Who voted, and what the roll shows

Votes in these hierarchies were published with the voters' names and addresses attached, which makes the RESULT of June 1993 one of the few pieces of hard evidence about who this community actually was. The roll rewards reading.

Ninety-two of the 198 affirmative votes came from just eight corporate domains. Nineteen came from cv.com — Computervision, the name Prime Computer had taken for itself, and the company that had sold the Prime INFORMATION business to VMark the previous year; two of those addresses still carry PR1ME in the hostname. Nineteen more came from VMark itself, split between a British office at vmark.co.uk and a UUCP gateway spelled uvmark. Nineteen came from ADP, the payroll processor. Fourteen arrived through a UUCP path beginning mdcsc!, matching McDonnell Douglas Computer Systems Company, the corporate descendant of Microdata, on whose hardware the first commercial Pick system had shipped twenty years earlier. Eight came from Stratus, six from Dynix, five from Sybase, two from Sequoia. A further fifteen came from a single domain, rocket.com, which this page does not attempt to attribute to an employer, because it cannot do so with confidence and guessing from a domain name is exactly the failure mode this section is trying to avoid.

About forty more came from universities and research institutes: Cambridge, Oslo, Rice, Purdue, Drexel, Minnesota, Washington, Swarthmore, Mount Holyoke, the Space Telescope Science Institute. A few of those addresses have admin or ocs in the hostname rather than cs, which is suggestive of where an institutional Pick system tended to sit — in administrative computing, running the records of the place, rather than in the computer science department. It is suggestive and no more; three hostnames are not evidence.

Two details deserve a footnote each. Ron Dippold, whose UseVote program counted the ballots, is himself on the roll as a YES voter. And the seventeen NO votes are, as far as the record goes, simply seventeen names: the vote published how people voted, never why, and there is no honest way to reconstruct their reasoning from the archive. Some proportion of NO votes in any ballot of the period came from readers who objected to namespace growth in general rather than to the subject in particular, but that is a statement about the era, not about these seventeen people.

The RFD had made the case in exactly the terms the roll then confirmed. Its rationale argued that Pick discussion existed already but was scattered: "Revelation users chat in comp.databases; Prime Information users post into comp.sys.prime; Stratus Pick users use comp.sys.stratus, and the odd Pick OS article occasionally finds its way into comp.os.misc". That is why the RFD was cross-posted where it was, and the vote roll is the same map with names on it. The proposer's estimate of the market — "hundreds of thousands of systems, with millions of individual users" — is a claim made in a document arguing for a group, and should be read as such; but the electorate it produced was unmistakably professional.

What Pick actually is: items, attributes, values, subvalues

Most general references describe the MultiValue model in a sentence and get it slightly wrong. It is worth setting out properly, in the vocabulary its practitioners use, because that vocabulary is load-bearing and using it loosely is immediately visible to anyone who worked with these systems.

A Pick database holds files. A file holds items, which are what a relational system would call rows or records; each item has a unique item ID, its key. An item is divided into attributes, which correspond to fields or columns. So far this is ordinary. The departure is that an attribute may itself contain several values, and a value may contain several subvalues. Nothing is fixed in advance: attributes, values and subvalues are all variable in length and variable in number, and a record consumes only the space its contents need. A 1985 review of Pick on the IBM PC XT summarised the change of vocabulary in one line: commands are called verbs, records are called items, fields are called attributes.

Physically this is achieved with delimiter characters rather than with any table structure. Reference documentation for the UniVerse and UniData implementations records the delimiters exactly: attributes within a record are separated by a field mark, hexadecimal FE; values within an attribute by a value mark, FD; subvalues within a value by a subvalue mark, FC. Everything is stored as characters — there are no binary numbers on disk, and a floating-point value is written out in its printable form before being stored. A name of ten characters occupies ten bytes plus a delimiter; replace it with a name of twenty-one characters and it occupies twenty-one bytes plus a delimiter. There is no padding and no declared width, and the printing length carried in a field's definition governs reports rather than storage.

The consequence is that a single item can hold what a normalised relational schema would spread across a parent table and its children. The 1985 review put the example plainly: a medical office would normally keep a patient record and a separate detail record for each visit, whereas "Pick can keep all the patient's data in a single item", with an attribute called Visit gaining an additional value each time the patient attends. The whole item is read and written as a unit, so the common operation — fetch everything about one business object — is a single access rather than a join.

That access is by hashing. Pick files are hashed on the item ID: the file is divided into groups, the number of groups being the file's modulo, with a separation parameter setting how many 512-byte frames each group occupies. The hash of the key selects the group, and only that group is searched. Get the modulo right and retrieval by key is close to a single read; get it wrong and groups overflow into linked frames and performance degrades, which is why file sizing and periodic resizing were a permanent occupation of Pick administrators and a permanent subject in this newsgroup. Later implementations added self-resizing files that split and merge groups as data arrives: a UniVerse course of the 1990s teaches "static or fixed modulo hashed files" and "dynamic" files as two separate chapters.

Two further characteristics follow from the same design. There are no data types: everything is a string, and whether a given attribute holds a date, a quantity or a customer name is a fact about the application, not about the database. And, in the original systems, there were no transactions. The 1985 review is blunt about it — record locking yes, atomic multi-record updates no, no transaction log, restore from the last backup and lose everything since — and calls that approach standard for microcomputer databases of the day while adding that it expected more of Pick. Later implementations added B-tree secondary indexing, dynamic file allocation and, in the Unix-hosted products, SQL access; the record-size limits of the early systems went away.

The dictionary: a description of how a file is read

The feature that most often gets mangled in summaries is the dictionary, so it is worth being exact. When you create a file on a Pick-derived system you create two things: a data file and a dictionary file. They are physically separate. On UniVerse, creating a file produces one host file for the data and another, differently named, for the dictionary, and a pointer record in the account's VOC — vocabulary — file ties the two together under the single name the user types.

The dictionary does not constrain the data. It describes how to read it. A dictionary entry — a D-type or data field, in UniVerse terminology — names a field, says which attribute number it lives in, and carries display instructions: a conversion code, a column heading, an output format, and a marker saying whether the field is single-valued or multivalued. A second kind of entry, the I-type, which a UniVerse course of the period translates for beginners as an "imaginary field", defines a field that does not exist on disk at all: it is an expression evaluated when the field is read, deriving an age from a date of birth or a line total from a price and a quantity, or fetching a value out of a record in another file. The older Pick systems achieved much the same with an attribute definition item carrying a correlative.

Three consequences follow, and all three were arguing points in the group for its whole life. First, a file can have many dictionaries: nothing stops you defining several different views of the same attribute, with different headings, formats and derivations, and nothing stops two applications reading the same file through different descriptions. Second, because a dictionary is data, it can be listed, edited and reported on with the same commands as anything else — dictionaries have dictionaries, and the same course devotes a chapter to "the dictionary dictionary", the file that defines the data definitions. Third, and less comfortably, nothing enforces the description. If an application writes a date into attribute 7 of a file whose dictionary says attribute 7 is a quantity, the database will store it without complaint. Integrity in a MultiValue system is a property of the application code, not of the schema, because in the relational sense there is no schema.

First normal form, and being fair to both sides

The argument the group's name implies — Pick against relational — turns on a single technical point, and it is possible to state that point without taking a side.

Codd's relational model, published in 1970 and elaborated in the years immediately after, requires that the value in every field be atomic: no attribute may hold a set, a list or a nested table. This is first normal form, the most basic level of database normalisation, and it is treated as a precondition where the later normal forms are treated as guidance. A one-to-many relationship is therefore represented by putting the many in a second relation and joining on a key. What that buys is considerable: relations become closed under a small algebra, so queries can be composed and rewritten; an optimiser can choose an access path because the logical model says nothing about storage; new relationships can be added without restructuring existing records; and by the late 1980s a standard query language existed that could be pointed at any conforming product.

The MultiValue model declines the requirement. A repeating group stays inside the record, where the application expects to find it, and the cost of a join is not paid because the join was performed at design time. What that buys is also considerable: the most frequent operation in an order-entry or patient-records system is retrieving one whole business object, and that costs one hashed read; storage is compact because nothing is padded and no foreign keys are duplicated; and the application programmer's mental model of a record matches the record on disk.

Each side's advantage is the other's complaint. Relational practitioners point out that data outside first normal form cannot be queried by a general algebra: the query language has to know, case by case, whether it is looking at one value or many, and a question the designer did not anticipate may require code rather than a query. MultiValue practitioners point out that a normalised schema pays a join on every read to preserve a generality that most business systems never exercise, and that the industry spent the 1990s reintroducing denormalisation to make relational systems fast enough.

It is worth recording that the academic database community did not treat the question as closed either. Through the 1980s a substantial literature on non-first-normal-form relations — NF squared, in the notation of the period — worked on giving nested relations a formal algebra, and an international workshop under exactly that banner, "Theory and Applications of Nested Relations and Complex Objects", met at Darmstadt from 6 to 8 April 1987; its papers were published two years later as a volume in the Lecture Notes in Computer Science series. That research ran in parallel with the Pick industry and almost entirely without contact with it: the practitioners had a working product and no theory; the theorists had an algebra and no installed base. Neither community read the other's mail, and the newsgroup, whose readers were overwhelmingly practitioners, is a record of the first group's half of that non-conversation.

Origins: a database built for a helicopter that was never built

The lineage of Pick is tangled and widely misreported, so the following is stated with its sources and its uncertainties visible.

In the middle 1960s, TRW at El Segundo held a United States Army contract connected with the Advanced Aerial Fire Support System programme, which was to produce the Army's first purpose-built attack helicopter. The Army announced Lockheed as the winner of that competition on 3 November 1965 and awarded an engineering and development contract for ten prototypes on 23 March 1966; the aircraft became the AH-56 Cheyenne. TRW's job included tracking the programme's parts and progress, and the software written for it was the Generalized Information Retrieval Language System, GIRLS, implemented on an IBM System/360 by Don Nelson and Richard A. Pick.

Dick Pick's own account, given to the Los Angeles Times in 1985, is that about half a dozen employees spent nearly four years on the system, and that by the time it was delivered the Army had decided to scrap the helicopter. The dates fit: the Cheyenne's production contract was cancelled on 19 May 1969 and the programme was terminated altogether on 9 August 1972. Reference works generally date GIRLS itself to 1965, which is best read as when the work began rather than when anything was delivered. A trade account of 1986 adds two further dates and cheerfully declines to choose between them: that the system was held by legend to have come into being in March 1965, an anniversary Pick was said to celebrate with a birthday party, and that every Pick-based system nonetheless recorded 1 January 1967 as its official start date regardless of when it was actually installed.

The decisive fact is legal rather than technical. Because the work was done under a government contract, the resulting program was in the public domain, and Pick was free to build on it. Everything that follows — the licensing, the litigation, the three dozen differently named implementations — descends from that one clause.

Pick took the design to Microdata, a computer manufacturer in Irvine, California, and in 1973 the two entered into a contract that allowed the manufacturer to put the system on its machines. The product was called Reality, and it was the first commercial implementation, running on the Microdata 1600. Reality had been distributed in Britain by CMC from 1973; the two companies merged in 1976, and Reality machines were subsequently built at Hemel Hempstead. Reality ran in firmware, so a software upgrade arrived as a new configuration chip.

Then came the lawsuit that the industry never quite forgot. Microdata's position, as reported in 1985, was that it had purchased Pick's system rather than the right to use it. Pick Systems and Microdata formally severed their relationship in the middle 1970s; the litigation between them ended, in the summary of later reference accounts, with a ruling that both parties could consider themselves owners of the software and both were free to market it. The two lineages did indeed continue separately: by 1986 a trade survey could report that Reality, though still the most widely installed member of the family, was no longer based on licensed Pick Systems source code. This page does not give a settlement date, because the dates in circulation for it are not corroborated by any source it was able to consult.

Microdata itself passed to McDonnell Douglas. The date is a good illustration of how unreliable this lineage is in secondary sources: reference works variously give 1981, March 1983 and 1985 for that acquisition, and this page does not attempt to adjudicate between them. What is not in dispute is the direction of travel — the division became McDonnell Douglas Information Systems, went through a management buyout in 1993 led by twenty-nine of its own managers and directors, a London flotation in 1994, a renaming to Northgate Information Solutions in 2000, and is today part of NEC Software Solutions.

Dick Pick himself is the reason the family carries a surname. He founded Pick & Associates, later Pick Systems — incorporated in California in November 1982 — and licensed the system to anyone who would pay. The 1985 Los Angeles Times profile is unusually candid about how that went: a man "generally credited with devising one of the world's best operating systems for business computers" who gave customers a take-it-or-leave-it pitch and demanded licence fees of up to a million dollars, "many times the cost of competing systems". By the time the profile appeared he was trying to shed the mad-scientist image: prices had been cut dramatically at the prompting of a new wife who cared more about selling computers than about their innards, he was backing a marketing association of manufacturers using his system, and, after fifteen years of dressing casually, he had agreed to wear a tie to the office. A separate trade report puts a number on the installed base at the same moment: sixty thousand licensed CPUs running the Pick operating system at the end of 1985. Analysts quoted at the time thought it was too late, and one of their specific complaints was that Pick had licensed to second-tier manufacturers rather than to a DEC or a Wang. Pick died in October 1994, aged 56.

The diaspora of names

Because the underlying ideas were public and the implementations were licensed, ported or reimplemented rather than distributed from one source, the same system reached its customers under a couple of dozen different names. Reference accounts put the number of licensees at roughly three dozen between 1978 and 1984. The list below is not exhaustive — the charter's own list was explicitly a minimum — but it covers the systems that mattered and the ones the group discussed.

• Reality (Microdata, from 1973; later CMC, McDonnell Douglas, MDIS, Northgate, NEC). The original commercial implementation, in firmware on Microdata hardware, later re-engineered as a Unix application under the name RealityX so that it could run on other vendors' machines, and sold in that form as SeriesX.
• Ultimate (The Ultimate Corp of East Hanover, New Jersey, from about 1978). The second implementation, again partly in firmware: Pick's instruction set in microcode on Honeywell Level 6 hardware, later using a DEC LSI-11 for the monitor with a bit-slice co-processor executing Pick assembler. Versions ran on DEC VAX and on IBM 370-series machines. The company was renamed Allerion; most assets went to Groupe Bull, and the United States maintenance operation to Wang around 1994.
• Prime INFORMATION (from 1979). Written in FORTRAN and assembler by a Microdata reseller — named Devcom in most reference accounts and Dezcom in one contemporaneous trade report — to run under PRIMOS on Prime's 50-series minicomputers, then bought by Prime. Not an operating system but an environment hosted on one — the first of the guest implementations, and the model for everything that followed. Its BASIC was called INFO/BASIC. Prime rewrote it in C as PI+ and then PI/open for Unix.
• ADDS Mentor (Applied Digital Data Systems, 1981). The first implementation done purely in software, so that an upgrade arrived on tape rather than as a chip. Initially on the Zilog Z8000, it set off a wave of ports, many of them to the Motorola 68000.
• Revelation (Cosmos, Seattle, 1984). Pick's ideas on the IBM PC under DOS. By 1986 it was the single largest source of Pick licences — the family's widest distribution came, as so often, from its least prestigious member. Advanced Revelation followed, and the line continues as OpenInsight.
• General Automation Zebra, Sequoia, Altos, Wicat, Pyramid, Fujitsu Microsystems of America, the French IN2 and others: software implementations of the 1980s, most of them tied to a hardware line. Fujitsu Microsystems of America was acquired by Alpha Microsystems in October 1989; Sequoia's enterprise systems unit, which sold Pick, went to General Automation in 1996–97.
• UniVerse (VMark) and UniData (Unidata Corporation, Denver). The two Unix-hosted implementations that came to dominate the upper end. UniVerse was the first to emulate other flavours, which mattered enormously to customers with twenty years of application code: a UniVerse account could be created as generic Pick, or as Prime INFORMATION, Reality, IN2 or PI/open, or in VMark's own synthesis of them all, which it called IDEAL.
• jBASE (1991, Hemel Hempstead, written by former Microdata engineers). Notable for compiling applications to native machine code rather than to the interpreted intermediate form the other implementations used.
• UniVision (EDP, Sheffield, 1992) and OpenQM (Ladybridge Systems). OpenQM is the one member of the family to have been distributed both as a supported commercial product and in open-source form under the General Public Licence.
• D3 (Pick Systems). The Pick system rebuilt to run as a database product hosted on Unix, Linux or Windows, storing its data in the host's file system rather than in a private disk partition — the step that finally let a Pick application share a machine with the rest of the world's software.
• Caché for MultiValue (InterSystems, announced 2005). A relative latecomer, and the one arrival from outside: a different database engine growing a MultiValue personality rather than a MultiValue system growing anything.

Almost every entry in that list is a different answer to the same question — how do you sell a system whose ideas nobody owns? — and almost every one of them was represented in the 1993 vote roll.

Who owns them now

Verifying the current status of these products matters more than usual, because the received wisdom is that they are all dead and the received wisdom is wrong. Two long chains of acquisitions ran through the 2000s, and both ended in the same place.

The first chain is the one now sold as Rocket U2. Unidata Corporation and VMark merged in 1997 to form Ardent Software. Informix acquired Ardent in March 2000, which is how the two MultiValue products came to sit inside a relational vendor's catalogue. IBM acquired Informix's database division in April 2001, and the pair became the IBM U2 family. On 1 October 2009 it was announced that Rocket Software had bought the entire U2 portfolio from IBM, and they have been Rocket UniVerse and Rocket UniData since.

The second chain begins with Pick Systems itself. Its assets passed through PickAx to a company which completed that acquisition with effect from 1 December 2000 and simultaneously changed its name from Pick Systems to Raining Data; Raining Data renamed itself TigerLogic on 17 April 2008; and on 18 November 2013 Rocket Software announced its acquisition of TigerLogic's MultiValue database business — D3, mvBase and mvEnterprise. Separately, the cloud provider Zumasys acquired jBASE distribution rights and intellectual property in 2015 and became OpenQM's exclusive worldwide distributor, and on 14 October 2021 sold its databases and tools, including both, to Rocket.

The result is a concentration that would have astonished the 1993 electorate: UniVerse, UniData, D3, jBASE and OpenQM — five of the family's principal implementations, once sold by five competing companies — are now all products of one vendor, and still under development, with UniData and UniVerse releases dated into the 2020s. Outside that consolidation, Reality survives under NEC Software Solutions, and Revelation Software continues to publish OpenInsight, now in its version 10 line.

Between them these products still run payroll, distribution, healthcare, local government and manufacturing systems whose oldest code was written when the newsgroup did not yet exist.

The BASIC dialect

Programming a Pick system meant, in practice, writing in a dialect of BASIC that has almost nothing in common with the BASIC of home computers, and this is the part of the story that most surprises people who have not seen it.

The language began in the middle 1970s when Ken Simms implemented a version of Dartmouth BASIC for the Microdata Reality, with extensions for terminal handling and database access; it was called Data/BASIC, and reference accounts add the pleasing detail that Simms played a great deal of the text-mode Star Trek game while writing it, in order to satisfy himself that the language worked. Renamings followed the diaspora: Data/BASIC became Pick/BASIC, INFO/BASIC on Prime, UniVerse BASIC and UniBasic on the Unix hosts, FlashBasic on D3, and mvBasic as a generic modern name.

What distinguishes it is that the database is part of the language rather than a library called from it. Variables are typeless. Strings may be very long — up to 32,767 bytes in the mid-1980s implementations, and effectively unbounded later. A record is read into a single variable and written back from it, and while it is in the variable the programmer addresses its structure directly: a reference such as R<4,3,2> denotes the second subvalue of the third value of the fourth attribute of the record held in R, and it may appear on either side of an assignment. The three-dimensional string is not an abstraction over the storage format; it is the storage format, which is why the language and the database are so hard to separate and why porting a MultiValue application to any other language was, and remains, so unattractive.

The 1985 BYTE reviewer, no partisan, wrote that the language "bears little resemblance to the awkward Microsoft BASIC" and was "actually a fine little language", and listed the features it had and Microsoft BASIC did not: typeless variables, strings up to 32,767 bytes long, subroutines with arguments, built-in database functions, multiline structured control statements and no line numbers — a structured language wearing an unfashionable name. Programs compile to an intermediate form executed by an interpreter, an arrangement that gave the early systems their portability across wildly different hardware; jBASE broke with it by compiling to native code, and D3's FlashBasic likewise.

Around the BASIC sat the rest of the toolkit: PROC, a procedure language for collecting command lines into stored procedures, joined at various points by RPL from a Chicago software house; a line editor called ED, of which the same reviewer wrote that it was "the worst I have ever used"; a rudimentary text formatter called RUNOFF; screen-handling layers such as Microdata's ScreenPro; and TCL, the terminal control language, which was the command prompt from which everything else was invoked. The portability was real and is worth one concrete illustration: when the Dynix library system moved from Ultimate hardware to Unix machines running UniVerse, the application was not rewritten, because Pick/BASIC and UniVerse BASIC are the same language.

The English-like query languages

The other half of the working environment was a retrieval language that read, more or less, like a sentence. It was called ENGLISH on the original Microdata systems, ACCESS on Pick Systems' own products, RECALL on Ultimate, INFO/ACCESS on Prime INFORMATION, RetrieVe on UniVerse, UniQuery on UniData, AQL on the Advanced Pick line, and CMQL on InterSystems' implementation. Practitioners generally call the whole family the query language and mean any of them.

A query names a verb, a file and the fields to be shown, with selection and sorting expressed in ordinary-looking words: list this file, sorted by that field, with such-and-such a condition, showing these columns. What makes it work is the dictionary. The column headings, the formats, the conversions and the derivations all come from the dictionary entries, so a report specification carries almost no formatting instructions of its own; and because dictionary entries can be defined for anything, a query can ask for a field that is computed at read time or fetched from another file.

Two properties of these languages caused most of the discussion. The first is that a query runs against a single file. As the 1985 review put it, "you can operate on only one file at a time, so the system can't do a relational join"; the workaround, which the same review describes, was to build a list of item IDs with one query and feed it to another, which required that the files' keys had been chosen to make that possible. Dictionary entries doing calculated lookups into other files covered many of the remaining cases, which is why the absence of a join in the language mattered less in practice than it looks on paper. The second is multivaluedness: asking for a multivalued attribute normally produces one line per value under a single item's other columns, and where a practitioner wanted each value treated as though it were a record of its own there was an exploding modifier for the purpose, whose correct use depended on the dictionary having declared which fields are single-valued and which are not. Getting those declarations wrong produces a report that looks plausible and is not, which is why the discipline of dictionary maintenance mattered more on these systems than the word dictionary suggests.

One consequence of the dictionary-driven design deserves recording. The verbs, keywords, connecting particles, file pointers and sentences a user types are not built into a parser; they are records in the account's vocabulary file, of documented types, and users may create their own. A site is therefore free to alias the whole working vocabulary, and a 1987 trade article was able to describe Pick, without much exaggeration, as a multilingual operating system. The language was called ENGLISH, but only by default.

The query language was, originally, a retrieval language and not an update language; batch updating arrived later through a reformatting verb. Ad hoc changes to data were made from BASIC programs, partly because the line editor could not lock records — a detail that says a good deal about how the system expected to be used.

The applications nobody wrote about

The base description of this group calls Pick the platform of the world's unglamorous business systems, and the claim can be made concrete. Consider one documented example whose users never knew what they were using.

The Dynix Automated Library System was written in Pick/BASIC. First installed in 1983 at a public library in Kershaw County, South Carolina — which had contracted for the system before the software was written — it grew into what the reference literature calls the most popular library automation software ever released: more than 5,000 installations worldwide at its late-1990s peak, a market share of nearly 80 per cent, and users including the Library of Congress, the New York Public Library and the King County system outside Seattle. It ran first on Ultimate machines under Pick, then, from 1990, on IBM RS/6000 hardware under AIX with UniVerse acting as the Pick layer, then on Windows NT servers the same way. Its complete source approached 900,000 lines. Anyone who used a public library catalogue on a green-screen terminal in the 1990s was, quite possibly, using a MultiValue database, and neither they nor most of the librarians had any reason to know it.

The pattern repeats, and the trade press of the mid-1980s named names when it bothered to look. Reference accounts of Prime Computer attribute much of its 1980s success to United States banking, where its INFORMATION database was widely accepted; the company reckoned a quarter of all Prime systems shipped with the product in 1985. Ultimate, with 1985 sales of $107 million and an installed base of four thousand systems, said that thirty per cent of its users were Fortune 1000 companies, among them the Bank of New York, the CBS News division and Florida Power & Light. Elsewhere on the same list sat Marshall Field in Chicago, Gump's in San Francisco, the California State Almond Exchange, Arthur Andersen and Anheuser-Busch. Nineteen of the 198 votes to create this group were cast from addresses at ADP, which processes payroll for a large part of corporate America. The 1985 Los Angeles Times profile lists CBS News's archive and the inventory of the retail chain Contempo Casuals among Pick's showcase installations, and quotes Pick's own summary of what his system was for: "You wouldn't use us to design or keep track of the space shuttle. But our system is the best for keeping track of all the parts used to build it."

Underneath the named accounts was the ordinary customer, and the trade press described that customer precisely: a small or medium-sized company in a specific industry vertical, running eight to ten terminals off a supermicro, mini or supermini bought through a value-added reseller. More than half of Pick installations, the vendor's own vice-president of sales and marketing told a reporter in 1986, had no professional data-processing support on site at all.

That last point is the whole economic argument for the platform, and it explains both its longevity and its invisibility. A system that a company can run without employing anyone to run it generates no conference talks, no consultancy market, no certification industry and no journalism. It generates invoices, and it keeps working.

Why the industry kept forgetting

The structural explanation is unflattering to everyone and requires no special pleading.

Trade coverage follows change. A platform that runs a wholesale distributor's order book for twenty-five years without incident offers a journalist nothing to write: no migration, no crisis, no launch, no rivalry. Its practitioners are correspondingly invisible — they are employees of the distributor, not of a software company, they attend one specialist conference a year if their employer pays, and their professional reputation is entirely local. Meanwhile the same trade press has an unlimited appetite for whatever is being launched, and vendors with marketing budgets supply it. None of this requires a conspiracy or even a preference; it is what a press covering an industry by covering its announcements will produce.

The Pick world also had specific, documented handicaps. Its licensing was expensive and idiosyncratic in the years when Unix was being seeded at nominal cost into universities, so a generation of graduates learned Unix and had never heard of Pick. Its licensees were, in the words of an analyst quoted in 1985, second-tier manufacturers rather than a DEC or a Wang. Its founder was a gifted engineer with an indifferent commercial instinct and a taste for publicity of the wrong kind: he had appeared on the cover of a trade paper in 1983 hanging upside down in anti-gravity boots, and the profile that recorded his attempt to shed the mad-scientist image treated the wearing of a tie as news.

The vendors' own answer to the fragmentation was the Spectrum Manufacturers Association, a body of Pick and Pick-compatible hardware vendors that set out to write a common Spectrum Standard so that a customer could move between one member's hardware and another's. Its board president, Len Mackenzie — also president of the Pick vendor General Automation — told a reporter in March 1986 that the association's first goal was to "expose and promote the value of Pick and Pick-like systems", growth in the Pick market having recently slowed. By then it counted seventeen of the twenty-six vendors that sold hardware running a Pick or Pick-like operating system, among them Applied Digital Data Systems, Cosmos, General Automation, Nixdorf, Pertec, Intertechnique and McDonnell Douglas Computer Systems. The standard was to appear in levels, Level 1 first; the comparison the association's own president drew was with AT&T's System V Interface Definition, with the difference that the Spectrum Standard would come from a consensus of its members rather than from one vendor handing down a specification.

And the technical press, when it did look, was not hostile. The BYTE review of Pick release 1.3 on the IBM PC XT in the autumn of 1985 concluded: "Many of the Pick operating system's less important features are badly designed, but its important features are very well designed, particularly its file structures and the PICK/BASIC language. Pick is simple and powerful, and it seems to be efficient and reliable, too. It does exactly what it was designed to do." It added that, because Pick worked well as a multiuser system, it was "probably the most cost-effective way to use an XT". That verdict was published, and then the industry went and standardised on something else anyway, for reasons that had more to do with distribution and mindshare than with file structures.

The newsgroup was a direct response to one specific form of that invisibility. Before 1993 the RFD's fragmentation problem meant that no MultiValue practitioner could find the others: the Revelation users were in one group, the Prime people in another, the Stratus people in a third, and, in the proposer's words, "many more folk don't post at all, because there isn't any defined group dedicated to their questions". The point of the group was to give a scattered profession a single address.

What the traffic then looked like is what comp.* traffic generally looked like — the hierarchy page for this directory describes those genres, and this group ran to type. For a MultiValue platform those genres meant file sizing, source management, select lists, getting a report out of a D3 database through somebody else's reporting tool, and producing a PDF from Pick.

The migration question and the ODBC bridge

The perennial argument in the group was not really Pick against relational as an abstract question. It was a specific, recurring, practical one faced by every site: you have a working MultiValue application of two or three decades' standing, and the rest of your organisation runs on SQL. What do you do? Three positions were argued, and this page reports them without adjudicating.

Migrate. Move the data to a relational database and rewrite the application. The technical work is well understood: every multivalued attribute becomes a child table, every subvalued attribute a grandchild, and every place the code walked a dynamic array becomes a join or a cursor. The arguments made for it were about supply rather than elegance — that staff who know SQL are easy to hire and staff who know Pick/BASIC are not, that reporting and integration tools all speak SQL, and that a platform whose vendor has changed hands four times is a risk on a board's register. The arguments made against it were about cost and risk: the rewrite is total, because the data model and the language are the same thing, and thirty years of accumulated business rules live in the code being discarded.

Bridge. Leave the application where it is and expose the data through ODBC or JDBC drivers, so that spreadsheets, report writers and business-intelligence tools can read it as though it were relational. The major implementations acquired such drivers, along with SQL layers over the native files. The difficulty is exactly first normal form: a multivalued attribute has to be presented to the SQL client either flattened into one column or exploded into several rows, and which is correct depends on the meaning of the data, which lives in the dictionary. Associations between related multivalued attributes have to be declared correctly for the exploded view to be right; where they are not, the bridge delivers a view that is subtly, plausibly wrong, and delivers it to precisely the audience least equipped to notice.

Stay and modernise. Keep the database and the BASIC and put something modern in front: terminal emulation with a graphical skin, then web front ends, then web services and JSON. The vendors invested heavily in exactly this, and the current products offer client interfaces for .NET, Java, Python and the web alongside the green screen. The argument for it is that the expensive asset is the application logic, not the user interface. The argument against it is that each layer adds a place where MultiValue expertise is needed, and that expertise is what the organisation was worried about in the first place.

There was also a strand of opinion, well represented among practitioners, that the SQL bridges were a convenience for outsiders rather than an improvement for insiders. The UniVerse training course already quoted — a period document written by a working Pick engineer, not an official one — devotes a page to SQL only in order to explain why it will not be teaching it. It grants that UniVerse's SQL support is impressive, "because SQL was not designed to deal with typeless, 'post-relational' ... databases like PICK", and worthwhile for anything that smooths a conversion; then it declines to recommend the language for new enquiries and reports, on the grounds that the support "does not fill any functional gap, but rather adds a handy piece of support when porting systems", and that a reader who wants SQL "really are better off using a product like Oracle, which was designed to work with it". That is one practitioner's view, stated here as evidence of what the argument sounded like from inside, not as a conclusion.

What became of the community

The group was never removed, and it is still there. It appears in the current active file flagged y for unmoderated and in the current newsgroups file with its 1993 description; a reader with an NNTP client can still open it. That survival was not entirely automatic. On 3 November 2001 an rmgroup control message for comp.databases.pick appeared on the network, carrying the address of the maintainer of the tin newsreader and asking that the "bogus newsgroup" be removed. Whatever its provenance, it had no standing: the news servers that carry these hierarchies are configured so that unsigned newgroup and rmgroup messages for comp.* are dropped, and only messages cryptographically verified against the news.announce.newgroups key are acted on. The group outlived the message without visible incident, which is roughly how the whole system was designed to work.

The traffic, though, went where all Usenet traffic went. The MultiValue community's discussion moved to vendor-hosted forums and mailing lists, to user groups, and to a Google Group titled Pick and MultiValue Databases, which is open to all the platforms at once and carries the same kind of question the newsgroup carried. Independent institutions survive too: International Spectrum, which publishes a MultiValue trade magazine and runs a conference of Pick users, was already convening that conference in Las Vegas in March 1986, and the vendors' own standards body of the same period, the Spectrum Manufacturers Association, is the reason the community had a shared logo to put on a stand.

What has not survived is the thing the newsgroup uniquely provided: a single, vendor-neutral, publicly archived room where a UniVerse site, a D3 site and a Reality site could argue in front of each other. The successor venues are either owned by a vendor or organised around a product, with the Google Group the nearest thing to an exception. That is not a complaint about the vendors, whose forums are useful; it is an observation about what a neutral namespace was worth, and what it costs to lose one.

What the record does not show

The honest limits of this page are worth stating, because the temptation with a group of this kind is to fill the gaps with plausible colour.

• No readership figures. Nothing in the surviving record establishes how many people read comp.databases.pick. The 215 people who voted in 1993 are the only enumerated population, and voters are not readers.
• No FAQ. The archives consulted for this page turned up no periodically posted FAQ for the group in the usual collections. The RFD does contain a dangling cross-reference to a numbered question that appears nowhere in the document, which suggests its author had drafted a longer version, but a dangling reference is not a FAQ.
• No moderator, and no moderation record. The group was unmoderated by charter, so there is no editorial archive of the kind that some moderated groups left behind.
• Partial archives. Web archives of the group's articles vary in coverage and none of them is complete; the counts quoted above are counts of what one archive holds from mid-2003 onward, not of what the group carried across its life.
• Contested dates. The acquisition of Microdata by McDonnell Douglas is given as 1981, as March 1983 and as 1985 by three different reference works. The transfer of the D3 line from TigerLogic to Rocket is dated to the announcement of 18 November 2013 in one source and to 2014 in another. The birth of the Pick system itself is dated to 1965 by reference works, to March 1965 by a trade legend of the 1980s, and to 1 January 1967 by every Pick system's own internal clock. Where sources disagree this page says so rather than choosing.
• An unattributed block of votes. Fifteen affirmative votes came from one domain that this page could not identify with confidence, and it is left unidentified rather than guessed at.
• Unverifiable market claims. The RFD's "hundreds of thousands of systems, with millions of individual users" is a proposer's estimate in a document written to persuade. The only contemporaneous count this page found is a vendor's own figure of sixty thousand licensed CPUs at the end of 1985, which is a vendor's figure. No independent census of the MultiValue installed base exists for any year.

Scope and limits of this page

This page is about a newsgroup and the world it belonged to. The mechanics of group creation in the mainstream hierarchies are set out on the soc.* page, which carries this directory's account of RFDs, votetakers and control messages; the shape and history of the computing hierarchy are on the comp.* page linked at the head of this article. Neither is retold here.

For a companion case of long-lived, commercially serious software that the trade press almost never covered — a different corner of the same phenomenon, on the real-time side rather than the business-data side — see comp.os.psos. For another instance of the stratum this directory happens to preserve, the group for 4DOS is a smaller variation on the same theme: a tool kept in service for years by the people who used it every day.

Technical details above are drawn from documentation and contemporaneous reviews of specific implementations, chiefly UniVerse and the Pick Operating System as sold in the mid-1980s; other members of the family differ in detail, sometimes considerably, and the group existed in large part so that those differences could be compared by people who had to live with them. Where a term has several names across implementations, the alternatives are given; where the community's own vocabulary differs from relational usage, the community's vocabulary is used, because that is what the archive is written in.