The Dynix Automated Library System was a popular integrated library system, with a heyday from the mid-1980s to the late-1990s. It was used by libraries to replace the paper-based card catalog, and track lending of materials from the library to patrons.[1]
First developed in 1983, it eventually became the most popular library automation software ever released, and was once near-ubiquitous in libraries boasting an electronic card catalog, peaking at over 5,000 installations worldwide in the late 1990s, with a market share of nearly 80%,[2] including the United States' Library of Congress.
Typical of 1980s software technology, Dynix had a character-based user interface, involving no graphics except ASCII art/ANSI art boxes.
The first installation, in 1983, was at a public library in Kershaw County, South Carolina. The library actually contracted for the system before the software was written. In the words of Paul Sybrowsky, founder of Dynix: "There was no software, no product. Undaunted, we pitched our plan to create an automated library system to a public library in South Carolina. We didn't have a product, but we said 'You need a system and we'd like to bid on it,' and showed them our business plan."[3]
The original Dynix library system was based on software developed at CTI (Computer Translation Incorporated) which was a development project of Brigham Young University, and presided over by Gary Carlson. The initial search engine tools: FSELECT and FSORT were written for the PICK operating system under contract for CTI by Walter Nicholes as part of a bid for a research support systems for AT&T laboratories. Paul Sybrowsky was an employee of CTI. (As was Bruce Park, founder of ALII library systems, later GEAC Library Systems.) Both library systems (Dynix and ALII) were based on these PICK based search engine tools.
In 1984, Eyring Research Institute acquired 80 percent of Dynix.[4] Then in 1986, the executives and employees bought out Eyring Research's share and became independent again.[5] In 1987, a New Jersey firm called the Ultimate Corporation purchased a minority share of Dynix.[4]
Dynix use grew quickly in the early-and-mid 1990s. In October 1989, Dynix had just 292 installations.[6] Fifteen months later, in January 1991, it was up 71% to 500 installations.[7] A year-and-a-half later, in June 1993, Dynix had doubled its installed base, signing its 1,000th contract.[8] At its peak in the late 1990s, Dynix had over 5,000 libraries using its system, amounting to an 80% market share.
The company selling the Dynix software changed hands several more times.[9] [10] When mostly independent it was called Dynix Systems, Inc. In January 1992, Dynix Systems was acquired by Ameritech.[11] Dynix and NOTIS Systems (maker of NOTIS), which Ameritech purchased in October 1991, were consolidated into Ameritech Library Services (ALS) in 1994. In November 1999, Ameritech sold Ameritech Library Systems to a pair of investment companies, the 21st Century Group and Green Leaf Ridge Company, which rebranded ALS as epixtech.[12] In 2003, epixtech reverted to using the Dynix name.[13]
The customer base for Dynix did not begin decreasing until 2000,[14] at which point it started being replaced by Internet-based interfaces (so-called "Web PACs"). In 2003, it was reported that Dynix was being phased out by its manufacturer, and approaching "end-of-life" status in terms of functionality and support.[15] By 2004, its market share was down to 62%, still a comfortable majority.
In June 2005, SirsiDynix was formed by the merger of the Dynix Corporation and the Sirsi Corporation.
Phase-outs of Dynix were constant in the late 2000s, and by the second decade of the 21st century, it was obsolete and remained in very few libraries. By mid-2013, only 88 libraries were on record as having Dynix installed.[16] The majority of phase-outs took place between 2002 and 2007.
At one point, Dynix was benchmarked supporting 1,600 terminals on a single system.[17] This stability would later come in handy; the largest installations ever were the King County Library System in the greater Seattle area, which was largest by collection size (tens of millions of cataloged items), and New York Public Library in New York City, which covered the largest geographical area with 87 branches (requiring dumb terminals numbering into the thousands).
Several specialized versions were released, all nearly identical to the mainstream version. For academic libraries, primarily K-12, there was Dynix Scholar (an Intel 80xxx-based microcomputer version of regular Dynix). For very small libraries, with perhaps only one or two terminals, there was Dynix Elite. The original Dynix system, as used in regular public libraries, was renamed Dynix Classic later in its lifespan to distinguish it from other Dynix products.[18]
Based around a relational database, Dynix was originally written in Pick/BASIC and run on the PICK operating system. In 1990, it was ported to VMark's uniVerse BASIC programming language, and run on Unix-based servers, with uniVerse acting as a PICK emulation layer between the software and the operating system. In the late 1990s, Dynix was once again re-ported, this time for Windows NT-based servers; again, uniVerse acted as a Pick emulator between the software and the operating system.
Pick/BASIC and uniVerse BASIC are the same programming language, so porting Dynix did not require re-writing the source code. In the words of one Dynix developer, "[Dynix] was programmed in Pick/BASIC ... however, as it matured, it was written in uniVerse BASIC ... It was never re-written. That type of BASIC isn't easy to move to any other language. None other handles data as well. It's a very fast-compiled and -interpreted language, and frankly nothing matches it, then or now. It's too bad that it (uniVerse BASIC) was so good, because it didn't make the transition to object-oriented Web-based technology in time to stay afloat."
The software was originally written on computers made by The Ultimate Corp. of East Hanover, New Jersey, which ran Ultimate's proprietary implementation of the PICK operating system. Later, Dynix moved to IBM RISC/6000-based computers running AIX throughout the company, except in Training, which used SCO Unix. While most libraries purchased the same type of servers as Dynix was using, there were installations done on platforms such as DEC and MIPS, Sequent, Sequoia (which used a very expensive native PICK), HP's Unix servers, etc. The Dynix corp. could do software-only installs to any compliant Unix because of uniVerse's scalability and adaptability.
Dynix was originally developed around the ADDS Viewpoint A2 terminal's escape sequences, because ADDS terminals were the de facto standard on the PICK-based mainframes on which Dynix was created. Shortly after Dynix started being deployed to libraries around the country, requests started coming back that alternate terminals be provided for patron use; children would bang on the keyboards or throw books at the terminals, or use unauthorized key sequences to mess up the programming. In response, Dynix asked Wyse to develop such a terminal; Wyse created the WY-30, which was a stripped-down version of the best-selling terminal ever made, the WY-60. The swivel base was removed so that the terminal sat flat on whatever surface it was placed on; what the unit now lacked in viewing-angle adjustability, it made up for in physical stability (it could not be knocked over by the force of a child). A specially-designed keyboard reduced the number of keys from 101 to 83, mainly by removing all the function keys; this was designed to keep users out of the internal setup functions and other parts of the software they "weren't supposed to be going". To maintain compatibility with how Dynix was already written, the WY-30 supported the Adds Viewpoint A2 emulation, which was actually one of the only emulations on the terminal. They WY-30 had very few emulations compared to most Wyse products, and notably did not support VT100 or any other ANSI emulations. Years later, when the Dynix company was moving from Ultimate computers running Pick/OS to IBM computers running AIX and uniVerse, compatibility for VT100/102/340 terminals was added to the software; then, other models of Wyse terminal started coming into favor, such as the WY-60 and WY-150, which were easier on the eyes and hands than the WY-30 was.
The complete Dynix Classic approached 900,000 lines of source code, and compiled at around 120 MB. It was distributed via tape drive, first on 1/2" reel-to-reel tape, then later 1/4" cartridge tapes for Dynix Elite users, and 8mm cartridges for everyone else.
One reason for Dynix's success was that an entire library consortium could be run off of just one server, in one location, with one copy of the software. This meant that a library system with multiple branches—whether a large single-city system such as the one in New York City, or whether a consortium made of several small cities/towns banded together—could pool their funds and only have to purchase one server and one copy of the software. Each branch had their own Circulation module, but the actual catalog database was a single copy on one server in a central location. Each record had a line in it stating which actual branch the item belonged to, allowing users to request holds/transfers from another branch to their branch, as well as see whether it was checked in or out at its home branch. This saved a significant sum of money—millions of dollars, in the case of the largest installations—versus Dynix's competitors, who required a separate server and copy of the software in each library branch.
With the single copy of the Dynix software installed on a central server, both patrons and librarians could access it by using dumb terminals. The technology for linking the terminals to the server within each building, and linking the separate buildings (branches) together to the central server location, changed over time as technology progressed. The earliest method was to have the entire system connected via RS-232; there would be many muxes (statistical multiplexers) and many miles of serial lines. Muxes were the phone company's solution for connecting serial lines between branches. Later, dumb terminals were connected via RS-232 to a terminal server, which in turn connected via Ethernet to the branch's LAN. The separate branches would be connected to the central Dynix server via IP-based methods (the Internet). The latest installations used PC's running terminal emulation software, and connecting to the Dynix server via telnet over the Internet.
Dynix was made up of several different modules, each of which was purchased independently to create a scaled system based on the library's size and needs. A library could buy as few as two modules. The two basic modules were Cataloging ($15,000 + $1,500 annual maintenance), and Circulation ($12,000 + $1,200 annual maintenance). Some of the other modules included Kids' Catalog, Bookmobile, Homebound, Media Scheduling, Reserve Bookroom, TeleCirc, DebtCollect, Electronic Notification System, and Self Check-Out. A Dialcat/DialPac module was offered, allowing patrons with a modem and terminal emulation software to dial in from home and search the card catalog or renew books.
Programs with a text-based interface, such as Dynix, are described as being either "menu-driven" or "command-line-driven", referring to how users interact with the software. Dynix was actually a hybrid of both; the patrons used a menu-driven interface, where they would be given a numbered list of options, and simply have to key in the number of the option they wanted in order to navigate through the system. Unknown to the patrons, the librarians had the ability to manipulate the system in the command-line-driven way, by keying in special codes at the same prompts where patrons would key in menu item numbers. These codes, referred to a "dot commands" due to their structure of being a period followed by one or two letters (such as '.c' to switch between checkout and checkin screens in to the Circulation module), allowed librarians access to advanced/hidden features of the Dynix system, and—along with password-protection—prevented patrons from gaining unauthorized levels of access.[19] [20]