lib-s-mocs-kmc364-20140601053153 184 ]oumal of Library Automation Vol. 5/3 September, 1972 TWO TYPES OF DESIGNS FOR ON-LINE CIRCULATION SYSTEMS Rob McGEE: Systems Development Office, University of Chicago Libra,ry On-line circulation systems divide into two types. One type contains records only for charged or otherwise absent items. The other contains a file of records for all titles or volumes in the library collection, regardless of their circulation status. This paper traces differences between the two types, examining different kinds of files and terminals, transaction evidence, the quality of bibliographic data, querying, and the possibility of functions outside circulation. Aspects of both operational and potential systems are considered. INTRODUCTION A literature survey was made of on-line circulation systems ( 1 ). To qualify for study, a system needed to perform any major circulation function on-line. Charging and querying were common. Some systems were also found to perform some acquisitions, cataloging, and reference work. Criteria used to examine systems have been presented in an earlier paper as key factors of circulation system analysis and design (2). This paper concep- tualizes the survey findings, and goes on to consider general problems and alternatives of designing on-line circulation systems. The survey shows that on-line circulation systems divide into two types, according to the scope of their bibliographic records. We give the term "absence file" to a set of records for only those items that have been charged or otherwise removed from their assigned locations. The name "item file" is given to what is, or approaches being, a comprehensive file of records for all titles or volumes in the library collection, regardless of their circulation status. Each on-line circulation system either does or does not have an item file. Systems without an item file must contain an absence file, and are Two Types of Designs/McGEE 185 therefore called "absence systems." Systems with an item file are called "item systems." (An item system may also have an absence file, depending upon its design.) Note that an "absence file" and an "item file" are each conceptually or logically defined as a single file, whereas in some opera- tional systems either may be stored as more than one physical file. Two other basic files generally appear in operational systems: a user file of complete records for users; and a transaction file that may be variously used for data collection, system update, system backup, and batch genera- tion of notices. We can now generalize common but not exclusive file definitions for the two design types. Absence systems usually contain three main logical files: 1) a user file; 2) an absence file that contains records only for charged or otherwise absent items; and 3) a transaction file. User identification number and complete item data (all the item data the system is to hold) are input at transaction time to create charge records. These data are typically collected from machine-readable sources such as punched cards or magnetic strips; the surveyed systems use punched cards. Time data, such as charge date or due date, and circumstantial data, such as charging location, may also be collected. During batch processing, user records are accessed by identifica- tion number to obtain name, address, and so forth. Examples of absence systems are found at West Sussex County Library (3,4,5 ), Illinois State Library ( 6,7 ), Midwestern University library ( 8,9,10), Queen's University library ( 11,12,13,14,15), Northwestern University library ( 16), and Buck- nell University library ( 17). Item systems are characterized by three or four major files: 1) a user file; 2) an item file of bibliographic records for all library volumes or titles, or for as many as machine records can feasibly be created and stored; 3) a transaction file that may be used for update of the item file, data collection and analysis, and perhaps notice generation; and optionally 4) an absence file of records for circulating items, if transaction data for them are more efficiently kept here than in the item file. Records in both the user and item files contain either full data or at least enough data to address messages to users and to adequately describe items. If an absence file is used in an item system, it may copy bibliographic data from the item file, or the two files may be linked to avoid data redundancy. Item systems are in operation at Bell Laboratories library ( 18,19 ), Eastern Illinois University library ( 20), Ohio State University libraries ( 21,22 ), and the Technical Library of the Manned Spacecraft Center, Houston ( 23). (The Manned Spacecraft Center library, alone among the systems we have surveyed, does not have a user file. Instead, user's last name, initials, and address code are input at charge time.) Since the basic distinction between absence and item systems is whether descriptive data for an item are machine-held prior to its charge time, item file records are limited primarily by the costs of conversion and machine storag~, but can have full, even MARC-like formats; whereas absence sys- 186 Journal of Library Automation Vol. 5/3 September, 1972 tern records are restricted by the quantity of data that can be input at charge time, i.e. by the capacities of source record coding and data transfer techniques. BASIC APPROACHES TO ON-LINE CIRCULATION SYSTEM DEVELOPMENT Three approaches to the design of on-line circulation systems have origin- ated from different notions of circulation control ( 24). First is the view that circulation control is a separate library function, or one with minimal rela- tionships to other library data processing. Exclusive requirements for user and item data are formulated; the format of bibliographic data and the design of data management capabilities are developed explicitly for circula- tion control, to the exclusion of other library data processing requirements. Absence systems have been developed with this approach, but thus far item systems have not. The second approach is to create a circulation system that is opera- tionally independent of other library data processing activities, but designed with a view toward the possibility of shared usage of bibliographic and other data, and of general library data processing facilities. Compatibility with other functions is provided, to aid later combination. Either system design can take this approach, but item systems can take better advantage of the integration of functions. A third approach is to add circulation control to other large file processes (such as a cataloging system), or to develop them concurrently. This follows an integrated view of library data processing that sees a circulation system operating with many of the same data and processing requirements as other library functions, all of which are handled by a general library data management system. The broad range of library data processing activities needs to be addressed, and an item system design is likely to be preferred. Two concepts underlie these approaches: 1 ) an integrated library system, and 2) a remotely accessible library catalog. An integrated view of the library is one of a total operating unit with a variety of operations that are logically interrelated and interconnected by their mutual requirements for data and processing ( 25) . The term "integrated system" usually implies a system in which centralized, minimally-redundant files undergo shared processing by different library functions. It is not clear exactly how the concept of a remotely accessible catalog should be defined, or exactly what the phrase means to various users. If we take it to mean the capability to access information from a given catalog at remote locations, then a variety of systems may qualify: e.g., telephone access to a group that performs manual card catalog lookups ; multiple locations of book catalogs or microform catalogs; and terminal access to an on-line, computerized catalog. The last is pertinent to our discussion. Two Types of Designs/McGEE 187 How an integrated system is implemented determines if its central biblio- graphic file is accessible from multiple remote locations; how an on-line, remotely accessible catalog is used determines if the system is integrated. Recently the Ohio State University libraries circulation system has come to be explicitly called a remote catalog access system. We have not yet found reports of any on-line system that has integrated all of technical services and circulation. The addition of circulation control to existing on-line cataloging systems has been planned for the Shawnee Mission system ( 26) and mentioned for the system at Western Kentucky University, Bowling Green ( 27). The Ohio College Library Center has not yet decided how it will handle circulation. As long as we define an integrated system on the basis of multiple uses of nonredundant data (among other characteristics), and a remote catalog access system upon physical accessibility, various systems may qualify as either or both. Recognizing these two concepts helps to show how the three approaches to on-line circulation system development capsulize broader trends in library systems. First, the redundancy of bibliographic data in operationally separate but conceptually related functions has characterized traditional manual systems, batch computer systems, and now some on-line systems. Second, the construction of individual, independent subsystems, while planning for their eventual combination, has been called an evolu- tionary approach to a total system, by De Gennaro ( 25). He has also defined a third, integrated approach, in which computerized systems are designed to take advantage of interrelationships among different subsystems, for example, by accepting one-time inputs of given data, and processing them for multiple library functions and outputs. These three trends have been widely experienced in changing relationships among traditional and innova- tive systems for acquisitions and cataloging. The pattern is repeating now in the evolution of on-line systems with respect to technical services processing and circulation control. Large on-line systems are emerging to perform acquisitions, cataloging, circulation control, and reference functions with shared processing facilities and data bases. TERMINAL DEVICES Most on-line circulation systems do not perform all functions on-line, although the following are possibilities: charge, discharge, inquiry, and other record creations and updates, such as reserving items in circulation, renewing loans, recording fines payments, and even converting files to machine-readable form. What do their input/output requirements imply for terminal devices? Inputs for charges may be minimal user and item identification numbers, or full borrower and book descriptions. Evidence of valid charges may be produced; printouts of user number, call number, short author and title, and due date are common. There are also special "security systems" that switch two-state devices in books (such as sensitized plates ~r labels) to record valid charge, but as yet no such system has been 188 Journal of Library Automation Vol. 5/3 September, 1972 coupled with on-line charging. Discharge inputs need only to match existing records; simple access keys such as call number or accession number are adequate. Querying, too, may be accomplished with simple search keys, or with bibliographic inputs such as author and title . All these functions can be performed with keyboard input and output display of alphanumeric data. Absence Systems Although not a requirement by our definition, most absence systems feature machine-readable user and item cards (the Queen's University system does not); the terminals used for charge and discharge must have card reading capabilities. Thus for on-line tasks charge stations need card readers and the ability to produce charge evidence, usually in hard copy; querying by bibliographic search keys requires keyboard input and output display of alphanumeric data; discharge stations need a card-reading capability and a display mechanism to identify reserved items; and file creation requires inputs of alphanumeric data in a character set that may range from minimum to full. There are at least two problems in choosing terminal equipment for absence systems. Fi1·st, any single terminal or configuration that satisfies input and output requirements for all basic functions may be too expensive to install at every library location of these activities. Second, the combina- tion of separate hardware units (such as keyboards, printers, and card readers) may require special hardware or software interfaces that prove difficult and expensive ( 16, 28). Alternatively, separate circulation stations with different terminal devices can be established for specific functions. This solution may introduce problems of hardware and personnel redun- dancy and backup. Difficulties with terminal devices explain in part why most systems perform not all but only selected functions on-line. Item Systems It is possible, in systems with user and item files, to access records by using search keys that are either keystroked or machine-read from cards. The use of machine-readable cards involves the same problems as those described for absence systems. However, choosing keyboard entry of acces- sion or call numbers eliminates card reading, and simplifies requirements so that keyboard devices with display capabilities can perform all basic func- tions. The feasibility of keyboarding the inputs at transaction time has been demonstrated by the systems at Queen's University library (an absence system without machine- readable cards), Ohio State University libraries, Bell Laboratories, and the Technical Library of the Manned Spacecr:1ft Center. A system based on a single terminal device that handles all real- time functions offers attractive simplifications for hardware and tele- processing software. The primary disadvantages also center on the device itself. Factors such as input error, transmission and printing rates, char- acter set, special function keys, noise, and cost have various implications Two Types of Designs/McGEE 189 for system design and operations. Obviously, in a system based on a single terminal device, the characteristics of that device are influential. Kilgour has stated that the two most important factors in configuring a computer system for an item file design are, first, the nature of secondary memory, and second, the kind of terminal device to be employed ( 29). The need to quickly access large stores of data is basic. As for keyboard devices, one often finds that typewriter terminals may require far more computation of a central computer than do cathode ray tube terminals, because many CRT systems have substantial computing power of their own, giving the effect of a satellite computer. This can be important for systems that will run on time-shared machines, or transmit data over long distances. The problems we have described for circulation terminals can be over- come; appropriate devices can be built. Too many library systems have been designed around unsuitable hardware; there has been little choice but to develop circulation systems (both on-line and batch) with data collection devices designed for industrial applications. Their influence-frequently bad-is fundamental to the nature of resulting systems. In fairness, suppliers need both direction and marketing potential. The deeper fault is with librarians, who have inadequately documented requirements and not proven the existence of a market. The integrated approach to library automation ultimately visualizes all library functions using a single set each of bibliographic, user, and other kinds of records, although different pieces of data for different purposes. Similarly, one can say that different sets of terminal requirements arise from the different input/ output specifications among library tasks and not so much from the nature of bibliographic and other data. As functional require- ments of different activities (e.g., acquisitions, cataloging, and circulation) overlap, the opportunity to use identical or similar terminals in a variety of library processes is enhanced. Extending the integrated approach to library- related hardware fits well with the concepts of modular hardware design and add-on features. Take, for example, a basic keyboard/display screen terminal to which modules can be added to read book and borrower identi- fication and to produce hardcopy printout. TRANSACTION EVIDENCE A variety of transactions may occur between a library and its users: charging and discharging books, placing reserves on circulating material, paying fines, etc. Evidence may be provided to verify transaction accuracy and to furnish receipts for users. This evidence can be in various formats: it might be a hardcopy record (or worksheet) of transaction inputs, or a printout or screen display of system responses. Printed charge evidence is a familiar example, and is sometimes used for inspection of items that library users carry from the building. Two kinds of charge evidence may be defined ( 2). Simple evidence contains no more user and item data than are input at transaction time. Complex evidence contains user or item data other 190 ]oumal of Library Automation Vol. 5/3 September, 1972 than charge time input, and requires the system to extract data from machine-held file( s). Printed evidence typically contains an item due date that may be calculated from either user or item criteria, or both; or directly specified at the time of charge. Let us look at the implications of printed charge evidence for the two system types. Absence Systems In most absence systems user identification number and full item data are transferred into the system from machine-readable cards at charge time. There are various ways of printing simple transaction evidence; the follow- ing are illustrative. One technique is to transmit data directly to a com- puter that formats them for output, calculates a due date, and returns them to a printing device. Another method is to process source record data with a terminal system that can buffer and format them, select a Juc date, and output the evidence on a printer. Shifting functions from the computer to a terminal system may simplify teleprocessing software, save time at the central processing unit, and permit nearly normal charge operations during computer downtime. If more elaborate user data than identification number are required, there are two obvious solutions. Central user records may he accessed to provide complex evidence, possibly increasing central processing unit time and response time. Or, user cards (such as magnetically encoded ones ) that contain fuller data could be employed with a terminal system that handles them independently of the central computer. Item Systems In item systems as in absence systems it is possible to use machine- readable cards, with the same implications for printing charge evidence. However, if 1) user and item numbers are keystroked, 2) these are con- sidered sufficient borrower and book information, and 3) decision rules for loan periods are simple, then little or no computer response is required for charging. Due date may be returned and printed to signal completed transaction, or predated date due slips may be used. Alternatively, special terminal features may be added to select and print a due date. This compli- cates otherwise simple terminal requirements. Sophistications such as status checks on the borrower (e.g., Any outstanding fines?) and item (e.g., Is it reserved for another user?) will of course require more extensive processing and responses. If charge time inputs are indeed keystroked, user and item numbers with check digits are desirable, to minimize the effects of input error. For complex evidence response time is important, expecially if terminals are typewriter-like devices. The time required is determined by the sources of response data, their access times, how much data must be transmitted, and the transmission and terminal display rates. Through careful design the time required to obtain charge evidence and complete the transaction can Two Types of Designsj.McGEE 191 be minimized. For example, if the user number carries a code for borrower class, then a due date can be quickly selected and printed, while the item file is accessed for needed author /title data. It is clear that in an item system containing a user file, only very simple inputs are required to record a charge transaction. The additional require- ments for charge evidence, status checks on - user and item, and so forth determine how elaborate and slow system responses may become. AVAILABILITY, HOLDINGS, AND ABSENCE INFORMATION One may take the view that a library should provide the following kinds of responses to users. If a title is requested, library holdings for it should be given. If a specific item is wanted, either its absence or presumed location should be reported. If the item cannot be immediately provided, the library should determine its future availability and inform the user. The terms "availability," "holdings," and "absence information" have special meanings. The availability of a specific item to a library's users is mapped onto the universe of items by the library's acquisitions, cataloging, circulation control, and interlibrary borrowing functions. Availability information obtains from all these sources, but particularly from the public catalog of library holdings. Absence information, in contrast, corresponds only to a subset of library holdings-it tells the locations of library-owned items when they are absent from the locations indicated by the catalog. Absence information therefore corresponds to a subset of holdings information; holdings information is a subset of availability information. In the context of our discussion an absence system provides full absence information and only partial holdings and availability information. An item system can provide full holdings and absence information, but only partial availability information, since items not owned may be ordered, or borrowed from another library. Such con- siderations strengthen the argument that circulation control shares a func- tional unity with other library processes, and should therefore be considered as one of several integrated functions. The provision of absence and availability information is the essence of circulation system querying requirements. Figure 1 shows that different query keys access different subsets of availability information. Note the wider utility of some keys than for just circulation control. Absence Systems In on-line circulation systems built around an absence file, the data representing each physical item may range from a simple accession or item call number (as in the Queen's University and Northwestern University systems) to larger records containing as much data as may be stored and transferred with a machine-readable card (for example, a Hollerith-punched book card). If availability information is to be obtained from a library's public catalog, and not from the circulation system, then access to the file of absence information may be with any key shown in the catalog records: 192 Journal of Library Automation Vol. 5/3 September, 1972 e.g., author and title, title and author, ca11 number, accession number. Only the simpler keys, item call number and accession number, have been used in absence systems developed so far. Consequently their requirements for file organization and access software are minimal. In most systems these keys permit exact matches to only single records, but in the Northwestern University system a call number query may cause display of a set of related records ( 16). Item Systems The query function in item systems is bound by different constraints than those constraints of absence systems. The amount of bibliographic data is not restricted by the storage capacities of machine-readable cards, trans- action response time, or the transfer rates of charge-time inputs. However, the following questions arise: How many and which records from the li- brary's data base (e.g., its shelflist) must be converted to provide a sufficient item file? For each record converted, how much and which data are re- quired? What functions shall such a data base ultimately support? What kinds of absence and availability information will be provided? These deserve special discussion before we consider querying in item systems. ITEM SYSTEM BIBLIOGRAPHIC DATA How much data are required for item file records? In an integrated system full records are ultimately produced by the cataloging process. Should one use full, variable-length, MARC-like records for circulation control? The conversion, on-line storage, management, and access of a large file of full bibliographic records are expensive propositions. One may be compelled toward a lesser effort. Under much of the popular data manage- ment software it is easier to organize and store fixed length records than variable length records with different combinations of fixed and variable length fields. The files of current item systems hold less-than-full biblio- graphic records: Bell Laboratories library utilizes two basic fixed length formats of 155 and 188 characters ( 18,19); the Eastern Illinois item file consists of 124-byte records ( 20); although the Ohio State system contains variable length records, they are less-than-full bibliographically, averaging 103 bytes ( 22 ) ; the ~1anned Spacecraft Center system has fixed length records of 168 characters ( 23). If not a full, MARC-like record, then what? Two questions may be asked: How much data should be converted for each record? and: How much of these data should be put initially into an item file? If one believes a fully integrated system may eventually take over some public catalog functions, then traditional author-title-subject accesses must be maintained, at least until proven unneeded. The minimum genuinely useful set of bibliographic data elements needed for futuristic information retrieval from library catalogs has not been proven; the safe but expensive answer is to convert Univ e r se of all items Two Types of Designs/ McGEE 193 Access Keys .,..------:~}Standard bibliogr aphic / descr i ption l St andard but noncomp r ehensively --__ ::;;~ ~ppli~d.single-element unique A----- - /" 1dent1f1e r: e . g. , ISBN , SSN _,/ l Li brary- a ssigned ke ys s uch as item call number and accession numbe r No te ~means t he access key r etrieves all me mbers of a set ..-- me a ns the access ke y retrieves only so~e members of a set Fig. 1. Possible Access Ke ys to Sets of Availability Information full records. Initially, however, one might want no more data in an item file than are functionally justified. How much are a ctually needed ? The four existing item systems provide traditional information in new ways that have dramatically improved services to users. They answer sev- eral basic kinds of questions on-line: Does the library have book ? Is it available now? What books do I have charged out? Such queries can be answered by nonsubject, d escriptive bibliographic data, and by circula- tion status information that shows if items are absent, and when they may become available. For this an item file needs records only for items that are used, in contrast to a comprehensive on-line shelflist. Which records to include b ecomes a problem remarkably similar to deciding what books to put into low-access, compact storage , or to discard. The two university libraries with item systems chose comprehensive conversions: Eastern Illinois for 235,000 volumes ( 20 ), and Ohio State for 800,000 titles ( 22). What are the potential advantages to users of an item system? If one only wants to know what books are charged, an absence system will suffice. Both the penalties and promise of an item system lie in its bibliographic store-in the records it holds (scope ), and in the data these records con- tain (content ) . Unless real-time querying of an item file can substitute for at least some manual searches of the public catalog, and in an improved way, its bibliographic data offer no direct advantages to users of a circula- tion system; an item system will provide no direct circulation services that an absence system could not. Applying this as a test to the utility of a noncompreh ensive item file (a file of records only for items that are, or are likely to b e, in use ), we find perhaps the key question for development of item systems among libraries with very large catalogs: To what extent may 194 Journal of Library Automation Vol. 5/3 September, 1972 a noncomprehensive item file substitute for accesses to a comprehensive public catalog? Although related, this is not the same question as what proportion of a library's book stock circulates. This is a question of how the public catalog is used: by whom , and for what? Lipetz's study of the card catalog in Yale University's Sterling Memorial Library gives insight to at least that institution's catalog use (30). He found that 73 percent of the users attempting searches were looking for particular documents (known items ). Overall, users' approaches to catalog searches were: author, 62 percent; title, 28.5 percent; subject, 4.5 percent; and editor, 4 percent. This may encourage one to believe that an item file which is accessible by author and title can handle a significant portion of manual catalog lookups. If so, developers of item systems may want to consider strategies similar to the following. If it is shown that satisfactory author /title access can be provided by an item file, then perhaps a large library is justified in dividing its card catalog and retaining only the subject-access portion. The argument is that author/ title access can be provided by an item file of partial records containing nonsubject descriptive data, whereas the requirements for subject access involve still more data that are likely to change as subject descriptions do. However, if a manual card catalog for subjects were maintained , this would facilitate updates of subject headings, and at the same time permit the most efficient format and smallest set of machine-held item file records to be kept. Through the use of machine-held subject authority files, maintenance instructions and replacement heading cards could be computer-produced for update of the manual subject catalog. (Distribution of machine-readable subject headings is being considered by the Library of Congress MARC Development Office.) Reduction in the maintenance and use of a full manual author-title-subject catalog by library technical services departments could produce significant savings, aside from whatever direct improvements in access that machine files might provide. If the item file were noncomprehensive, or contained retrospective records only for those items that circulated, then author/title accesses would of course be limited to the contents of that file. This would require maintenance of full manual catalogs for noncirculating items. Two general alternatives to a comprehensive item file of full records come to mind. One is to utilize records as they are created by the cataloging process, complemented by partial-record conversion (conveniently, in- house) for only those retrospective items that circulate. Another is to create a special circulation-only item file of partial records. This kind of system would use an item file primarily as an alternative to machine-readable book cards. Absence and holdings querying would be supported, but not acquisitions or cataloging functions. A system like this, with an item file of partial records, may be the most reasonable answer for large research libraries ( 28). It should be able to give the same circulation services as an absence system, in addition to satisfying certain kinds of Two Types of Designs j.McGEE 195 public catalog searches. The simplifications for data conversion, data man- agement software, and terminals are worth special evaluation as a middle or simple approach to on-line circulation system development, with an item system design. ITEM SYSTEM QUERYING, BIBLIOGRAPHIC DATA STRUCTURE, AND FILE ORGANIZATION The querying capabilities featured by each item system differ somewhat, and are explained in part by differences in bibliographic data structure and file organization. The data and design of an information-providing system are fundamental to the kinds of services it can provide. A useful conceptual model is the traditional manual library system in which separate files are used for different functions: an in-process file for technical processing, a shelflist for the official holdings, a public catalog for reference, and a circulation file to control item absences. Among these the file for circulation contains less bibliographical data than the others, since even a single data element such as the call number can uniquely identify a physical item and relate it to a fuller description, such as a shelflist record. A circulation file of this nature is in effect a manual absence file, and serves no major purpose other than circulation control. vVere the processing requirements not im- practical, circulation status cou ld be more usefully recorded in public catalog records, in the manner of an item file. The Eastern Illinois University system has an indexed sequential item file organized by item call number plus accession number. It may be queried by this key to get an exact match to a single record, or by a classification number to get a file scan of corresponding records. Query by user number displays charges to the user. The Ohio State system has a read-only item file that is randomized by item call number, but it may also be accessed by an author/title key that consists of the first four characters of the main entry plus the first five characters of the first significant word or words of the title. The second five characters can be blanked to provide author-only access. The file is also accessible by an item record number that is assigned sequentially to new records entering the file. The Bell Laboratories system provides access by item number to its item file, and uses a set of twelve query codes to obtain status and other factual information on users and items. User number and item number are the query keys. The item file is also used to produce a book catalog that gives the item numbers by which queries can be made. The item file of the Manned Spacecraft Center library is sequentially organized by item number, and can also be queried by call number and user number. These systems demonstrate alternatives for bibliographic data structure and file organization and access methods that are summarized by the author in a separate work ( 1) and explained by the references for each system 196 Journal of Library Automation Vol. 5/3 September, 1972 ( 18,19,20,21,22,23). Briefly, the Eastern Illinois, Bell Laboratories, and Manned Spacecraft Center systems use a fixed-length item record structure, and charge data are written directly to item record fields that are defined for this purpose. The Ohio State system has a variable length , read-only item record. Transaction data are recorded in an absence file, and linked to the item file. In the Bell Laboratories system what is conceptually a single item file is actually two separately organized physical Rles with different record formats. Fixed-length book records are organized sequentially, and each contains fields for three loans and two reserves; all copies and volumes are repre- sented. Journal records arc organized by an indexed sequential method, and do not contain copy and volume data, which must be added at transac- tion time. In the Eastern Illinois and Manned Spacecraft Center systems the item file contains a separate record for each physical volume in the library. The Ohio State item file contains one record per title. Although it is difficult to tell without detailed programming knowledge of these systems, theBell Laboratories data structure seems to enable exact matches to single records for status queries (e.g., What is the status of title number ? What is the status of copy ? ) in ways that the Eastern Illinois and Ohio State systems can only accomplish through a terminal operator's interpretation of a displayed set of matching records. The Bell Laboratories system can therefore conduct queries of this nature with keyboard/printer terminals, whereas the Eastern Illinois and Ohio State systems require CRT devices to display large amounts of information. It can also ask what overnight loans are still out, possibly a function of its journal file's data structure. The software implications of these various capabilities will not be dis- cussed here. Suffice it to say that absence systems require simpler accesses and data management than do the kind of item systems we have discussed, and that as item files are designed to replace all or selected public catalog functions, their data management and user interface requirements become greater. SPECIAL ASPECTS OF THE CHARGE FUNCTION Two aspects of the charge function have special significance for on-line systems: patron self-charging, and a telephone and mail or delivery service. Among the on-line systems we surveyed, only the one at Northwestern University is reported to be self-charging. To have patron self-charging requires that charge transactions be simple and convenient. Data transfer methods that require little effort are therefore preferred, and the usc of machine-readable user and item identifications seems to be the best current choice. The Northwestern system uses Hollerith- punched user badges and book cards. Other methods of data entry such as magnetic card reading and optical scanning are often mentioned for circula- Two Types of Designs/McGEE 197 tion control, but as of December 1971 we know of none that has resulted in a practical terminal-based svstem for on-line charging. Two of the item systems promote a telephone and delivery service: the Bell Laboratories system and the Ohio State University system. In each system inquiries can be directed to operators, who may conduct on-line searches of library holdings and circulation information for specific items. The kinds of questions that can be asked are "Does the library have ___ ?" and "Is it charged?" We noted earlier that a catalog can he made "remotely accessible" in several ways: e.g., by a special group that performs manual card catalog lookups for telephoned requests, or by users' consulting multiple copies of book or microform catalogs. In principle, a variety of catalogs and circulation systems can be used together in a telephone inquiry system of this nature. For example, the Library of the Georgia Institute of Technology has recently implemented an "extended catalog access" and delivery service that is based on microfiche copies of its catalog at thirty-six campus locations, coupled with telephone inquiry to a manual circulation system ( 31). Readers look up wanted items and telephone the library to request them. The manual circulation file is checked: available items are charged for delivery, or reserves may be placed for items that are already loaned. Presumably, the currency of information and quickness of response times are better in an on-line circulation system than in any other type. An item system can furnish both holdings and absence information. An absence system needs to be coupled to another system to furnish holdings informa- tion: a requirement is that the holdings information must contain a key by which the corresponding absence records can be accessed. These are basic considerations in providing a telephone and delivery service. SYSTEM BACKUP The problems considered here derive from two conditions: unexpected system downtimes and scheduled periods when the system is not in opera- tion. At these times a system cannot execute on-line tasks . Two classes of backup problems are: 1) provision of service to users during the downtimes; and 2) updating system files to record downtime transactions. The latter are termed recovery problems. One way to backup the query function is to periodically print a list of circulating items. The frequency and ease of access (e.g., number of copies, their locations, telephone access to them ) of such a list can pose substantial problems. An alternative to scheduled printings is an arrangement for quick printouts of a frequently copied backup tape on a redundant computer system. The basic recovery problem is how to enter data into the system for transactions that took place during downtimes. Presumably, if unexpected do\\'ntimes are not inordinately long, discharges and other file updates may be postponed. This simplification is helpful, since transaction sequences 198 Journal of Librm·y Automation Vol. 5/3 September, 1972 among different kinds of updates can become quite complicated, e.g., dis- charges undo charges, and confusing the sequence causes problems: Al- though other kinds of system updates have their own special problems, the following paragraphs only briefly discuss the backup and recovery of charging activities. Absence Systems The provision of transaction evidence in off-line mode has already been suggested for absence systems that have the necessary terminal capabilities. Similarly, there are configurations which, in off-line mode, read user and item cards and produce machine-readable transaction records that can be read-in during post-downtime recovery procedures. The Northwestern University system has a special backup terminal for this purpose. The provision of automatic recovery facilities is an attractive feature. Alterna- tively, multiple part manual transaction records can be made for charges during downtimes. One part may serve as transaction evidence; the other can be used for manual input of recovery data, when the system is up again. Exactly how this is done depends upon other details of the particular system. Item Systems Since inputs of user and item identification numbers are sufficient to record charges in item systems, the recovery problem can be simpler than for absence systems. Typewriter-like terminals with card or paper tape punches or magnetic recorders can be used to create machine-readable recovery data. The requirements for transaction evidence may be crucial. Perhaps the solution to the worst case is the use of a two-part manual transaction form: one copy for transaction evidence, and the other, as above, for post-downtime recovery inputs. We can summarize three hardware solutions for transaction backup in either system type: 1) total system redundancy, 2) backup at the terminal level, and 3) a backup facility between terminal and computer. The cost of full system redundancy makes it unlikely. A facility to log transactions during downtimes is more feasible; there are several choices. One such alternative is to record transaction data off-line in machine-readable form at each data collection point: e.g., to punch paper-tape or cards. Another alternative is to record data from several terminals with a single device, such as a magnetic recorder, or a control unit that coordinates a multiterminal system. A third solution, a variation on the second, is a mini-computer which links terminals, and handles telecommunications with a larger machine that holds system files. This approach has been taken by Bucknell University. It affords more comprehensive backup than merely capturing transaction data. Other functions, such as checks for user validity and reserved items, can be performed on a relatively reliable mini-computer dedicated to circulation. Two Types of Designs/McGEE 199 CONCLUSION On-line library catalogs are now a reality, but not yet for the exotic information retrieval work once popularly projected. Instead, relatively straightforward accesses by author, title, and call number are supporting circulation, reference, and technical processing functions. The needs for better circulation systems and network processing of shared cataloging data have stimulated developments of large-scale operational (not experimental) systems around resident files of on-line bibliographic records. Developers have not waited for solutions to fundamental problems of automatic indexing and information retrieval ; they have put large bibliographic files on-line and provided relatively simple, multiple access keys. The advances that have been made are in methods of physical access to bibliographic records, not in the intellectual or subject access to information. No new information is being retrieved, but familiar processes are being performed in better ways. Improvements in the ease and time of accessing library files have dra- matically upgraded the library's responses for its own routine work and to the public in general. We are experiencing the first of a new generation of practical systems that perform traditional functions with on-line rather than manual files, with as much benefit as possible short of better subject access. The new systems are transcending the barriers to convenient use that have been imposed by the size, complexities, and awkwardness of large manual systems. Historically, it has been impractical to add circulation information to each record in the public catalog for an item. With on-line files of single records per item this is now possible. State-of-the-art computing affords multiple access keys to a record, instead of duplicating it for additional entries as in manual catalogs. How many and which keys are furnished largely determines the extent to which an on-line catalog can replace a traditional one. Difficult cost and technical problems explain the current approaches. Full requirements of a public catalog have been avoided; simpler files have been built to handle explicit processing functions. The advantages are simplified records and fewer access points. Full bibliographic records are variable length, often large, and sometimes eccentric-and therefore rela- tively expensive to handle in machine form. In principle the overhead for access is the same as for manual files: the more entries that are provided, the greater the storage, processing, and cost. Systems with simpler files than the public catalog have therefore been built. There have been no machine equivalents of large library catalogs; so we have studied manual ones to theorize ideal characteristics. In some cases this model may have supplied a misleading bias. Studies of the new on-line systems at work could possibly revise our notions of what is needed. The kinds of systems now emerging are answers for the foreseeable futur e. The tradition of separately organizing and managing public and technical ser- vices will be challenged by the integrated systems. Their centralized files , data handling, and access methods transcend functional boundaries which 200 Journal of Library Automation Vol. 5/3 September, 1972 grew between library tasks that used different but redundant manual files and evolved separate units and procedures to accomplish virtually the same basic data processing functions. The profession has yet to widely appreciate the new overview and managerial changes that are invited. Reaction to them may be projected as a fourth and perhaps painful trend. In sofar as no fully integrated systems have yet been developed, it is likely that as they emerge they will force substantial changes to traditional patterns of library organization and management. ACKNOWLEDGMENTS This work was supported by the University of Chicago Library Systems Development Office under CLR/NEH Grant No. E0-262-70-4658 from the Council on Library Resources and the National Endowment for the Humani- ties, for the d evelopment and operational testing of a library data manage- ment system. REFERENCES 1. Rob McGee, A LiteratU1'e Survey of Operational and Emerging On- Line Library Circulation Systems (University of Chicago Library Systems Development Office, Feb. 1972). Available as ERIC/CLIS ED 059 752. MF$0.65, HC$3.29. 2. , "Key Factors of Circulation System Analysis and Design," College and Research Libraries 33:127-140 ( Mar. 1972 ). 3. H. K. G. Bearman, "Library Computerisation in West Sussex," Program: News of Computers in British Libraries 2:53-58 (July 1968). 4. , "West Sussex County Library Computer Book Issuing System," Assistant Libra1·ian 61:200-202 ( Sept. 1968 ) . 5. RichardT. Kimber, "An Operational Computerised Circulation System with On-Line Interrogation Capability," Program: News of Computers in British Librm·ies 2 :75-80 (Oct. 1968 ) . 6. Homer V. Ruby, "Computerized Circulation at Illinois State Library," Illinois Libraries 50:159-162 ( Feb . 1968 ). 7. Robert E. Hamilton, "The Illinois State Library 'On-Line' Circulation Control System," in: Proceedings of the 1968 Clinic on Librm·y Appli- cations of Data Processing. (Urbana, Ill.: University of Illinois Grad- uate School of Library Science, 1969 ) p. 11-28. 8. IBM Corp., On-line Library Circulation Control Syste m, Moffet Li- brary, Midwestern University , Wichita Falls, T exas. Application bri ef K-20-0271-0. ( White Plains, N.Y.: IBM Corp., Data Processing Div. , 1968) 14 p . 9. Calvin J. Boyer and Jack Frost, "On-Lin e Circulation Control- Midwestern University Library's System Using an IBM 1401 Computer in a 'Time-Sharing' Mode," in: Proceedings of the 1969 Clinic on Two Types of Designs/McGEE 201 Library Applications of Data Processing. (Urbana, Ill.: University of Illinois Graduate School of Library Science, 1970) p. 135-145. 10. Charles D. Reineke and Calvin J. Boyer, "Automated Circulation System at Midwestern University," ALA Bulletin 63:1249-1254 (Oct. 1969). 11. Belfast, Queen's University, School of Library Studies, Study Group on the Library Applications of Computers, First Report of the Working Party (Belfast University, July 1965) 18 p. 12. Richard T. Kimber, "Studies at the Queen's University of Belfast on Real-Time Computer Control of Book Circulation," Journal of Docu- mentation 22:116-122 (June 1966) . 13. , "Conversational Circulation," Libri 17:131-141 ( 1967). 14. ___ ,"The Cost of an On-Line Circulation System," Program: News of Computers in British Libraries, 2:81-94 (Oct. 1968). 15. Ann H. Boyd and Philip E. J. Walden, "A Simplified On-Line Circu- lation System," Program: News of Compute1·s in Libraries 3:47-65 (July 1969). 16. Velma Veneziano and Joseph T. Paulukonis, "An On-Line, Real-Time Time Circulation System." [This documentation of the Northwestern University library system was made specially available to the author. A later version with the same title appears in LARC Reports 3:7-48 (Winter 1970-71)]. 17. H . Rivoire and M. Smith, Library Systems Automation Reports 1971- A-2, Bucknell Library On-Line Circulation System (BLOCS). Ellen Clarke Bertrand Library ( 15 Mar. 1971) 19 p. 18. R. A. Kennedy, "Bell Laboratories' Library Real-Time Loan System (BELLREL)," lOLA, 1:128-146 (June 1968). 19. , "Bell Laboratories' On-Line Circulation Control System: One Year's Experience," in : Proceedings of the 1969 Clinic on Library Applications of Data Processing. (Urbana, Ill.: University of Illinois Graduate School of Library Science, 1970) p. 14-30. 20. Paladugu V. Rao and B. Joseph Szerenyi, "Booth Library On-Line Circulation System (BLOC)," ]OLA, 4:86-102 (June 1971). 21. Richard H. Stanwood, "Monograph and Serial Circulation Control," A paper for the International Congress of Documentation, Buenos Aires, Sept. 21-24, 1970. National Council for Scientific and Technical Re- searcb, Buenos Aires ( 1970) 23 p. 22. IBM Corp., Data Processing Division, Functional Specifications: A Circulation System for the Ohio State University Libraries, Gaithers- burg, Maryland (November 26, 1969) various paginations. [This and other technical documentation were made specially available to the author. This is now available through ERIC/CLIS as: On-Line Remote Catalog Access and Circulation Control System. Part I: Functional Specifications. Part II: User's Manual. November 1969. 151 p. ED 050 792. MF $0.65, HC $4.00] 202 Journal of Library Automation Vol. 5/3 September, 1972 23. Edward E. Shumilak, An Online Interactive Book-Library-Management System. NASA Technical Note NASA TN D-7052. National Aeronautics . and Space Administration, Washington, D.C. ( March 1971 ) 40 p. [This document is available through the National Technical Information Service under Document Number N71-20526] 24. University of Chicago Library, A P1'0posal for the Development and Operational Testing of a Library Data Management System, Herman H. Fussier and Fred H. Harris, principal investigators. ( Chicago, Ill.: 1970) 44 p. 25. Richard De Gennaro, "The Development and Administration of Auto- mated Systems in Academic Libraries," ]OLA, 1:75-91 (Mar. 1968). 26. Ellen W. Miller and B. J. Hodges, "Shawnee Mission's On-Line Cata- loging System," ]OLA 4:13-26 (Mar. 1971). 27. Simon P. J. Chen, "On-Line and Real-time Cataloging," American Libraries 3:117-119 (Feb. 1972 ). 28. University of Chicago Library, Development of an Integrated, Com- puter-Based, Bibliographical Data System for a Large University Li- brary, Annual Report 1967/ 68. By Herman H . Fussier and Charles T. Payne. University of Chicago Library, Chicago, Illinois ( 1968 ) 17 p. + appendixes. 29. Frederick G. Kilgour, Letter to the author 23 November 1971. 30. Ben-Ami Lipetz, User Requirements in Identifying Desired Works in a Large Library, Final Report, Grant No. SAR/ OEG-1-71071140-4427, U.S. Department of Health, Education, and Welfare, Office of Educa- tion, Bureau of Research. (New Haven, Conn.: Yale University Library, June 1970) 73 p. + appendixes. 31. "Library Extends Catalog Access and New Delivery Service," [ 4 p.] A brochure issued by Price Gilbert Memorial Library, Georgia Institute of Technology, Atlanta, Georgia, 1972.