PROCEEDINGS 
 
 OF THE 1972 CLINIC 
 
 ON LIBRARY APPLICATIONS 
 
 OF DATA PROCESSING 
 
LIBRARY OF THE 
 
 UNIVERSITY OF ILLINOIS 
 
 AT URBANA-CHAMPAIGN 
 
 025 
 
 C64p 
 1972 
 cop. 3 
 
The person charging this material is re- 
 sponsible for its return to the library from 
 which it was withdrawn on or before the 
 Latest Date stamped below. 
 
 Theft, mutilation, and underlining of books 
 are reasons for disciplinary action and may 
 result in dismissal from the University. 
 
 UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN 
 
 APR 1 3 W3 
 
 
 DEC 2 
 
 i 
 
 11979 
 
 L161 O-1096 
 
Proceedings of the 1972 Clinic 
 on Library Applications 
 
 of Data Processing: 
 
 Application of On-Line Computers 
 
 to Library Problems 
 
PROCEEDINGS OF THE 1972 CLINIC 
 ON LIBRARY APPLICATIONS 
 
 OF DATA PROCESSING: 
 
 APPLICATIONS OF ON-LINE COMPUTERS 
 
 TO LIBRARY PROBLEMS 
 
 Edited by 
 F. WILFRID LANCASTER 
 
 Papers Presented at the 
 
 1972 Clinic on Library Applications 
 
 of Data Processing, April 30 May 3, 1972 
 
 University of Illinois 
 
 Graduate School of Library Science 
 
 Urbana, Illinois 
 
1972 by the Board of Trustees of the University of Illinois 
 
 LC Card Number: 65-1841 
 ISBN: 0-87845-035-1 
 
TABLE OF CONTENTS 
 
 INTRODUCTION 1 
 
 F. WILFRID LANCASTER 
 
 ON-LINE INTERACTIVE SYSTEMS IN LIBRARIES, NOW AND 
 
 IN THE FUTURE 3 
 
 I. A. WARHEIT 
 
 THE OHIO STATE ON-LINE CIRCULATION SYSTEM 22 
 
 HUGH C.ATKINSON 
 
 LOLITA: AN ON-LINE BOOK ORDER AND FUND ACCOUNTING 
 
 SYSTEM 29 
 
 LARRY AULD AND ROBERT BAKER 
 
 ON-LINE TECHNOLOGY IN A LIBRARY NETWORK 54 
 
 IRWIN H. PIZER 
 
 ON-LINE SERIALS CONTROL AT UCLA 69 
 
 JAMES FAYOLLAT 
 
 ON-LINE REAL-TIME SELF-SERVICE CIRCULATION 
 
 AT NORTHWESTERN UNIVERSITY 82 
 
 JOSEPH T. PAULUKONIS 
 
SHAWNEE MISSION'S ON-LINE CATALOGING SYSTEM: 
 
 THE FIRST TWO YEARS 94 
 
 ELLEN WASBY MILLER AND B. J. HODGES 
 
 A USER'S VIEW OF BALLOTS 109 
 
 A. H. EPSTEIN AND ALLEN B. VEANER 
 
 AUTOMATION, OR RUSSIAN ROULETTE? 138 
 
 ELLSWORTH MASON 
 
 SUMMARY OF THE CLINIC 157 
 
 GLYN T. EVANS 
 
 INDEX . 167 
 
INTRODUCTION 
 
 The ninth annual Clinic on Library Applications of Data Processing was 
 conducted by the Division of University Extension and the Graduate School 
 of Library Science of the University of Illinois, on April 30-May 3, 1972. Like 
 the eighth clinic, it was devoted to a single topic: the application of on-line 
 computer systems to the mechanization of library operations. Significant 
 advances have been made in this field in the last three or four years and a 
 number of interesting and innovative systems have become operational in 
 some relatively small institutions as well as the very large library organizations. 
 In planning this clinic an attempt was made to include papers on a wide 
 range of library applications of on-line computers, as well as to include 
 libraries of various types and various sizes. Two papers deal with on-line 
 circulation control (the Ohio State University system, described by Hugh C. 
 Atkinson, and the Northwestern University system, described by Joseph T. 
 Paulukonis), one with acquisitions (LOLITA at Oregon State University 
 Library, described by Larry Auld and Robert Baker), one with serials control 
 (a system at the Biomedical Library, UCLA, described by James Fayollat) and 
 one with on-line cataloging procedures (used in the Shawnee Mission Public 
 Schools and described by Ellen Miller and B. J. Hodges). Multi-functional 
 on-line systems are represented by the BALLOTS project at Stanford 
 University (described by A. H. Epstein and Allen B. Veaner). I. A. Warheit of 
 IBM gives a comprehensive overview of the application of on-line interactive 
 systems in libraries. Irwin Pizer describes the use of such systems in library 
 
7972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 networks, and Glyn T. Evans undertakes the difficult task of identifying and 
 summarizing key points made by previous speakers. 
 
 Ellsworth Mason, to use his own words, plays the role of Daniel in the 
 lions' den and plays it in his own able and inimitable way. His talk drew a 
 crowd that probably set a record for attendance at a session in this series of 
 clinics. The talk was entertaining as well as provocative and it generated many 
 questions, which were ably handled by the speaker. Some hostility toward the 
 speaker was evident in certain segments of the audience! 
 
 I am very grateful to all of the speakers whose work appears in this 
 volume and whose excellent presentations made this a very successful meeting. 
 Grateful acknowledgements must also be made to my colleagues on the 
 planning committee: Herbert Goldhor, Director of the Graduate School of 
 Library Science, and J. Divilbiss, Associate Professor, Graduate School of 
 Library Science, University of Illinois. To the latter in particular must go full 
 credit for the planning and implementation of the on-line demonstrations that 
 were an important feature of this ninth Clinic. 
 
 F. WILFRID LANCASTER 
 
 Chairman and Editor 
 
 June 1972 
 
I. A. WARHEIT 
 
 Program Administrator 
 
 Information Systems Marketing 
 
 IBM Corporation 
 
 San Jose, California 
 
 On-Line Interactive Systems 
 in Libraries, Now and in the Future 
 
 For the sake of clarity one can discuss on-line interactive systems with 
 reference to their technology, their economics, and their application and 
 utilization, even though all these aspects are obviously intertwined and 
 inseparable. They will, however, be considered separately. 
 
 On-line, interactive systems were conceived long ago, even before 
 computers. Vannevar Bush's Memex was essentially an on-line interactive 
 system, as were the first teaching machines. What is considered the first 
 computer-based interactive systems were implemented by M. I. T. in its SAGE 
 system which responded to RADAR signals. From a practical, economically 
 feasible point of view, however, certain technological developments were 
 necessary before on-line processing could be widely adopted. 1 
 
 TECHNOLOGY 
 
 The first computers were serial devices with all information stored on tape. 
 Access to a record involved passing a reel of tape and serially searching the 
 records. Although information could be stored on drums and thus provide 
 very rapid access to records, the capacities of drums were so low and drum 
 storage was so expensive that their use was confined almost entirely to 
 program information, tables, etc. The file of records, except for a few exotic 
 and expensive applications, was not stored on drums. 
 
 The only practical, economic storage, therefore, was on tape, and 
 processing, for the most part, had to operate in a batch mode. In the 
 
4 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 mid-1950s the RAMAC, the first disk file, was announced. With RAMAC it 
 was possible to access a record directly without having to search serially a 
 whole file. With the disk, there is actually a serial search of a track, but this is 
 so short that for all practical purposes one can speak of direct access to a 
 record. With the disk file, the computer in a sense graduated from the age of 
 the scroll to the age of the leaved book or card file. 
 
 With the availability of disks, it became feasible for man to communicate 
 directly with the computer. Where previously most communication with the 
 computer was via the punched card or the punched paper tape, now a number 
 of terminals, primarily typewriter and teletype keyboards, were developed or 
 adapted to communicate with the computer. These terminals, which were a 
 great convenience, because now the computer inputs could be prepared where 
 the data originated, were used for remote job entry and to order printouts 
 from the files. Competing devices, primarily key-to-tape recorders and optical 
 scanners were more economical than the terminals however, and so direct 
 remote job entry for information collection did not find very wide 
 acceptance. 
 
 The use of on-line terminals has been popular for text editing which was 
 developed in the early 1960s, especially for those applications that required 
 frequent, rapid and radical changes in text. Even here, the development of 
 such machines as the magnetic tape Selectric typewriter (MT/ST) provided a 
 number of text editing capabilities at such a low cost that many users, and 
 especially libraries including the Library of Congress found the MT/ST a 
 very satisfactory and economical device to create records and edit text for 
 computer storage. 
 
 Although other devices have been less expensive than on-line terminals for 
 remote job entry and for limited text editing, they have been preferred where 
 large amounts of text must be handled or where complicated text editing is 
 required. 2 For example, when an intellectual activity has to be supported such 
 as doing calculations for the engineer, scientist, statistician, accountant, etc., 
 or a proper entry must be chosen to fulfill an order or make a flight 
 reservation, on-line processing is again the most preferred method. It saves 
 much human labor, increases and speeds up the throughput, and, in many 
 instances, improves the precision to such an extent that commercially 
 competitive industries and professions are adopting on-line methods wherever 
 it is advantageous. 
 
 With the development of direct access storage devices (DASD), it became 
 feasible to communicate with the computer in real time. The user could 
 interrogate the files to get an instant response. If the amount of information 
 that was transmitted and displayed was not extensive, then the voice grade 
 telephone lines and the 15-characters-per-second typewriter terminals were 
 adequate. Where, however, the number of characters to be displayed exceeded 
 200 to 300, then the user became impatient since he could read much faster 
 
ON-LINE INTERACTIVE SYSTEMS 5 
 
 than the terminal could type. The display terminal, built around the cathode 
 ray tube (CRT), has therefore become very popular; it can display 500 to 
 1,000 and more characters instantaneously, and is proving to be, in its basic 
 form at least, inexpensive to manufacture and operate, and hence very 
 competitive with the typewriter terminals. 
 
 One major objection librarians have had to the display terminal is that the 
 more available, low cost display units have had limited character sets, and 
 have not provided the upper and lower case and special characters that 
 librarians want. Extended character sets are available with display terminals 
 but they are relatively expensive. It actually does not cost much more to 
 manufacture a terminal with an extended character set; the market has not 
 yet justified the large-scale manufacture of such terminals. As the market 
 develops, especially in the so-called media industries-advertising, printing, 
 etc. large-scale manufacturing will bring down the cost of extended character 
 set terminals, and the librarians will get the terminals they need at a price that 
 they can afford. 
 
 There are other aspects associated with terminals of interest to librarians. 
 The so-called intelligent terminals that permit a certain amount of processing 
 by providing access to special local files, and the buffered terminals that will 
 hold working amounts of inputs and outputs, represent special approaches to 
 develop the most economic configurations for a variety of applications. In 
 other words, the terminals that will be used will range from the so-called 
 dumb ones, like the touch tone telephone, to the intelligent ones which are 
 essentially small computers. 
 
 The use of terminals initiated the need for communication links. Although 
 many data processing people were apprehensive that the communications 
 industry would become a major bottleneck for data processing, this has not 
 proved to be the case. Attempts are currently being made to reduce communi- 
 cation costs, and there is every indication that they will succeed. Hardware, in 
 fact, is probably the smallest obstacle to the development of interactive 
 library systems. 
 
 Even the software problems which affect library automation and also 
 affect batch systems, actually present no real hindrances. The main problem 
 for library automation is the organization and handling of a variety of very 
 large files. In addition, library bibliographic files are somewhat different from 
 the more usual commercial and name (so-called people) files. Library records 
 are long; the average MARC record is of the order of 600 bytes 3 to which has 
 to be added the local library's data including costs, holdings, etc. There are 
 many records. There are 16 million records in a National Union Catalog, and, 
 the Library of Congress needs a trillion bit file to store such a file. 4 Although 
 such files exist and are being used very successfully, they are slow and hence 
 not well adapted for interactive processing. In a typical situation, it now takes 
 about five seconds-an intolerable length of time for a computer-to get the 
 
6 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 first record. Actually this is not very bad since by use of lookahead, overlap, 
 buffering and taking advantage of the slowness of the human, the getting of 
 subsequent records is faster and does not necessarily hold up processing. 
 
 The lessened reliance on physical movement and the greater reliance on 
 electronic switching is so speeding up the accessing of magnetic records that 
 fetching a record will not be the bottleneck it has been. There is also the 
 exciting potential of holographic memories, but that is farther in the future. 
 Massive storage devices and digital communications are being improved very 
 rapidly. In an industry which has had a rapid technological growth, these two 
 areas are currently having the most rapid growth and development. * 
 
 Computer designers are very much concerned with the balance between 
 the various working parts of a system. For example, getting the input/output 
 (I/O) functions in balance with the internal processing can be a problem. 
 Wherever this type of physical bottleneck develops, one can be sure that a 
 great deal of effort will be devoted by manufacturers and data processing 
 personnel to solving the problem. Putting together the physical components of 
 a system is not the job for an amateur. There have been several computer 
 configurations assembled by library systems people on their own which have 
 left a lot to be desired. 
 
 With the coming of time sharing, the most difficult problem was what 
 data processing personnel call resource allocation or resource management. 
 This also involves communications control, i.e., controlling the traffic generated 
 by a number of different users, each doing different tasks from different 
 terminals. As a result, operating systems and supervisors or monitors be- 
 gan to be developed. Since different users accessed a number of different 
 files and there was a growing desire to separate application programs from 
 data base management, major efforts were devoted to building independent 
 data management systems. These developments all represent a currently strong 
 movement towards making application programs independent of the host. For 
 library interactive systems, data base/data communications (DB/DC) systems 
 are needed that will work efficiently in a conversational mode and on 
 unformated, variable length records. Such programs are currently being 
 developed using a number of different approaches; as a result there is some 
 confusion and chaos. Standard, supported programs are however now available 
 and users do not have to compromise or make do with supervisors and 
 monitors that are barely adequate or prohibitively expensive. 5 
 
 With on-line processing, data base integrity becomes very critical. WKere 
 there is updating in place, the files have no old master on which one can fall 
 back in case of failure. The file, therefore, must be protected while processing 
 goes on in core. Input from a terminal cannot be held to the quality standards 
 normally expected from keypunch. There are no verify operations from the 
 terminal and bad input data can damage the data base. If the originator inputs 
 the data and scans it on the display terminal before storing it, the inputs are 
 
ON-LINE INTERA CTI VE S Y STEMS 7 
 
 usually of very high quality. Nevertheless there is a great need for very good 
 editing and input validation. Data bases also have to be protected from faulty 
 application programs which can occur when existing programs are modified. 
 
 For all the above and a number of other security reasons, it is extremely 
 important to have powerful DB/DC systems. The development of such 
 programs is a highly specialized task. One must caution library systems 
 personnel against preparing homemade, special DB/DC programs. This is an 
 expensive waste of time which really does not aid the library, even though it 
 may satisfy the ego of the system designer. Essentially, what I am trying to 
 emphasize is that library people should not try to act as engineers or 
 programmer specialists building type 1 programs, but should devote their time 
 to application programs and problems that are peculiar to libraries. 
 
 One could go on to analyze a number of different aspects of data base 
 management, data communication, and operating systems, but these are really 
 not any impediment to the adoption and utilization of interactive library 
 systems. There are a number of fairly satisfactory software programs for all of 
 these problems and a large number of people are working on improving or 
 replacing these programs with better systems. 
 
 File and index organization is much more specialized and pertinent to the 
 success of library programs than the DB/DC programs. Although computer 
 professionals and the computer industry are devoting an appreciable effort to 
 the organizing and accessing of large files, they often overlook or ignore the 
 special problems of library files. Library files are different and are used 
 differently from the more usual data bases found in business, industry and 
 science. Librarians and the library systems personnel must, therefore, devote 
 some thought and effort to the organization of their files. 
 
 Librarians are beginning to appreciate the economics of book storage 
 where little-used materials are kept in less accessible but more economical 
 storage facilities. However the cost of retrieving and returning the book from 
 such storage is high compared to that of retrieving the more frequently used 
 materials which are kept in the most expensive storage area close to the 
 library user. 
 
 However, the librarian is reluctant to organize all his records similarly, 
 feeling that the information seeker will not understand and hence will be less 
 tolerant of impediments and delays in finding information. Once having found 
 the books he wants, the library patron is more apt to be tolerant about the 
 delivery of the older, more exotic and hence less accessible items. Much of the 
 present effort in the data processing community is to organize files based on 
 usage patterns. Although the librarian may accept this concept for his 
 materials, he is less apt to accept this for his subjects and authors. He 
 therefore has no hesitancy about putting in separate storage certain 
 information such as the data associated with ordering and receiving an item- 
 vendor, cost and the like-which he knows he will hardly ever use after the 
 
8 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 transactions are completed. However, subject and author information, even 
 though it may be associated with little-used materials, may be consulted 
 urgently and frequently both by library patrons seeking information and 
 librarians using the records as authorities for processing new acquistions. Data 
 processing people as a rule do not fully appreciate this and do not really 
 understand why the file organization developed for, let us say, a large 
 insurance company is not ideally suited for a file of library records of a 
 similar size. 
 
 The index organization of the more heavily posted areas-the Bible, 
 Shakespeare, the U. S. Government also present special problems. In the past 
 when using manual files, reliance has been on human discrimination in wading 
 through these interminable indexes. Librarians have ignored this problem 
 partially because they had no way of knowing how people used such indexes. 
 Now with computer systems having statistical modules, librarians will be 
 better able to know how people use the catalogs and other finding tools and 
 hence will be in a better position to do something about catalog organization. 
 
 At this point data processing is just beginning to attack the whole 
 problem of subject cataloging and indexing. Most library data processing 
 systems, certainly those in academic and public libraries, are merely accepting 
 the subject organization which has traditionally been used in library catalogs. 
 There are only a very few systems that not only allow for several levels of 
 subject indexing but also for completely different vocabularies. There are 
 many difficulties in accomplishing this, an example is the National Library of 
 Medicine's problems trying to interface the MeSH headings for pharmaceutical 
 and organic compounds with the much larger and more specific vocabularies 
 used by Chemical Abstracts and the Food and Drug Administration. 
 
 Even with the dual vocabularies detailed descriptors as well as standard 
 library subject headings that we used in the library management system 
 installed in the library of the IBM Advanced Systems Development Division, 
 Los Gatos Laboratory, and even though full file review is available for all 
 access points and Boolean operators can be used in searching the descriptor 
 indexes, and permutation is applied to titles and corporate authors, still the 
 research personnel are not fully satisfied with the searching capabilities of the 
 system. They want the full panoply of Boolean operators extended not only 
 to full subject headings, but also the masking and permutation capabilities 
 extended to the subject headings so that the individual elements making up a 
 subject heading can be searched like descriptors. Then the system will help 
 them make hierarchical searches, provide automatic cross reference control, 
 etc. 
 
 But this is a large area needing specific discussion and is not specifically 
 associated with on-line interactive systems. What is important for interactive 
 systems is that no matter what type of indexing or labeling used and no 
 matter what search strategies employed, there are going to be some heavily 
 
ON-LINE INTERACTIVE SYSTEMS 9 
 
 posted items which will be time-consuming to access, no matter how fast the 
 hardware might be. Some thought must therefore be given to the design of 
 accessing or addressing methods to overcome, or at least mitigate, this 
 difficulty. Probably some form of a hierarchical index sequential method as 
 presently applied in one library on-line system will have to be employed. 
 
 Of more immediate consequence and promising greater benefits for 
 organizing the main bibliographic records is the file organization used in the 
 Los Gatos Library management system mentioned above. 6 Although all library 
 records of an item were combined into a single logical record, the physical 
 storage and display of the record was segmented into separate physical parts. 
 The system designers decided to establish a hierarchy of physical storage since 
 only a small part of the record author, title, publisher, date, physical location 
 and availability-was used for finding purposes; and the rest of the stored 
 information, both bibliographic and commercial, was rarely used, and then 
 primarily for processing purposes. In normal searching of the files, only a 
 two-line record was displayed and the normal terminal could display up to 
 four such records simultaneously; if the total record of an item were desired, 
 then the rest of the record was fetched from a lower storage and only a single 
 record was displayed, usually filling the whole screen. At Los Gatos, it is 
 strongly suspected that not only is this more efficient for storage and machine 
 processing, but it increases the possibility that the use of the catalog record as 
 a means of finding information will succeed. The library catalog, after all, is 
 built for two purposes: one as a control of the collection and the other as a 
 finding tool. Too often the control functions complicate or at least obscure 
 the purely identifying and finding elements of the catalog record and hence 
 make the library catalog difficult to use, especially for the public. 
 
 Once it is recognized that the usage patterns of library files is different 
 from the more usual files used in other applications, one can make more 
 intelligent decisions about organizing the records. For example, in most 
 situations where a trade-off between processing and storage is possible, it is 
 more economical and more efficient to save processing time at the expense of 
 storage costs. Library usage seems to dictate just the opposite. With only very 
 tiny segments of the file accessed at any one time and with very large parts of 
 the file used extremely infrequently, it is more economical and basically more 
 efficient to conserve storage space as much as possible even at the expense of 
 increased processing costs. This may involve the extensive use of pointers and 
 codes and tables to compress records and avoid redundancies, or the physical 
 segmenting of records to avoid transporting more than is necessary. 
 
 Many of the problems described are still anticipatory. Except for the 
 rising quantity of MARC records which few libraries are really prepared to 
 store-librarians do not yet have very large files, nor do they make heavy 
 demands on them. It is going to be a while before the National Union Catalog 
 is stored in the computer or before all of Chemical Abstracts is available in 
 
10 1972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 digital form. In the meantime, technology is not going to stand still. It seems 
 rather pointless for the librarian to spend time worrying about solving 
 tomorrow's problems with today's tools, especially when he is not sure what 
 tomorrow's problems will be. 
 
 This all means that essentially there are no serious technological 
 difficulties which hinder the development of on-line, interactive library 
 systems. There is an awareness that, as interactive systems develop and as 
 people learn how they work and what their potentialities are, systems will grow 
 and change and library processing and library usage will change. Nevertheless 
 there is a good understanding of what needs to be done now to get started, 
 become operational, and to do today's jobs. It means that efforts should be 
 expended to produce application programs and operate them not only to do 
 productive work but also to explore the improvements that can be made. To 
 quote from the report Libraries and Information Technology, of the National 
 Academy of Sciences to the Council on Library Resources, "the primary bar 
 to development of national computer-based library and information systems is 
 no longer basically a technology -feasibility problem. Rather it is the 
 combination of complex institutional and organizational human-related 
 problems and the inadequate economic/value system associated with these 
 activities. National leadership to solve these problems has not emerged." 7 
 
 ECONOMICS 
 
 The "inadequate economic/value system" that the National Academy of 
 Sciences considered "the primary bar to development of national computer- 
 based library and information systems" encompasses the totality which they 
 call the "economics of information." The economic justification of infor- 
 mation in general and libraries in particular goes far beyond the purview of 
 this article which assumes that data processing has been accepted or at least is 
 being considered for adoption in libraries. However, a number of interactive 
 systems are being looked at and evaluations are being made about the utility 
 and value of on-line interactive systems. 
 
 An on-line system requires a communications link, a terminal, storage for 
 its records in a more expensive device than a reel of tape, and controls for the 
 flow of messages which makes it more expensive than an equivalent batch 
 system. The basic question is therefore, "Is it worthwhile to have an on-line 
 system?" The answer is, "Only if the total on-line operation is more 
 economical, and/or if it provides added services such as producing a better 
 product, or doing things more quickly." One should not minimize the con- 
 venience factor. People are willing to pay a great deal for things which 
 minimize work, save time and in general increase throughput. But basically, 
 for an on-line system to have wider use in the library, it must be more 
 economical than a batch system. 
 
ON-LINE INTERA CTI VE S Y STEMS 1 1 
 
 The hardware and software of an on-line system cost more than a batch 
 system. Ultimately the difference will not be as great as it is at present, since 
 a good on-line system does not require the large and expensive support 
 mechanism that all manual and batch systems require. These include card files, 
 printed lists and directories, guidebooks and other masses of printed paper. A 
 good on-line system can be truly paperless, and the maintenance of paper in 
 the library that is the working paper and not the bibliographic collection is 
 an extremely expensive business. It is reported that the Library of Congress 
 maintains over 1,200 files. It is quite conceivable, although this has not been 
 worked out as yet, that the larger displaceable costs of an on-line system will 
 make it competitive with a batch system. Currently, for example, an on-line 
 circulation control system in a large library can be cheaper than a batch 
 system because of the elimination of the massive printouts of circulation lists. 
 
 What is incontrovertible is that the on-line system saves labor compared to 
 the usual batch and manual system. At the lowest level, just bringing the 
 needed information to the worker rather than having the worker physically go 
 and get it can be a very important laborsaver. Studies at the Library of 
 Congress have shown that 60 percent of a cataloger's time is spent walking 
 from his desk to the various files and catalogs, opening the trays or bound 
 volumes, transcribing the information and carrying it back to his desk. 8 
 
 Repeated copying of information is another wasteful operation. At the 
 National Library of Medicine analysts select and index the journal articles and 
 prepare worksheets for the keypunch operators. These clerks transcribe the 
 worksheets and prepare machinable inputs. When the information flows into 
 the computer it is edited and the detected errors, whether originally 
 committed by the indexer or introduced by the transcription clerk, are 
 detected and the record is recycled, usually all the way back to the indexer. 9 
 
 Recycling costs are very high. Even with the MARC program and its use 
 of the MT/ST, which has reduced the error factor at the Library of Congress 
 and has speeded up cataloging, the amount of recycling is still very high and 
 most of this is due to error detection in machine editing and proofreading. On 
 the average it takes three inputs to produce two records at the Library of 
 Congress. Where editing and proofreading are done on-line, the original 
 material is still in hand, and the decisions are still fresh in the librarian's mind, 
 and there is no intervening clerk to introduce additional errors, the amount of 
 labor required is greatly reduced and the time needed for the preparation of 
 the record is shortened. 
 
 Similarly an on-line circulation control system can be a laborsaver. Since 
 each transaction in an on-line circulation control system is essentially an 
 inquiry to validate the legitimacy of the transaction and since all the elements 
 involved in the transaction are present the borrower, the book and the 
 librarian-the snags and conflicts can be readily resolved. In a batch system, 
 the snags show up long after the transaction has been completed and the 
 
12 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 loan has been made. To resolve the problem at that time is often a long and 
 tedious business. In one university library, the on-line circulation control 
 system made it possible to reduce the library's circulation staff from ten to 
 five and even the remaining five had more time to provide other reader 
 services. 
 
 There is one area where on-line systems can add to labor costs. A good 
 on-line system forces the librarian to validate variable information. For 
 example, when order librarians order a book, the system forces them to 
 check the author and title even though in their own mind they are positive 
 that the author and title are not in the library's records. The system also 
 forces them to look at the completed order to be sure that everything is 
 correct. Some are so confident, and some library's operations are so uncompli- 
 cated or at such a low level that such safety controls may be unnecessary and 
 a hindrance to rapid and efficient processing. Some small systems, therefore, 
 dispense with such controls. However, such safety controls are worth their 
 cost, especially in large systems, even though the number of errors caught may 
 be very small. 
 
 Since machine costs are decreasing rapidly and consistently and labor 
 costs are rising rapidly and consistently, savings are ultimately going to be 
 made with the system that will save labor even with an added machine cost. 10 
 In one study of a university library, it was shown that the projected rising 
 labor costs, which included salary rates and increased processing requirements, 
 would provide the necessary displaceable costs for a total library on-line 
 system within five years. The costs of the system were set at today's costs and 
 today's efficiencies. There was no consideration of any potential improvement 
 in the system or the lowering of machine costs. In this instance, although 
 there would be added costs for a number of years, the total system costs of 
 the on-line system would in five years be less than the projected current 
 system. 
 
 One can speak blithely of future costs, but the credibility of such figures 
 seems to rest mainly not on any empirical evidence but rather on the basic 
 attitudes of the individuals concerned. A few basic points should be made to 
 support the contention that the developing on-line, interactive systems will be 
 cheaper per operation while manual and machine batch systems will be more 
 expensive. 
 
 One argument has already been made: that labor costs are rising steadily. 
 In libraries they are rising at the rate of 10 percent per year. Data processing 
 machine costs are dropping. Typical of any new technology that is past 
 recouping the initial development costs, the cost decreases have been 
 spectacular and will undoubtedly slow up in time. The rising operating costs 
 are posing a real threat to libraries, for society is beginning to show signs of 
 unwillingness to support libraries. When properly applied, machine systems can 
 effectively perform many of the library's tasks and perform them more 
 cheaply. 
 
ON-LINE INTERACTIVE SYSTEMS 13 
 
 A few examples will be given of what is meant by "properly applied." 
 There is a learning curve when a new system is installed. Once a new system 
 becomes operational, one learns not only how to improve the system but how 
 to improve one's skill in using it. Typically, in one interactive library system 
 the operators could chain commands and institute default operations. The 
 order librarian wants to examine an author entry to determine the correctness 
 of the order information. The step-by-step procedure would be to first select 
 the function to be performed, in this case, file review. From the file review 
 list the index to be reviewed will be selected. In this case it is the author list. 
 From this list the segment that contains the author's name will be examined. 
 All this would involve a minimum of four steps with three displays. The first 
 three steps can be eliminated along with two of the displays simply by 
 chaining the commands which would bring forth the last two displays. Skillful 
 experienced order librarians can chain a dozen or more commands each 
 command is a single letter or digit and involves only one keystroke; three or 
 four commands can be routinely chained. 
 
 In addition to this command chaining, the operator can accept "by 
 default" prestored information. For example, all the standard data stored in 
 the file of the selected vendor can be accepted. Normal orders are, for 
 example, put on an open or blanket order; ship best way; payment will be 
 made in dollars upon receipt of invoice; and first claims are made in six 
 weeks. None of this need be keyed in with the individual order since it is 
 prerecorded in the vendor file. 1 ! The skill in using command chaining and 
 default options depends on the experience and the ingenuity of the operator. 
 The novice will have to proceed step by step. The experienced, clever librarian 
 will be able to ignore and skip many operational steps and thus produce more 
 with less work. 
 
 Systems also become more efficient as they become more integrated. 
 Operating integrated systems should really be considered as experimental since 
 they have not been applied as yet to the total system for which they have 
 been designed. However, based on experience with such an experimental 
 integrated system, certain conclusions are obvious. A single record can be put 
 to a number of uses and produce a variety of products. The information 
 keyed in to order a book is later used without additional keying by the 
 cataloger to prepare the catalog record, and from that is produced the pocket 
 and spine labels and the circulation card. It is this multiple use of a single 
 input which can make the difference between a profitable and an unprofitable 
 system. 
 
 Integration and multiple use of single inputs is possible not only with 
 on-line systems but, to a certain degree, with batch systems. Actually, trans- 
 ferring a record from application to application in a batch operation, 
 especially when the file is stored on tape and is accessible only in a serial 
 mode, is so clumsy, expensive and impractical that it is better to recreate the 
 record as needed for each separate application. 
 
14 1972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 The design of the Library Management System in Los Gatos was to be the 
 fourth generation of that library's system. The third generation, a partially 
 integrated batch system, was characterized by one of the systems people as a 
 series of high speed highway segments connected by bottlenecks. To achieve 
 any real breakthrough in efficiency, the new system had to work in a totally 
 integrated manner; all information had to be stored as a single logical file 
 accessible to everyone, according to his needs. To achieve this mechanically, 
 the file had to be on-line in a direct access storage device and accessible from 
 terminals. 
 
 Not only is there economy in the production of records but, in having a 
 single logical record, there is economy in utilizing records. Today in machine 
 batch systems and manual systems, when a patron or librarian needs infor- 
 mation about a book, he often has to utilize a number of different tapes or 
 go to a number of different places: the catalog, the book shelves, the 
 circulation file, the on-order file, the in-process file, or a branch or depart- 
 mental library. This weary traveling from department to department to find 
 various files is a fairly common complaint. 
 
 Another requirement for a system to be "properly applied" is that there 
 be enough work for it. There has to be a minimum amount of work -a single 
 threshold if you will to make the system viable. The threshold depends not 
 only on the complexity of the task, but also on quantity. If an expensive 
 machine is idle most of the time, it would be better to have a human do the 
 work even though he may be less efficient. At least he is more versatile and 
 can use his idle time for a variety of tasks. Too often a system is used for a 
 few, often trivial tasks; machines are then misapplied. It is senseless to use an 
 automobile to travel a few hundred yards to perform a simple errand, 
 although it is often done because of laziness, personal convenience or 
 unthinking habit. It is wrong to build an interactive on-line system just to do 
 simple lookup like identifying an author or an entry. If this lookup is part of 
 a larger more complicated process, then it is entirely valid economically. It is 
 only when lookup becomes a more complicated search that the interactive 
 system comes into its own. 
 
 Two growth factors greatly affect the threshold level of a system: (1) the 
 increased growth of the operation itself and (2) the decreased cost of the 
 hardware. Originally data processing and today interactive systems- was 
 adopted primarily by growing and expanding operations. A stagnant or 
 shrinking operation seldom feels any need for adopting new methods and 
 techniques unless, of course, it becomes evident that the stagnation is due to 
 the present inefficient methods. Also, a growing operation will grow into the 
 economic capacity of a machine installation even though it may actually start 
 below the economic threshold. 
 
 As Chief of the Library Branch of the Tedhnical Information Division of 
 the U.S. Atomic Energy Commission (AEC) in Oak Ridge, the quantity of 
 
ON-LINE INTERA CTIVE SYSTEMS 15 
 
 documents I had to process was increasing rapidly and Civil Service would not 
 give me more personnel as the workload increased. Finally, in desperation, I 
 asked for enough money to install some unit record equipment to do the 
 work. I could not reduce staff and the machines would not be utilized for 
 more than an hour or so a day, but I would never ask for any more people. I 
 made a very rash promise twenty years ago, and today, although the amount 
 of library processing put out by the AEC in Oak Ridge has increased 
 manyfold, they have not had to increase manpower and the machine 
 capacities have been more than able to keep pace with the growth in demand. 
 
 As evidence of the decreased cost of the hardware, today, a small 
 computer-and by this I do not mean the little mini-computer but the small 
 general purpose machine that is capable of performing all the basic data 
 processing jobs in the library -rents for the salary equivalent of one to two 
 professional personnel. Seven years ago when library automation first got 
 underway, the least expensive hardware configuration capable of doing the 
 library's work cost ten to fifteen times as much. One should not forget that 
 today's small computer is at least the equal in power, capacity and perfor- 
 mance of that much more expensive machine. In addition to these small 
 stand-alone machines, the increased availability of time-sharing facilities is also 
 lowering the economic threshold to where the smaller libraries can afford to 
 make use of data processing. One also should remember the tremendous 
 potential saving that is possible by using shared data bases. Until on-line 
 systems are utilized, such sharing cannot be fully exploited. 
 
 Looking at the total operating costs of the library, it appears that data 
 processing, when properly applied, will either reduce costs or slow down the 
 present rapid rise in processing costs. On-line interactive systems will be the 
 preferred method for a number of applications both because of the economics 
 of the situation and because of the inherent needs of the application. 
 
 APPLICATIONS 
 
 One could spend an appreciable amount of time defining interactive systems 
 based on level of communication. There is simple remote job entry or 
 one-way communication. Typical examples are placing a hold on a book or 
 recommending a new acquisition. At a higher level is two-way communication 
 in a prescribed format. Examples of this might be placing an order with a 
 vendor with a system check for duplicates or checking an authority file for 
 correctness of entry. At the highest level a system might provide fully 
 unstructured conversation. 
 
 Based on available descriptions of both library and non-library systems, 
 one can extract those elements of an application which strongly influence a 
 user to select on-line, interactive processing. Some of these elements have been 
 
16 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 mentioned already, but they bear repeating. One is the need to transport the 
 information directly to the user so that he will not have to spend time and 
 energy going to the various sources. Librarians have recognized this problem in 
 designing their workrooms and in locating the official catalog, the shelflist, the 
 serials check-in files, etc. It is an accepted idea that library processing people 
 must go to the various catalogs and files. Many workers develop their own 
 little card files, indexes, authority lists and other working tools for con- 
 venience, to save time, to avoid walking to distant cabinets and shelves, and to 
 avoid waiting in a queue while someone else is using the file or book. When 
 the information is brought to the individual immediately as needed, and there 
 is never a conflict or out-of-file situation as exists in manual files, then the 
 productivity of the workers is greatly increased. Some have argued that 
 physically going for information is a good distraction and breaks the 
 monotony of the job. But such arguments are mostly rationalizations, 
 certainly in the library. 
 
 On the input side, a good on-line system eliminates the intermediary 
 transcriber clerk, usually a keypunch operator or typist. One does not need a 
 separate operation to update the file. The originator of the information -the 
 order librarian, the cataloger, the patron or clerk charging a book or dis- 
 charging a loan, etc. in creating the information is immediately creating the 
 record and storing it. No new errors are introduced by a transcription clerk or 
 by a defective work sheet. If any problems develop and if any proofreading or 
 correction is required, this is done immediately by the person who has just 
 created the record and who has all the pertinent information and materials at 
 hand. Furthermore, experience has shown that there are fewer errors when the 
 data is entered by the person familiar with it rather than by a keypunch 
 operator. 
 
 Since the system is on-line, the normal editing by the computer can be 
 accomplished immediately and the creator of the record can immediately take 
 the necessary action. This adds up to faster turnaround time, faster and 
 greater throughput. Mention has already been made of the large amount of 
 recycling or looping back which is currently necessary in the MARC program. 
 Figures are not available for the National Library of Medicine Index Medicus 
 program or for other abstracting/indexing services, but all connected with such 
 operations have complained about the burdens of double processing. 
 
 This recycling or looping back is due to the fact that the error is detected 
 long after the transaction has been completed. As noted, in an on-line system 
 each transaction is an inquiry which must be answered before the transaction 
 is completed. In a batch system, the inquiry comes after the transaction has 
 been completed and the parties concerned are either not present, as with a 
 book loan, or the material has gone and the person involved is engaged in a 
 new task, as in cataloging and ordering. As a result, more controls have to be 
 built into a batch system than are necessary with an on-line system. In some 
 
ON-LINE INTERA C77 VE SYSTEMS 1 7 
 
 libraries the loan clerk may have to verify that the patron is a legitimate 
 borrower and the book may be charged out. The cataloger may check the 
 authority lists for every entry and verify every field, even though subsequently 
 these may be machine-editing functions. The order librarian will carefully fill 
 in all the boxes on the order form even though a large number of them carry 
 default information such as method of payment, method of shipment, claim 
 cycle and the like, simply because she is not absolutely sure what the stored 
 default information is. In a good on-line system the completed order, 
 including the default information which did not have to be manually entered, 
 is displayed for verification and acceptance before final processing. 
 
 On-line processing guarantees the currency of records. The moment a 
 record is created and stored, it is available to every inquirer. As soon as a 
 journal issue is checked in, an order recorded, a book cataloged, or a loan 
 discharged, that information is immediately available to everyone. There is no 
 librarian in existence who has not, on many occasions, spent long frustrating 
 hours trying to determine the status of an item. Most of this is due to the 
 fact that the record is not available until long after the event. 
 
 Currency of information is of overriding importance in many commercial 
 applications. That is why so many credit and banking applications, insurance 
 processing, airline reservations and the like were pioneers and moved rapidly 
 to on-line systems. Such urgency may not exist in librarianship, but it should 
 if libraries are to have satisfied patrons. Too often the acceptance of delays in 
 making information available and the difficulty in obtaining it reduce the 
 utilization of such information and so reduce the use of the library. Further- 
 more there is little incentive to maintain such records. A case in point is 
 serials holdings records. When its serials holdings records are first published, it 
 is not unusual for a library to experience a 20 percent increase in the use of 
 periodicals. It is often also startling and amusing to discover how bad the old 
 card file of serial records are and how rapidly they are cleaned up and 
 updated when they become highly visible in published form. In fact, the most 
 difficult problem in building a computerized serials list is cleaning up the old 
 card file. The bad record is usually not due to the fact that the information 
 was not available, but simply because changing the record involved a lot of 
 work and there were higher priority jobs demanding the librarian's or clerk's 
 time. So at the most, a note may have been made which might act as a 
 reminder. 1 2 
 
 As already mentioned, the ability to obtain current information very 
 quickly in an on-line system does away with the need for maintaining 
 expensive paper files. Yet, since we have always had them, they are given up 
 with great reluctance. When the RAMAC was first introduced and used for 
 inventory control, the information was processed and stored in the machine, 
 but the records that were consulted by the users were printouts. It took some 
 time for people to give up their cherished lists and card files and go directly 
 
18 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 to the computer which produced these lists and cards. Too often batch 
 systems are nothing more than a new method for maintaining manual files and 
 sometimes on-line systems are added on top of existing manual systems rather 
 than eliminating the latter. This of course makes for very expensive 
 operations. This is to be expected in new systems because of lack of 
 confidence in the new and familiarity with the old. What is unforgivable is the 
 continuation of the old beyond the minimum conversion period. 
 
 An interactive, on-line mode of operation is much more comfortable for 
 the worker than a batch mode because there is no need to break up tasks to fit 
 the batch. If it is better and more convenient, for example, to completely 
 process an item before tackling the next job, even though it requires a variety 
 of tasks, it can be done with the interactive on-line system. The batch system 
 is most efficient when it groups a large number of items for a single task or a 
 small number of operations. This can mean, for example, that the cataloger 
 may have to handle the same book more than once. People find it distracting 
 and confusing to handle many different items in a single batch. There is the 
 problem of broken continuity of thought and the problem of remembering. 
 
 One must admit that the efficiency of some catalogers would be improved 
 if they did a little more batching. However, the mere fact that the batch 
 mode is essentially a procrustean bed, inevitably forces the human to 
 accommodate himself to the machine, which can be undesirable. In an inter- 
 active system the user can shape the application program to suit his require- 
 ments as in command chaining, variable file access, choosing different 
 functions, etc. In essence, the human controls the order and sequence of 
 events, not the machine. The system is said to be user oriented. A batch 
 program, however, is absolutely rigid. Although it may be able to turn out a 
 great variety of individual, customized products, the operational sequences are 
 programmed and unchangeable. A good interactive system should not have 
 any of the dehumanizing aspects that too often characterize our big, industrial 
 society. 
 
 At this clinic there is understandably no example of an on-line, interactive 
 reference system. The only ones that exist in libraries are for certain 
 specialties, are experimental or are confined to limited collections. The 
 machine-readable files of large, general collections have not yet been built. 
 These are necessary before truly adequate reference work can be performed. 
 The search and retrieval functions that do exist for general collections are* 
 used entirely to support the various technical processing functions in the 
 library. 
 
 The major research on interactive, on-line systems involve search and 
 retrieval functions. It seems that this is the main interest of information 
 science; it is certainly the dominant theme in that literature. This clinic 
 restricted itself to the immediate problems of librarians, deferring for possible 
 future consideration all the topics associated with reference work, while 
 
ON-LINE INTERACTIVE SYSTEMS 19 
 
 recognizing that much of the original impetus to adopt interactive, on-line 
 systems was to improve search and retrieval. I will, therefore, mention only a 
 single aspect of the search techniques possible with on-line systems since it has 
 a profound effect on library technical processing. 
 
 The computer can dynamically organize and structure files. By the use of 
 Boolean operators or multiple access points, it can organize lists and com- 
 pilations extracted from the data base in many different sequences and with 
 various populations. In a manual system this is not possible since everything is 
 filed in a single sequence. For example, to receive a book, the user must 
 search the outstanding order file. To search the file to answer an inquiry 
 about the item, the user must know the entry which is used to sequence the 
 file. If the original entry is incorrect, which happens frequently, or if the 
 original inquiry does not have all the necessary information, then the user will 
 have difficulty in generating an entry compatible with the file entry. The 
 mark of a good receiving clerk is his ingenuity in solving such snags. A good 
 on-line system provides multiple access points, not only from the individual 
 fields on the order author, editor, publisher, vendor but also includes fully 
 permuted titles and corporate authors. The availability of any one of these 
 single clues is sufficient to retrieve the record. In addition, even partial clues 
 using indeterminate search keys such as truncated and compacted terms to 
 find authors, titles, etc., when coupled with the browsing capabilities made 
 possible by the display terminal, greatly improves our searching capabilities 
 beyond anything in the past. 
 
 These search strategy capabilities can, in part, exist in a batch system but 
 their utilization is much more restricted and awkward. The user, for example, 
 can submit a query in various different arrangements and then look at the 
 various printouts to see which was the lucky one. Or the user could go 
 through a series of search strategies until he or she is satisfied, but in every 
 case he or she must wait for a completed search before trying a new search 
 strategy. In an on-line system, by seeing what intermediate results are, one can 
 carry out this exploration quickly and efficiently modifying the search as he 
 or she picks up clues, scans lists, etc. There is a proper division between the 
 intellectual processes which the human does and the mechanical processes 
 which the machine does. This is the essence of interactive processing. 
 
 Another example is indexing. The present arguments between machine 
 indexing and human indexing should really not take place. Rather, one should 
 examine very closely what aspects of machine indexing can be integrated with 
 human indexing to generate the best index possible. This is a topic which 
 cannot be covered at this clinic. The exploitation of the interplay between 
 what the machine can do and what the human can do is what will really 
 advance the state of library technology. Format recognition as exemplified by 
 the current RECON project will only be really successful in an on-line 
 interactive mode. 
 
20 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 Obviously, successful library systems of the future will be hybrid systems, 
 partially manual, partially batch and partially on-line. Data processing people 
 are trying to build the best possible operating system for the library, and they 
 are going to make use of many different technologies and a great variety of 
 systems. 
 
 Interactive use of stored communicable and dynamic data bases will 
 undoubtedly have a profound effect on the role of the library in our rapidly 
 changing bibliographic world. For example, on-line systems being developed in 
 business and industry are tending toward the building of large, central, 
 integrated facilities. In the library this will mean everyone having access to 
 large, shared data bases like union catalogs and massive inputs, like MARC 
 outputs, now available only to a very few large libraries. This does not inhibit 
 the development of small, stand-alone systems that perform all the local 
 tasks such as circulation control, periodical check-in, and binding control. 
 Librarians should ask themselves how having what is sometime referred to as a 
 computer utility will affect libraries. 
 
 Another subject for speculation is the suspicion that the successful 
 exploitation of retrieval systems and the widespread use of libraries as sources 
 of information will come primarily not because of any improvement in 
 indexing and retrieval methods, but because getting the needed information 
 will be made convenient and easy. When the library terminal becomes as 
 ubiquitous as the telephone, libraries are going to play a much larger role in 
 information processing and transmission. 
 
 An even more radical idea is that as interactive systems open the door to 
 new forms of information storage and information transfer, some people are 
 talking about the abolition of all hard copy. Potentially the librarian might 
 have little concern with books, periodicals and other printed matter. 
 
 It is tempting to speculate as new tools open up opportunities for new 
 methodologies and services. But in view of the real interests of this clinic's 
 participants, this presentation has been kept to mundane, immediate and 
 practical topics. Library technology is moving in the direction of on-line, 
 interactive processing and it is important that it be done well. 
 
 REFERENCES 
 
 1. Meadow, Charles T. Man-Machine Communication. New York, Wiley- 
 Interscience, 1970, pp. 7-10. 
 
 2. Skolnik, Herman, and Jenkins, William L. "Evaluation of the IBM 
 Administrative Terminal System and Magnetic Tape Selectric Typewriter for 
 Text Processing" Journal of Chemical Documentation, 11:170-73, Aug. 1971. 
 
ON -LINE INTERACTIVE SYSTEMS 21 
 
 3. Swanson, Gerald L. Selected Statistics Based on L.C. MARC Biblio- 
 graphic Records. Cumulated Statistics for Vol. 1, Nos. 1-54, March 
 1969-March 1970. Systems Office, Columbia University Libraries, Technical 
 Note No. 2, Sept. 1970. See also: Fasana, Paul J. Utilization of MARC Data 
 in the Columbia Automated Technical Services System. Systems Office, 
 Columbia University Libraries. Technical Note No. 1 (Revised), Nov. 1970. 
 
 4. King, Gilbert W., et al. Automation and the Library of Congress. 
 Washington, D.C., Library of Congress, 1963, pp. 19, 54-72. 
 
 5. Fussier, Herman H. "The University of Chicago Library Automation 
 Project." In Allen B. Veaner and Paul J. Fasana, eds. Stanford Conference on 
 Collaborative Library Systems Development: Proceedings . . . October 4-5, 
 1968. Stanford University Libraries, 1969, p. 18. 
 
 6. Alexander, R.W. Library Management System (LMS): Descriptive 
 Specifications for an On-Line, Real-Time Integrated Library System. Los 
 Gatos, Calif., IBM Advanced Systems Development Division, Laboratory 
 Report 16.196, Sept. 20, 1969; and Alexander, R.W. "Toward the Future 
 Integrated Library System," 33rd Conference of FID and International 
 Congress on Documentation (Abstract No. Ill 64). Tokyo, International 
 Federation for Documentation, 1967. 
 
 7. Information Systems Panel. Computer Science and Engineering Board. 
 National Academy of Sciences. Libraries and Information Technology -A 
 National System Challenge (A Report to the Council on Library Resources, 
 Inc.). Washington, D.C., National Academy of Sciences, 1972. 
 
 8. King, op. cit., p. 80 
 
 9. Warheit, I. A. "Design of Library Systems for Implementation with 
 Interactive Computers," Journal of Library Automation, 3:65-78, March 1970. 
 
 10. Warheit, I. A. "The Automation of Libraries; Some Economic Con- 
 siderations," Special Libraries, 63:1-7, Jan. 1972; and Kilgour, Frederick. 
 "Evolving, Computerizing, Personalizing," American Libraries, 3:141-48, Feb. 
 1972. 
 
 1 1 . McAllister, Caryl, and Bell, John M. "Human Factors in the Design 
 of an Interactive Library System," Journal of the American Society for 
 Information Science, 22:96-104, March 1971. 
 
 12. Verity, John B. Automated Serial Records: An Oblique Look at the 
 State of the Art (UCRL-71729). Livermore, University of California, Lawrence 
 Radiation Laboratory, 1969; and Library Automation-Computerized Serials 
 Control (GE20-0352). White Plains, N.Y., IBM, 1971. 
 
HUGH C. ATKINSON 
 
 Director of Libraries 
 
 The Ohio State University 
 
 Columbus, Ohio 
 
 The Ohio State On-Line 
 Circulation System 
 
 The Ohio State University (OSU) Libraries is a network of approximately 
 twenty-three department libraries and the main library. The number is 
 approximate because the question of which libraries classify as department 
 libraries presents some problems. For instance, Ohio State University has a 
 library on Gibraltar Island in the middle of Lake Erie, accessible only by boat, 
 and open only during the summer months. It is, in fact, a subbranch of the 
 Biological Sciences Library and is not counted as one of the twenty-three 
 department libraries. The library in Perkins Observatory in Delaware, Ohio, is 
 counted in the twenty-three department libraries, as is the library at Children's 
 Hospital. There are certain libraries on the campus which are not a part of the 
 university libraries system. The Law Library lists its material within the 
 system, but does not have a terminal and does not use the system for charging 
 or for access, but purely for information. Privately endowed libraries and 
 libraries supported by certain departments such as the English Department 
 Library and the Philosophy Library, which are primarily libraries for under- 
 graduate reserve reading, are neither part of the university libraries system, nor 
 are they under the jurisdiction of the libraries. 
 
 The library system contains approximately 2,500,000 volumes. The 
 acquisition f cataloging, and serial recording are done centrally and the finishefl 
 items are then sent to the various public service units. In 1972 the libraries 
 will circulate approximately 1,500,000 volumes. They will purchase some 
 120,000 volumes and on a busy day 20,000 patrons may enter one of the 
 libraries within the system. The campus is large and decentralized and the 
 distance from the Veterinary Medicine Library to the Education or Commerce 
 Libraries is well over two miles. The libraries serve approximately 70,000 
 patrons, as listed in the patron name and address file. 
 
OHIO STA TE ON-LINE CIRCULA TION S YSTEM 23 
 
 During the 1960s the Ohio State University Libraries became increasingly 
 aware that library circulation was not increasing at the same rate that enroll- 
 ment was. The analysis of this phenomenon seemed to demonstrate that the 
 system itself was clogged, that is, the procedures that had been evolved over 
 the previous century were insufficient to meet the demands and load level 
 that the increased size of the institution was placing on the library. Newer 
 methods of teaching and research were also placing heavier demands on the 
 libraries. 
 
 To simply expand the staff and the concomitant files and checkout desks 
 seemed to be both inappropriate and unlikely to receive funding from the 
 University budget authority. Furthermore, due to inflation, the costs of 
 personnel were rising at an enormous rate. The libraries therefore decided to 
 design an automated circulation system in order to recapture some of the lost 
 circulation and to provide a system which would be expandable in the future 
 at minimal cost. As the requirements for the system were designed it became 
 clear that the system should be one which would speak to the problems of its 
 users rather than simply the problems of the library. The most common user 
 complaint arose from attempts to borrow materials from the library only to 
 discover that the materials were either not owned by the library or were 
 checked out. Another common complaint was that to locate a spectrum of 
 materials on such a large campus and in a library situation which was fairly 
 decentralized was a frustrating and time-consuming operation; a trip from the 
 main library where the union catalog (wherein all the books on the campus 
 are listed) is located, to another library would often prove fruitless since the 
 materials were either checked out or the patron had gone to the wrong 
 library. 
 
 Although materials were available to patrons if they would go to the right 
 library, people would often not try all the possible alternatives of libraries 
 where a copy might be located when they discovered the copy located in the 
 particular library they were using was out. Therefore, rather than a system 
 which would keep records of "books out" only, it was decided that full 
 inventory control was needed. Furthermore, we felt that we must design a 
 system which would provide for remote access and the ability to display all of 
 the libraries holdings at any of the libraries' many locations as a basis for 
 sharing of resources rather than a buildup of duplicate libraries. A fair amount 
 of duplication is necessary in a campus of the size of Ohio State University, 
 but it was hoped that in the future one department library could forego the 
 purchase of little-used material if another library on the campus had the 
 material available and it was readily accessible by a patron in the first 
 location. This kind of cooperation is just beginning and should increase in the 
 future. 
 
 The next problem was the amount of data needed on the file in order to 
 satisfy a large portion of the patrons' demands. At about the same time that 
 
24 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 Ben-Ami Lipetz at Yale completed his studies on card catalog use in a major 
 academic library, his findings were verified by findings at the University of 
 Michigan which pointed to the fact that about 80 percent of the patrons who 
 enter a library know the items they want and they are engaged in a known 
 item search. Of the remaining 20 percent, a fair proportion are engaged in a 
 subject search, and the others are engaged in a search by series, for a group of 
 documents, or for bibliographic information only. 
 
 With this information at hand it was decided that the system should 
 involve an author-title and title search capability, but not subject search 
 capability. There are so many unanswered questions about the "subject search 
 process" that data are still being amassed about it. The university then selected 
 the IBM Corporation to draw up the functional specifications for the system and 
 to program the remote access and circulation system. This required 5 men for 
 15 months or 75 man-months, costing $225,000. A vendor was selected to 
 convert the library records. Records include: the call number, author, title, LC 
 card number (in case subject information was added later, a link would be 
 needed to other bibliographic records produced at other institutions), an 
 internal identification number or title number, date of publication, a tag 
 designating the item to be English or non-English or serial or monograph, and 
 the holdings that is, the volumes and copies of the particular title and where 
 they are held. The average master file record is 100 characters in length. The 
 OSU Libraries use the Library of Congress classification scheme with certain 
 exceptions. The Education Library's juvenile collection is Dewey Decimal, the 
 theses and dissertations are in a arbitrary sequential number contrived from 
 the author's last name as well as the year and level of thesis. Microforms use 
 simple sequential numbers and the Law Library uses another classification. 
 Thus we have a mix of call numbers which demands a free and variable length 
 field containing both numerical and alphabetical characters. The programs 
 themselves are formed in approximately ninety-four separate modules and at 
 any one time demand 186Kof core of the IBM model 360/50. The "Fifty" 
 seems to be the smallest machine which has the necessary channel speeds for 
 the system. The system has approximately thirty 2740 typewriter terminals 
 and approximately ten 2260 CRTs (fig. 1). The patron may telephone and 
 request a search by author-title, by title, or by call number, and the library 
 can respond as to whether the libraries owns the items, whether it is charged 
 out, and in which library it is housed. It can also charge the book to the 
 patron if he has a valid identification number. The system carries approxi- 
 mately 70,000 names and addresses with corresponding identification numbers 
 as well as 1,000,000 titles comprising 2,500,000 volumes. Books may also be 
 renewed by telephone. If a patron comes to a circulation desk with a book in 
 hand, rather than do a search, the book can be charged by simply typing the 
 call number and the patron identification number at that keyboard and the 
 machine will respond with the author, title, date due, and date charged on a 
 
OHIO STA TE ON-LINE CIRCULA TION SYSTEM 
 
 25 
 
 Fig. 1. Hard ware 
 
 slip of paper which can then be inserted into the book. On a remote charge 
 the same data appears in the library where the book is located; the book is 
 paged and awaiting the patron when he arrives at the circulation desk. 
 
 Any library can charge any other library's books, but only the home 
 library can discharge books. The discharge routine is similar to the charge 
 routine except that the patron's identification number is not needed. Thus, 
 the stock of each unit is protected and controlled by the discharge routine. 
 The machine automatically generates "holds" or "saves," "recalls" from 
 faculty members for books that have been out more than three weeks when 
 requested by a student or other patron, and provides a lists of "snags," that 
 is, books not on the shelf and not charged out which are searched to see if 
 
26 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 they are misshelved or some other error has occurred. Bills for "lost" books 
 or accumulated fines are also generated by the system. 
 
 The system was first started in November of 1970. Circulation has risen 
 over 40 percent in the eighteen months the system has been operating. With 
 the rises in wages, circulation costs are now about the same as before 
 installation of the system, about $0.43 or $0.44 per circulation. About 
 one-half of the circulation is still done manually almost all of this is from the 
 reserve rooms, since the old system of writing one's name on the end of a 
 long card is still faster for controlled access materials than keyboarding. The 
 university does not have a machine-readable identification card. If such an 
 identification card is issued, manual circulation for reserve materials will be 
 switched to the 1050 terminal or some other terminal which can read both a 
 Hollerith card and the borrower badge in a very short time. The library 
 encouraged the university to switch to such a machine-readable identification 
 card and it appears that some action may soon be forthcoming. 
 
 In January of 1973 an automated acquisition and serial system will be 
 initiated. Much of this data will reside in the Ohio College Library Center's 
 Sigma 5 XDS machine, but will utilize the OSU Libraries' terminal system and 
 circulation system. In essence an acquisition will be dealt with in the same 
 way a circulation is dealt with; i.e., it will be treated as a book that some- 
 one has checked out of the stacks which must be returned; much in the same 
 way that someone who has charged the book owes the library a book. In 
 effect we will create a record on the file and charge it to a vendor with a 
 date due, just as if he were a patron. It will display on the system with 
 perhaps a prefix "V" for vendor identification number and a date due. The 
 vendor, if he does not supply by the date due, will receive an overdue notice, 
 only we will call it a "claim." To a patron or a user of the system the books 
 on order will look the same as the books already owned by the library except 
 that rather than a call number, an order number or an invoice number will 
 appear. A book may be reserved when it comes back from a patron even if 
 the patron is a vendor. The libraries will then be able to circulate uncataloged 
 books and defer cataloging for items which are needed immediately until after 
 the initial use. The system has the ability to expand to 200 to 300 terminals 
 before degrading the response time. 
 
 Some of the more interesting phenomena that we had not realized when 
 we did the original design and programming are: 
 
 1. On-line systems should, in fact, have on-line maintenance. We had antici- 
 pated that batch maintenance would be the most efficient and easiest 
 method of updating the system. This is simply not true. When a system is 
 running as many hours as ours is, it becomes feasible to "time-slice" and 
 do maintenance routines in between circulation transactions. The batch 
 routines take an enormous amount of time at least once a week, and do 
 not have the instantaneous need for updating that an on-line system does. 
 
OHIO STA TE ON-LINE CIRCULA TION SYSTEM 27 
 
 The process of backing up the system, doing the batch maintenance, and 
 then re-backing up the new file is extremely expensive and time- 
 consuming. It is not in any way cheaper or more efficient than an on-line 
 system. We hope to have the on-line programming finished by August 
 1972 so that we can stop doing batch processing of updates. We now have 
 the ability to maintain the name and address file on-line, but the master 
 file of books and journals is far more complex; there are problems such as 
 identifying or holding from maintenance the change to records of books 
 which are in circulation. 
 
 2. We had set up the on-line system believing that some of the smaller 
 department libraries could share lines into the computer. This proved to 
 be untrue queuing problems quickly occurred and soon became intoler- 
 able. Furthermore, we discovered a large amount of unforeseen traffic of 
 department libraries searching for added copies or added editions of 
 materials held in those libraries, but which were either checked out or not 
 available at the moment. The interdepartmental traffic is a very large 
 portion of the total system traffic. 
 
 3. We discovered that certain kinds of unforeseen reference operations have 
 played an important part in the reference services using the computer. 
 The checking of standard reference books, especially bibliographies, for 
 those items which we hold is now being done on a large scale. The 
 reference librarians use the terminal provided in the reference department 
 not only for such housekeeping routines as charging to themselves the 
 latest volume of those series labeled "latest volume in Reference," but 
 also for answering catalog information questions. Since so much of 
 reference work is the matching of bibliographic sources against library 
 holdings, there is extensive use of the terminal in that department, 
 although very little actual "charging" and "discharging" is performed. 
 
 4. We are beginning to be able to limit the number of duplicate copies being 
 provided in the system since all of the copies of a book are available 
 throughout the system. We are not forcing this particular issue, but are 
 discovering a tendency among the various department librarians to 
 "stretch" their book budgets by cutting down on the duplication of 
 material that is used heavily a few times a year, but sits idle the rest of 
 the year. 
 
 5. We are exploring the possibility of using the system as a sort of sub- 
 standard cataloging by providing limited entries on a permanent basis for 
 the kinds of materials that are duplicated in many copies-sometimes 
 hundreds of copies-for the History 101 courses, for general under- 
 graduate reading, and for the browsing room. No definite decisions have 
 come from this, but we have received the recommendation that added 
 copies of popular items be listed only in the computer and never fully 
 cataloged. 
 
28 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 The system also sends certain statistical reports to the library as well as 
 purchase alerts to the acquisition department for items for which there are 
 more than two "saves" and reduces the circulation period to one week for all 
 books when more than three "saves" are present on a given title. We expect 
 that the circulation will continue to increase, and by displaying the on-order 
 file with the circulation file, we will be able for the first time to have full 
 control of the materials both on the shelves and in the pipeline to those 
 shelves. 
 
LARRY AULD 
 
 Head, Technical Services 
 and 
 
 ROBERT BAKER 
 
 Information Analyst 
 
 Oregon State University Library 
 
 Corvallis, Oregon 
 
 LOLITA: An On-Line Book Order and 
 Fund Accounting System 
 
 LOLITA is the project name for the on-line book order and fund accounting 
 system developed by the Oregon State University Library and used since 
 mid-March 1970. Although designed primarily to handle monograph orders, 
 serials and binding are included in the fund accounting portion. This paper 
 will discuss approximately two years of production work with LOLITA: the 
 changes in the work load caused by LOLITA, the effects on the overall 
 acquisitions program, program revisions, and operating costs. The overall 
 design philosophy, record formats, and on-line processing of these records 
 were detailed in "On-Line Acquisitions by LOLITA" by Spigai and Mahan. 1 
 Additional detail, particularly in regard to fund accounting was described in 
 "LOLITA: An On-Line Demonstration" by Baker et a/. 2 
 
 The Oregon State University Computer Center has a CDC 3300 computer 
 which is operated under OS-3, a locally developed timesharing system serving 
 a network of remote terminals around the state of Oregon. Depending upon 
 the nature of the computing work being done by individuals, the system can 
 support in excess of sixty concurrent users. System reliability bcfth in terms 
 of hardware and software, is excellent: downtime is measured in hours per 
 month. 
 
 The name LOLITA was chosen for its acronymous value, standing for 
 Library On-Line /nformation and Text Access. Although we like to think of 
 the promise for the future the project name holds, we sometimes agree with 
 
30 
 
 1 9 72 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 Fig 1. Flow Chart of LOLITA 
 
 Frederick Kilgour who suggests that, in his view, LOLITA is "a dangerous 
 name, replete with suggestion." 
 
 In LOLITA one can see a near fusion of technology and Robert Graves's 
 White Goddess. LOLITA is oriented to the service of humanity: wherever 
 possible LOLITA accommodates people rather than requiring that people 
 accommodate the machine. Robert Graves's Seven Days in New Crete 3 
 describes a sort of Utopia in which the Goddess is supreme and all technology 
 denied. But the climax of the story includes an admission that knowledge and 
 technology are not evil in themselves but only according to the purposes to 
 which they are put. A humane use of the machine, such as we believe 
 LOLITA to be, is acceptable to the Goddess. 
 
 Fig. 1 is a simplified flow chart illustrating the major functions of 
 LOLITA. The files on which LOLITA depends include on-order/in-process, 
 vendor, and fund accounting. 
 
ON-LINE ORDER AND FUND ACCOUNTING 31 
 
 Certain operations are oriented to a cathode ray tube (CRT) terminal; the 
 on-order/in-process file can be searched by purchase order number or author. 
 New orders are input and automatically indexed on a daily basis. Invoice data 
 are added to records or, for serials, standing orders, and binding, set up in a 
 separate file, again on a daily basis. Finally, the catalog updating (addition of 
 call number, corrected main entry and title, and other changes) is also done 
 on a daily basis. 
 
 Other functions, particularly where a paper document as an audit trail is 
 desirable, are oriented to a Teletype terminal; periodically on demand, but 
 normally once or twice a week, purchase orders are prepared for printing. As 
 the purchase orders are prepared, the fund accounting and vendor files are 
 updated both in terms of new orders issued and invoices processed. Purchase 
 order, invoice, and fund accounting statements are automatic by-products. The 
 vendor file, which includes cumulative counters for frequency and dollar 
 amounts for each vendor, can be accessed at any time for display and 
 maintenance (updating, correction, additions, deletions) or a complete listing 
 can be produced on the line printer. The fund accounts are readily accessible 
 on-line on demand so that the current status of each budget line item and 
 each subject category is always available. Summary statements for all fund 
 accounting can be produced on the line printer by command from the 
 Teletype. A special program for entering new fund allocations, corrections, and 
 transfers is also available to authorized personnel. 
 
 The book, serial, and binding budget for the Oregon State University 
 Library varies from year to year. Encumbrance accounting is used, and funds 
 committed to cover a given purchase order may be carried forward into the 
 new fiscal year; while these so-called outstanding funds are not really part of 
 the current year's budget, they do constitute a part of the acquisitions work 
 load. Budget figures for four fiscal years, from pre-LOLITA to the present, are 
 shown in table 1. Note that the figures for 1971/72 new funds are an 
 allocation; the final year-end figure could be higher (or lower). Also included 
 in table 1 are the catalog statistics for volumes and titles added during the 
 same time period. Incidentally, a major portion of the monograph funds for 
 1970/71 were not made available to the library until the final months of the 
 year: many of the items ordered were not received until 1971/72. Thus, the 
 flow of new materials coming to the catalog department is uneven; however, 
 the department is operating without a backlog. 
 
 LOLITA's Effects on Staff 
 
 The acquisitions staff has remained stable in size over the last four years so 
 that the number of persons doing acquisitions work before and after LOLITA 
 is the same. The full-time employee equivalent is eight; the number of 
 full-time student assistants is two. Acquisitions work includes: coordination of 
 
32 
 
 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 New funds 
 including 
 gifts 
 
 1968/69 
 
 1969/70 
 
 1970/71 
 
 1971/72 
 (est.) 
 
 $367,346.34 
 
 385,668.65 
 
 406,221.36 
 
 (375,918.00 
 
 Outstanding 
 funds carried 
 forward 
 
 33,036.06 
 
 28,284.71 
 
 28,031.65 
 
 76,019.42 
 
 Total 
 
 396,782.40 
 
 413,953.36 
 
 434,253.01 
 
 451,937.42 
 
 Volumes 
 cataloged 
 (gross) 
 
 32,082 
 
 31,701 
 
 29,580 
 
 32,000 
 
 Titles 
 cataloged 
 (gross) 
 
 14,206 
 
 15,105 
 
 10,738 
 
 14,500 
 
 Table 1 . Budget and Cataloging Workload 
 
 collection development, preorder searching, gifts and exchanges, issuance of 
 purchase orders, receipt of materials, and invoice processing along with the 
 normal complement of correspondence, claims, snags, incorrectly mailed 
 packages, and visiting sales representatives. A separate serials control unit for 
 which the full-time equivalent (FTE) is not included in acquisitions receives 
 serials and handles most serial claims; however, processing serial invoices is a 
 part of acquisitions. 
 
 Although staff has not been reduced as a result of LOLITA, there have 
 been significant changes in the work performed. Some of the changes are a 
 direct result of LOLITA; others reflect organizational changes, some of which 
 could not have been done without LOLITA. 
 
 The total book, serial, and binding budget has grown (see table 1) but, 
 with inflation, the effective increase in terms of purchasing power is not great. 
 
 The serials control staff has not grown during the past four years even 
 though the number of subscriptions received has increased by approximately 
 13 percent. (Serial titles including duplicate copies-received as of July 1, 
 1968 were 13,554; by October 1971, the number had reached 15,285, an 
 increase of more than 1 ,700 titles.) Since additional serials staff could not be 
 obtained it was necessary to reassign certain tasks in order to reduce the work 
 load in serials control. Bibliographic searching of new serial titles is now 
 performed in acquisitions; gifts of serials, which often show up by the box 
 load, are now handled by acquisitions. 
 
ON-LINE ORDER AND FUND ACCOUNTING 33 
 
 LOLITA produces a unique four-part purchase order for each title 
 ordered. The fourth copy is used as a work slip in the catalog department. 
 Before LOLITA, acquisitions spent more than eight hours per week typing 
 special cataloging work slips, one for each title. The one-fifth FTE savings 
 created by eliminating the hand typed work s'ips is a direct result of LOLITA. 
 
 A further savings is in the catalog department where, formerly, Oregon 
 State System of Higher Education rules required that bill data (invoice date, 
 vendor name, price, fund name) be typed on the shelf list card. Since 
 LOLITA assigns a unique purchase order number to each title, the catalog 
 department now types only the purchase order number and price (rounded off 
 to whole dollars) on the master card. There is a definite savings in labor plus a 
 significant improvement in the audit trail which we are required to maintain. 
 
 For many years the catalog department turned out a highly selective, 
 hand typed monthly list of new books. Acquisitions, with the assistance of 
 LOLITA, now turns out "Additions," a bimonthly list, at approximately 
 one-half the cost. "Additions" automatically includes those items ordered 
 through LOLITA and subsequently cataloged; thus, a complete current record 
 of the cataloged additions (including replacements and duplicates) is assembled 
 except that items received on standing order are not yet generally included. 
 As each item is cataloged and put onto the shelves, the call number and the 
 date cataloged are added to the record in LOLITA's files. This causes a 
 transfer of this record from on-line to magnetic tape which is processed 
 bimonthly. The author, title, date of publication, and call number of each 
 new item are extracted and grouped into sixty-three subject clusters and 
 subarranged by author. Then the list is output on the line printer and sent to 
 the university printing department where it is photographically reduced to 65 
 percent of its original size. After printing, the list is distributed to the 
 departments and administrative offices of the university. A short extract from 
 "Additions" is reproduced in fig. 2. 
 
 After the first issue of "Additions" (December 15, 1970) we received a 
 number of adverse comments regarding poor legibility. By the time the second 
 issue came out two months later a new line printer had been installed which 
 featured a markedly improved type face as well as better controls for vertical 
 spacing. Legibility ceased to be an adverse factor. 
 
 Early in March 1971, after the second issue of "Additions" was 
 distributed, a questionnaire was sent to each member of the Oregon State 
 University faculty. About one-third of the faculty responded. Table 2 
 summarizes the response. 
 
 "Additions" was originally arranged into fifty-eight subject groups based 
 on the initial letter or letters of the LC classification system; sequence within 
 each group was by main entry. More specific subject groups could be created 
 by sorting more of each call number, but the costs would be significantly 
 increased. Fifteen additional subject groups were added to meet special and/or 
 
34 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 >ufIOHI 1 CCINNINC 
 
 MkLiACi. toc. (.NAtics ICOITOO soic ofi -.IN or out,. -', .. . -uo*. SMOHTT. 
 
 iiisif iMoci IF*INT sEsicsi (nn iii-ii i LO/.uji/o/mi* 
 
 MILLMNS.STLVI* MT HASSLINC I11MI L0^*l/. /* 
 
 CNCtNCHINC, CMCICl 
 LCSCM.ll** ,ETil.f OTCIMti 1*1 COLO* RCCim F0 OTfINC T *) MMICS "MM TUL MAT(*HLt 
 
 iitrii tHivCli 
 
 NCMMtHf SCIFNCI INO TtCHNOlOOT Nt*>MC SCICNCC *NO T [CMNOlTCT I INOItttdU. IIOIOOIOI. MO DiST( TfTM 
 
 CNT ^MCCSStS. COIItd T jtdfS f. FUNK <!'> T*/.e/itM 
 SCICNCC Or CC**ICS VOCUNC T7t*/Sl 
 
 T*CSSIC,OON1LD (ITCLIT/jOtLTN.NtTNtRO <.OITOSI FU1I >KO VCtCTttLf JUICT rHOCCSSIMC ICCMNXOGT 
 
 (1*71) TStZ/tt*/l*7i 
 
 TtTgt .concur CHILD MSS-TVIITSFC* o(>t TIONS. iMCtcm-HKi CH.HICAL c'iMft[c stiS) 
 
 POXLUTION POT. tHOC*S. 1 lINOtM ?al*I/*% 
 
 PIE. STIKOOO S"ECIf ICITIOM5 FO* UM.IC D5 
 
 tNTILL.JkHCS N. CIVIL CNCIHCt*IN NANatCHCNT Ittftl 'l0/ii 
 
 *pLCI>UH.SiHuei i. OClINCtumTION IT ION CICNINCI ID "*U TJCJIMCKT iMQ C><e>>ICM. toc r 5Slt or OTNf* 
 
 LlOUtOS (lfk() (0<>*o7.r/4M 
 
 8JtMlN,JtCn iLPM PX09HTLIIT, SIAIIStlCS, NO DCCISIOH F0 CIVIL CN6INCC1 llt/ll Ttim/tsS 
 
 C*G,NCIL / (.0T.* I tH P. ! " >''< ITT AT S(.E-, O'CCQM, 1151-Htr. (14(11 
 
 TOIJ/.*.' > ' 
 
 "$ <* ** 
 
 Fig. 2. Extract from "Additions" 
 
 cross-disciplinary needs: three were separated in economics; the remaining 
 twelve could be separated only at greatly added expense. 
 
 The most urgent problem reflected in the questionnaire was one of 
 circulation. Publicity in the University's Staff Newsletter, admonitions in 
 "Additions," and notes to departmental secretaries stapled on the front cover 
 have done much to increase the size of the readership of "Additions." We 
 distribute an average of one copy of "Additions" per ten faculty members. As 
 far as can be determined this is an adequate level of saturation. 
 
 The total effect of the other questionnaire comments was to approve the 
 organization of "Additions," the data provided, its frequency, and its distri- 
 bution. The dissenters were a small minority and by no means in agreement 
 with one another. 
 
 Since July 1971, acquisitions has been filing one copy of each invoice 
 processed; previously this task (requiring four to five hours per week) was 
 performed by the Oregon State System of Higher Education (OSSHE) Dean of 
 Library Services Bookkeeping Office. 
 
 These increases to the acquisitions work load could not have been 
 absorbed without LOLITA. Indeed, before LOLITA, acquisitions was having 
 difficulty keeping orders going out and invoices processed; files lacked 
 maintenance, and claims were an irregular and infrequent consideration. Now, 
 with LOLITA, the files are being maintained, claims are being handled on a 
 regular basis, and the added work load factors described above were easily 
 absorbed. 
 
ON-LINE ORDER AND FUND ACCOUNTING 
 
 35 
 
 Responses 
 
 Percentage 
 
 Had not seen 
 
 72.2 
 
 Found useful within or outside their subject 
 area 
 
 82.4 
 
 Were satisfied with format, arrangement, and 
 reproduction quality 
 
 88.8 
 
 Felt a list of materials should be published 
 Monthly 
 Bimonthly 
 Quarterly 
 Annually or biannually 
 
 94.2 
 24.6 
 31.8 
 37.5 
 6.1 
 
 Table 2. Faculty Responses to "Additions" 
 
 Clearly, then, LOLITA has had a positive effect on the acquisition staffs 
 ability to perform its normal functions. Not only is the quality of biblio- 
 graphic and fiscal control improved, but acquisitions has, with no increase in 
 staff, taken on at least the equivalent of one and one-fifth FTE positions in 
 added responsibilities. To maintain the present level of bibliographic and fiscal 
 control would require the addition of at least two and probably three FTE 
 positions to the acquisitions staff. This sounds like an extravagant statement, 
 but a proper comparison of a manual and an automated system must look in 
 two directions: (1) at the relative difference in cost between the manual 
 system and the automated system which followed, and (2) at the cost of 
 manually attempting to achieve the controls and benefits of the automated 
 system. The first figure alone may make the automated system look 
 expensive, but the second figure shows a manual system to be even more 
 expensive. 
 
 Bookkeeping Office 
 
 During 1970/71 the OSSHE Dean of Library Services Bookkeeping Office 
 continued to do fund accounting for Oregon State University Library as it had 
 done for the last four decades. This paralleled the fund accounting done by 
 LOLITA. By the end of the year there were no doubts about the integrity of 
 the accounting performed by LOLITA, for the parallel fund accounting had 
 demonstrated that LOLITA was more accurate, more timely, and vastly more 
 detailed than the human bookkeepers (who were quite good). Beginning July 
 1, 1971, the fund accounting done by LOLITA is the official accounting. A 
 
36 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 listing of the invoice input is audited by the bookkeeping office, but it does 
 not duplicate any of the work done by LOLITA. Thus the work load of the 
 bookkeeping office has been significantly diminished. 
 
 As noted, an encumbrance system of accounting able to carry forward 
 committed funds into the new fiscal year as outstanding funds is used. In 
 order to do this it is necessary for the bookkeeping office to provide the 
 controller with an itemized list of purchase order numbers and accompanying 
 encumbrances; this monstrous task requires days of tedious work. On June 30, 
 1971, LOLITA produced Oregon State University Library's outstanding order 
 list in about twenty minutes (wall clock time) and at a cost of about $20. 
 Three weeks later the bookkeeping office was still compiling the outstanding 
 order lists for some of the other libraries in the OSSHE. 
 
 Serials Fund Accounting 
 
 LOLITA, as originally conceived, was to be strictly a monograph order 
 system. However, as planning for fund accounting was underway, it was 
 decided that all book, serial, and binding funds would need to be included if 
 the fund statements were to have either validity or utility. Expansion of 
 LOLITA to include serials receipts was out of the question. Instead, TFINVO 
 was developed a program for cathode ray tube (CRT) input of invoice data 
 for serial, standing order, and binding invoices for which LOLITA has no 
 outstanding purchase orders. The operator inputs some or all of the following: 
 account number, actual price, estimated price, vendor code, invoice number, 
 invoice date, total amount of invoice, or purchase order number. On redisplay 
 the flagword TFIN is automatically supplied indicating to the fund accounting 
 programs that the invoice was received on a TF ('til forbidden) order. The 
 operator can make any necessary corrections at this time. 
 
 Some invoices contain several different TF items; for these the flagword is 
 changed to MINV (multiple invoice) so that the repetitive data (vendor code, 
 invoice number, invoice date, and total amount of invoice) are carried 
 forward, and the operator need only fill in the account number and actual 
 price. This program is not only efficient, it is very fast. For a credit memo- 
 randum, the data are entered as if for an invoice and the flagword changed to 
 CRED (credit). 
 
 TFINVO has made it unnecessary to convert all old orders to LOLITA 
 but, at the same time, has allowed for a single set of fund accounting 
 procedures. For an item received and invoiced on a purchase order issue prior 
 to LOLITA (and carried in the outstanding fund) the flagword INVO (invoice) 
 is used. Thus there is provision for entering estimated price and purchase 
 order number in TFINVO. Similarly, if one of these old orders is cancelled, 
 the flagword CANC (cancel) is used. 
 
ON-LINE ORDER AND FUND ACCOUNTING 37 
 
 Flagwords 
 
 One of the features of LOLITA is the set of flagwords with which a number 
 of logical situations can be controlled. For a normal purchase order the 
 flagword is blank, upon receipt of the title and the invoice, the flagword is 
 changed to INVO. The Spigai and Mahan article described twelve flagwords 
 with which cancellations, confirmation orders, partial shipments, etc., could be 
 handled. 1 We naively assumed that everything we ordered would be cataloged 
 with some sort of call number; we were wrong. 
 
 A number of items are received which do not receive a call number per 
 se, such as phonodiscs, microforms, vertical file material, maps, and curriculum 
 library material. The item which really demonstrated the problem was the title 
 purchased to be exchanged for another title from Southeast Asia. Not only 
 did we not plan to catalog the book, we shipped it overseas the same day we 
 received it. Then we found that there was no way to remove it from the files! 
 The flagword KILL could have been used but this is usually reserved for 
 cleaning the files of cancelled items. The solution was the addition of the 
 flagword NCAT (not cataloged) which permits removal of the item without 
 the necessity of a call number. NCAT does not require any call number; 
 however, it is possible to use one of five pseudo-call numbers in combination 
 with NCAT for identifying certain special collections: MAPS, DISC (for 
 phonodiscs), CURR (for curriculum library), MICR (for microforms), and 
 VERT (for vertical file materials). 
 
 From the beginning LOLITA has had the ability to handle partial ship- 
 ments by use of the flagword PART (partial). This ability has been further 
 refined by the addition of the flagword MORE. When the first installment of 
 a partial shipment is received, the flagword PART is entered permitting the 
 invoice in hand to be paid and, at the same time, permitting the order to be 
 kept open for further receipts and payments. Thereafter, whenever the item is 
 displayed, the flagword PART will be shown along with a set of special 
 instructions for the operator. If further shipments are expected, the flagword 
 MORE is typed in and the order remains open. If no further shipments are 
 expected, the flagword INVO is typed in and the order is closed for account- 
 ing purposes. 
 
 The flagwords HELD and GIFT (included in the Spigai and Mahan 
 article 1 ), continue to be used, but with expanded capabilities. While none of 
 the items identified by either of these flagwords are considered in terms of 
 fund accounting, LOLITA does compile special data. HELD orders are those 
 titles which are input for bibliographic control while awaiting funds to permit 
 their purchase. Books given to the library and selected to be added to the 
 collection are similarly input so that all monographs can be handled with one 
 set of procedures. Two pieces of information are appended to the fund 
 accounting statement: (1) the dollar amount of HELD orders currently in the 
 
38 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 files, budget line item by budget line item; and (2) the cumulated evaluation 
 assigned to gift books added during the fiscal year. 
 
 The addition or deletion of a flagword constitutes only minor surgery for 
 LOLITA. Such changes must be made carefully because they are the levers by 
 which control is exerted over the various conditions which develop in the 
 course of ordering books and maintaining fund accounts. However, the 
 structure of the program assumes that as new conditions develop, flagwords 
 will be added or deleted. 
 
 Miscellaneous Refinements 
 
 Simplication of acquisitions work procedures and improved efficiency are 
 constant and ongoing goals of the LOLITA project. Some program adjust- 
 ments are minor points, while others assume major significance. For example, 
 LOLITA originally required that the operator key in the order date. A simple 
 program change provides this data element automatically and at less expense 
 than could be done manually. If for some reason a different date is preferred, 
 it is simply written over the supplied date. 
 
 Similarly, LOLITA originally required that the operator key in the 
 number of copies being ordered. Since more than one copy of a title is rarely 
 ordered, "1" is now supplied as the number of copies to be ordered and the 
 operator may override the number if more copies are being ordered. 
 
 The CRT input routine for new book order data is divided into three 
 sections: a page of bibliographic data, a page of fiscal data, and a page of 
 miscellaneous or inventory data. Again, the original program versions required 
 that the operator proceed through all three pages even if there were no data 
 to be entered on the third page. A simple exit key now permits the third page 
 to be bypassed if it is not needed. 
 
 Author Search 
 
 The Spigai and Mahan article stated that "Searching programs have been 
 completed which will search by order number and by author." 4 The order 
 number search has worked faithfully from the beginning. The author search 
 also worked but with a severe limitation: it required an exact match. In other 
 words, in order to retrieve an author, one had to enter the search in exactly 
 the same form down to the last letter, space, and comma. Even searching for 
 John Smith was a problem if he had a middle name. Corporate author 
 searches were generally only a last resort. 
 
 In January of 1971 a simplified author search was implemented which is 
 so successful that the exact match search is now only rarely used. The 
 simplified search requires that the first four (or fewer) letters of the author's 
 surname be input. With our on -order/in-process files which are stabilized at 
 
ON-LINE ORDER AND FUND A CCOUNTING 39 
 
 about 6,000 orders, this four-character search has proven to be more than 
 adequate. If the files were to be expanded to 18,000 items, the four-character 
 search would probably still be adequate although its efficiency might begin to 
 show degradation. 
 
 When the operator enters four characters for an author search, one of the 
 following will occur: 
 
 (1) LOLITA will indicate that no authors whose names begin with this 
 initial combination of letters occur in the files; 
 
 (2) if only one item in the file meets the search specification, the biblio- 
 graphic page of that item is displayed; or 
 
 (3) if two or more names qualify, a numbered list of authors' names is 
 displayed. By keying in the number opposite the desired name, one of 
 two conditions can occur: 
 
 (a) if only one item by that author is in the file, the bibliographic 
 page of that item is displayed, or 
 
 (b) if two or more items by that author are in the file, a numbered 
 list of titles is displayed. 
 
 Fig. 3 is a simplified flow chart illustrating how the author search program 
 works. 
 
 After one has looked at a displayed item, an escape key (an equals sign 
 followed by pressing the SEND key) causes a redisplay of the numbered list 
 of authors' names for that search. The list is held in core memory and remains 
 available for further use until the operator signals that the list is no longer 
 needed; the list can be discarded by typing NC (no choice) which brings one 
 back to the beginning of the search program. 
 
 LOLITA does not differentiate between an alphabetized and a non- 
 alphabetized group of order requests. However, if one is working with an 
 alphabetized group, it is sometimes possible to input only two or three letters 
 and, thereby, search several items simultaneously. For this reason and because 
 other library files require that the requests be alphabetized, normal work is 
 done with alphabetized groups of requests. Of course, it is possible to search a 
 difficult item under several different possible entries in succession without 
 disturbing the sequence of the requests in the group. 
 
 In some searching situations it is necessary to search either by author or 
 purchase order number. To go from one type of search to the other the 
 operator needs only to key in the command SWITCH and press SEND. The 
 alternate search mechanism is immediately available. This search mechanism 
 will also allow an exact main entry search (e.g., Smith, John P.) as a search 
 request. 
 
 The four-letter author search operates on the same multi-tiered index 
 described by Spigai and Mahan. 1 The author index is an inverted tree. A title 
 search remains to be implemented. 
 
40 
 
 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 Fig. 3. Flow Chart of Author Search 
 
 Purchase Order Printing 
 
 LOLITA was originally set up to have purchase orders printed out on a 
 Teletype terminal located in the library. In this way there was complete con- 
 trol as to when the orders would be printed and control of proper forms 
 and proper alignment of the forms. Teletype output of purchase orders 
 requires approximately forty seconds (wall clock time) per purchase order. 
 
ON-LINE ORDER AND FUND ACCOUNTING 41 
 
 This was judged to be a satisfactory method for printing orders but there was 
 occasional inconvenience due to the length of time the teletype was tied up in 
 merely printing. Two hundred orders at forty seconds each is one hour and 
 forty-three minutes. 
 
 One advantage in working with the Oregon State University Computer 
 Center is that the facilities (both hardware and software) are constantly being 
 perfected and expanded. One expansion was an improvement in the way batch 
 jobs could be entered remotely. It became possible to initiate the batch 
 printing of purchase orders on the line printer from the library's Teletype 
 terminal; so we developed an optional printing routine for line printer out- 
 put. 
 
 The use of the line printer has shifted to the computer center the 
 responsibility of loading and lining up forms. In addition to the convenience, 
 the printing is done more rapidly and at a lower cost. The line printer prints 
 purchase orders at the rate of about one per second; that is one-fortieth the 
 time required with the Teletype. Two hundred purchase orders can be printed 
 on the line printer in less than three and one-half minutes. The graph in fig. 4 
 shows the cost comparison between Teletype and line printer purchase order 
 printing. Note that when printing fifty-two or fewer orders the teletype is 
 more economical than the line printer. 
 
 As a result, although the option of printing purchase orders on the 
 Teletype, particularly for a small rush group, is still retained, we depend 
 almost entirely on the line printer. Our routine is to initiate the remote batch 
 job with the Teletype, walk the short block to the computer center to pick up 
 the printed orders, and bring them back to the library for audit, bursting, and 
 mailing. The only problems encountered have been operator errors when the 
 wrong forms were loaded or the alignment was not done properly. In such 
 cases, the orders are reprinted at the computer center's expense. 
 
 Held Orders 
 
 As mentioned, the flagword HELD signifies that the item is built into the 
 bibliographic records for control until money is available, but that no fund 
 accounting has been performed. Our library has had a history of substantial 
 amounts of book fund money arriving very late in the fiscal year, sometimes 
 on the last day of the year. To utilize these late funds it is necessary that 
 they be encumbered and purchase orders issued by 5:00 p.m. on June 30. 
 Therefore, we have HELD orders which, by changing the flagword to LIVE, 
 become active purchase orders with complete fund accounting. 
 
 The first opportunity to try the HELD order procedure with LOLITA was 
 in June 1971. Added to the book budget was $60,000 that approximately 
 doubled monographs and retrospective materials purchasing ability. Because 
 we had already printed and stockpiled a substantial number of HELD orders, 
 
42 
 
 1 9 72 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 20 
 
 1ft 
 
 10 
 
 68 100 200 300 
 Number of Purchase Orders 
 
 400 
 
 Fig. 4. Cost Comparison for Printing Purchase Orders 
 
 we were able to avoid the purchase of a major reprint set which, although 
 composed of excellent research material, has little relevance to the Oregon 
 State University curriculum. 
 
 As an aid in selecting from among HELD orders to be purchased, we can 
 obtain a listing of all HELD orders arranged by fund account number, and 
 subarranged by subject category number. Thus, we can concentrate on specific 
 subject areas desired. 
 
 File Structure and System Changes 
 
 The structure of the LOLITA files has undergone only two minor changes. 
 The account number, formerly stored as two computer words, is now stored 
 as one computer word. The position of the flagword in the sequence of data 
 elements has been moved from fifteenth place to seventh place for easier 
 access. Moving the flagword's position is a gradual process in which the 
 flagword is moved automatically as the old record with the old format is 
 accessed. This change was begun in mid-October of 1971; by May of 1972 
 
ON-LINE ORDER AND FUND A CCOUNTING 43 
 
 few, if any, records are in the old format. The users of LOLITA were 
 completely unaware of either of these changes as they were taking place. 
 
 In another area we did make a change of which the operator was aware. 
 The first version of LOLITA filed and indexed each item as it was input. To 
 enhance file security, the programs were altered so that as new orders are 
 input, they accumulated in a temporary file. At logoff time or at the 
 discretion of the operator, the contents of this temporary file are filed away 
 and indexed. One benefit of this change is an increased rate of input since the 
 operator need not wait for one item to be filed and indexed before the next 
 item is input. 
 
 An on-line system operates within critical logical tolerances outside of 
 which the computer may crash and files may be lost. When needed for 
 back-up protection, both OS-3 and our own back-up files are used. Periodic 
 tape copies and an item-by-item transaction file attached to LOLITA are both 
 used. Interestingly, the more back-up capability we have developed, the less 
 often we need to use it. This is a reflection of general improvements in the 
 overall operating system (OS-3) and the gradual elimination of bugs in 
 LOLITA. In fact, it is questionable whether we really need to maintain the 
 back-up measures since they are so infrequently used; however, they are cheap 
 and effective insurance. Thomas Mahan, research associate with the Oregon 
 State University Computer Center, is in the process of preparing a detailed 
 paper discussing the design, use, and need for back-up devices for use with 
 LOLITA. 
 
 Program Transferability 
 
 Many librarians have inquired about the transferability of LOLITA to their 
 library. In answering this question, several factors must be considered. First, 
 LOLITA is dependent on OS-3, the on-line, time-sharing operating system 
 used by the Oregon State University Computer Center. Although there are 
 several other CDC 3300 computers in the country, Oregon State University is 
 the only one using OS-3 as its operating system. Therefore, only a library 
 patronizing the Oregon State University Computer Center could use LOLITA. 
 
 Second, because of present local software and hardware limitations, a 
 CRT terminal must be operated within 3,000 feet of the Oregon State 
 University Computer Center. Teletype and video display terminals with Tele- 
 type logic can operate over telephone lines at any distance. Discussion among 
 the Oregon State System of Higher Education librarians may lead to a 
 decision to develop an alternate form of the CRT portions of LOLITA to 
 work on a video display terminal with Teletype logic. Then any library could 
 use LOLITA via telephone lines. 
 
 Third, there is the question of the adequacy of LOLITA for handling the 
 book ordering and fund accounting of another library. While we had no 
 
44 1972 CLINIC ON A PPLICA TIONS OF DA TA PR OCESSING 
 
 doubts about this, we recognized the need for empirical evidence to support 
 our assumption. A year ago the office of the vice chancellor for administrative 
 affairs granted us the funds necessary to support a six-month trial run with a 
 second library. Oregon College of Education Library in Monmouth, twenty 
 miles north of Oregon State University, participated in this experiment. Our 
 objective was to test the adequacy of the LOLITA programs for another 
 library, not to involve ourselves in the question of terminals and communi- 
 cations links. For this reason all input and updating of the files for Oregon 
 College of Education Library has been done in the Oregon State University 
 Library, but by persons on the Oregon College of Education payroll. As part 
 of the experiment, the LOLITA fund accounting was to be the official fund 
 accounting for Oregon College of Education's book, serial, and binding 
 budget as it is for Oregon State University. The funding for what was to be a 
 six-month experiment proved adequate to cover expenses for ten months. 
 Oregon College of Education Library likes LOLITA, but would definitely 
 prefer to have the input and update processing (i.e., terminals) done in their 
 own library. Without question, the experiment has proven the transferability 
 of the programs from one library to another within the Oregon State Univer- 
 sity Computer Center's on-line, regional terminal network. 
 
 Dynamic Environment 
 
 LOLITA exists in a highly dynamic environment. Mention has already been 
 made of the on-going efforts to improve the already good performance of the 
 timeshare operating system OS-3 through software and hardware modifi- 
 cations. 
 
 The environment is active in other ways as well. For instance, traffic, the 
 number of concurrent users, can vary widely according to time of day and 
 from beginning to end of the school term. The heaviest traffic tends to fall in 
 the mid-afternoon and after dinner hours toward the end of each term. But 
 even traffic is not a wholly reliable indicator of one's relative ability to access 
 the central processing unit (CPU) time. Many small jobs have no appreciable ef- 
 fect on overall response while a single large job may exert more competition than 
 several dozen other jobs combined. And, of course, traffic varies widely during 
 each particular job. 
 
 LOLITA's files vary in size reflecting a number of variables. As new data 
 are input, whether they be new orders or invoice information, several files 
 grow in size. As purchase order and invoice information is processed, certain 
 transitory files grow and diminish in size. As cataloging information is added 
 to a record, that record is released from the on-line file to be transferred to 
 magnetic tape. The release process not only frees the file space occupied by 
 the record, but also frees indexing and file pointer space. This free space is 
 then available for reallocation as new information for other orders is input. 
 
ON-LINE ORDER AND FUND ACCOUNTING 
 
 45 
 
 Type of Charge 
 
 OSU Computer 
 Center Rates* 
 
 Monthly 
 A verage 
 
 Total: Jan. 1- 
 Dec. 31, 1971 
 
 Central processing unit 
 
 $300/hour 
 ($.083/second) 
 
 $481.17 
 (1.6hrs.) 
 
 $5,774.00 
 (19.25 hrs.) 
 
 On-line disk storage 
 
 $.1 5/2040 char./month 
 
 $330.45 
 (4,494,120 
 char.) 
 
 $3,965.40 
 (53,929,440 
 char.) 
 
 On-line terminal time 
 
 $2.00/hour 
 
 $228.44 
 (1 14.22 hrs.) 
 
 $2,741.22 
 (1,370.61 hrs.) 
 
 CRT rental and 
 Maintenance 
 
 $100/month 
 
 $100.00 
 
 $1,200.00 
 
 Tape charge 
 
 $.50 tape mount 
 $.03/sec 
 (channel time) 
 
 $74.99 
 
 $899.87 
 
 Line printer 
 
 $.125/100 
 lines 
 
 $65.67 
 (52,539 lines) 
 
 $788.09 
 (630,472 lines) 
 
 Tape rental 
 
 $1.00/month/tape 
 
 $13.27 
 (13 + tapes) 
 
 $159.29 
 
 Card reader 
 
 $.15/1 00 cards 
 
 $.70 
 (465 cards) 
 
 $8.38 
 (5,587 cards) 
 
 Card punch 
 
 $.25/1 00 cards 
 
 $.01 
 
 $.16 (64 cards) 
 
 Refund 
 
 
 -$83.48 
 
 -$1,001.78 
 
 Total 
 
 
 $1,211.22 
 
 $14,534.63 
 
 ""Oregon State University Computer Center rates were extracted from the Cen- 
 ter's Computer Center Newsletter, vol. 6, no. 6, Sept./Oct. 1971. 
 
 Table 3. Summary of LOLITA Charges 
 Costs 
 
 So far this has been a review of LOLITA's accomplishments, changes in 
 attitude and procedure, and a gradual reordering of our daily existence. A 
 review of the on-going operating costs of Lolita is now in order. The operating 
 costs billed to the library from the Oregon State University Computer Center 
 for the period January 1 through December 31, 1971, are shown in table 3. 
 The computer center sends the library a monthly statement containing the 
 totals for the various services used. The figures in parentheses were computed 
 based on computer center rates, average monthly, and total yearly costs. 
 
46 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 Some of the tape charge represents regeneration of LOLITA's files due to 
 computer or system failure. Some CPU, card reader, and line printer charges 
 are also accountable to file regeneration. Whenever regeneration charges occur 
 they are reimbursed in the form of a refund to the Computer Center Library 
 Account. The refund also includes reimbursement for improperly printed 
 forms because of line printer failure or computer center operator error. 
 
 The on-line terminal time represents the wall clock time the library used 
 LOLITA either by Teletype or CRT. Based on 260 working days in a year, 
 this averages out to 5.27 hours per day on-line. Many operations not requiring 
 user interaction such as the preparation of purchase order forms initiated as 
 remote jobs, the accounting, LOLITA back-ups, and preparation of out- 
 standing order lists are performed in batch mode so no on-line terminal costs 
 are assessed. 
 
 Occasionally an operation which is normally performed in batch mode 
 will be performed on-line for monitoring purposes by LOLITA systems 
 personnel to help locate a problem or in anticipation of a possible problem 
 which, in batch mode, might cause the run to abort. 
 
 In addition to cost figures supplied by the computer center's accounting 
 system, a logbook (LOLITA's figures) is used by the library to record unit 
 processing information. A portion of a page of the logbook is shown in fig. 
 5. When a LOLITA user logs on, a status command (*SCOOP) is entered 
 which displays the amount of credit remaining in the computer center library 
 account (credit), the amount of storage being utilized (SFBLKS), the number 
 of other on-line users at that moment (traffic), the date, and the time of day. 
 This information is entered into the logbook. Since hard copy is obtained 
 from Teletype operations the logbook is used at the CRT only. Upon com- 
 pletion of a work session, *SCOOP is again called and the new data recorded. 
 When the user logs off, the CPU time and cost of the session are displayed 
 and recorded. To complete the logbook entry the number of inputs, updates, 
 or searches is recorded and initialed by the user. This logbook provides data 
 valuable in detecting trends (e.g., peak work load periods) for most efficient 
 scheduling as well as data necessary to compute unit operation costs. Various 
 "time-eating" bugs have also been detected by periodic examination of this 
 record of LOLITA's performance. 
 
 The data shown in tables 4-6, were compiled from LOLITA's figures frpm 
 January through December, 1971, and from Teletype and line printer listings 
 which contain data pertinent to the various operations. The unit cost data in 
 table 4 were computed from samples drawn randomly from the population of 
 data representing each particular operation. Table 5 lists information about 
 the sample data used. 
 
 The data listed for each operation in table 4 are for an individual item. 
 For example, to search for one main entry (line 1) would cost on the average 
 $.045 or to input one TF invoice (line 6) would take an average of 26.0 
 
ON-LINE ORDER AND FUND ACCOUNTING 
 
 47 
 
 I XV CAT Urn 
 
 MOOTF 
 COST 
 
 UST P0# 
 OR INV$ 
 
 SFBL"3(S 
 
 arw-ri 
 
 32 
 
 SJ. 
 
 I-IS 
 
 S_ 
 
 57.380 
 
 aaa 
 
 *C.fr 
 
 8TS 
 
 152. 
 
 11 
 
 I5.776 
 
 4.1ft 
 
 31 
 
 37.7S>/ 
 
 in-rii 
 
 k-.*^ 
 
 40 
 
 1 
 
 !5& 
 
 Note: 1 . SFBLKS are Saved File Blocks (a file block being 2040 usable charac- 
 ters). The number of SFBLKS in use by LOLITA at the beginning and 
 end of each session is recorded. 
 
 2. CREDIT refers to the dollar balance held in the LOLITA pro- 
 duction account. For convenience, the money is deposited in ad- 
 vance. Between Dec. 6th and 7th an additional deposit of $7,331.25 
 was made. 
 
 Fig. 5. LOLITA's Figures 
 
 seconds of wall clock time. The storage increase per operation has been 
 converted to character representation from storage units peculiar to the CDC 
 3300 computer and the OS-3 operating system. 
 
 Searching all new book order requests on-line began in August 1971. 
 Although LOLITA had been operational since March 1970, a sixteen-month 
 period was required to receive and process orders issued prior to LOLITA. In 
 the fifty sessions (table 5) used for computing search costs, 196 duplicates 
 were found, about four per session. The average purchase price per item is 
 between $12 and $13. Thus, considering the total cost per search, $.06 (from 
 table 6), the identification of one duplicate pays the cost of searching 200 
 requests. The search sample included a session with one search which is listed 
 in the maximum column for the breakdowns in searching (line 1, table 5). 
 These high figures in comparison to the average (table 4) illustrate what is 
 generally true with a complex computer system whether it be batch or 
 on-line: as more operations are performed per session, the cost per operation 
 decreases. When the number of operations exceed a certain point, the rate 
 becomes nearly constant. (In fig. 4 the cost of printing orders is shown to be 
 constant above about thirty orders. Below that point the graph would level 
 out or curve toward the vertical axis indicating an increased cost rate for 
 smaller batches.) 
 
48 
 
 1972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 Operation 
 
 1 . Search for main entry 
 
 $.045 
 
 19.9 
 
 .441 
 
 24.7 
 
 none 
 
 5.368 
 
 2. Input P.O., HELD, GIFT 
 
 .153 
 
 124.1 
 
 1.026 
 
 23.0 
 
 738 
 
 16,964 
 
 3. Prepare P.O. form file, 
 
 
 
 
 
 
 
 update vendor data, 
 
 
 
 
 
 
 
 P.O. accounting 
 
 .014 
 
 batch 
 
 .147 
 
 NA 
 
 494 
 
 16,964 
 
 4. Print P.O. form 
 
 .039 
 
 batch 
 
 .097 
 
 NA 
 
 none 
 
 16,964 
 
 5. Input P.O. invoice 
 
 .075 
 
 55.4 
 
 .539 
 
 20.9 
 
 218 
 
 14.403 
 
 6. Input TF invoice 
 
 .022 
 
 26.0 
 
 .092 
 
 26.1 
 
 84 
 
 9.293 
 
 7. Invoice accounting 
 
 
 
 
 
 
 
 (P.O. or TF) and 
 
 
 
 
 
 
 
 list invoice for 
 
 
 
 
 
 
 
 audit 
 
 .0057 
 
 batch 
 
 .047 
 
 NA 
 
 128 
 
 23,696 
 
 8. Input catalog data for 
 
 
 
 
 
 
 
 P.O., remove P.O. from 
 
 
 
 
 
 
 
 on-order/in-process 
 
 
 
 
 
 
 
 file 
 
 .114 
 
 61.8 
 
 .940 
 
 22.5 
 
 313 
 
 10,810 
 
 Table 4. Summary of Standard LOLITA Operations 
 
 The breakdown of inputs for purchase orders, HELD orders, and GIFT 
 items (see line 2, table 4) for the 1971 calendar year was 14,428 purchase 
 orders, 1,407 HELD orders, and 1,129 GIFT items for a total of 16,964. The 
 addition of 738 characters per input does not indicate that the average input 
 for this operation contains this many characters. Each new on-order file input 
 requires 488 characters to be added to a temporary file for subsequent 
 operations (preparing order forms, accounting, etc.). The remaining 250 
 characters of storage increase are also added to a temporary file for back-up 
 purposes. Both of these temporary files are removed periodically and add little 
 to storage costs. The data from an input does not generally change the size of 
 the on-order file since it usually takes the place of an order which has been 
 cataloged and removed leaving a vacant 204 character LOLITA "page." About 
 200 characters of the 250 characters added to the back-up file are data which 
 were input by the user. Besides the input of data (line 2, table 4), the unit 
 operation figures also include the storing and indexing of each item added to 
 the on-order file. 
 
 The preparation of the purchase order form file, updating vendor infor- 
 mation, and purchase order accounting (line 3, tables 4, 5 and 6) are 
 
 ar>rnmnlichpr1 hv nrrr>pccino thp innnt Hata ctnrpH rn thp fpmnnrarv file fnr 
 
ON-LINE ORDER AND FUND ACCOUNTING 
 
 49 
 
 CnxtlOn 
 
 ' ^* 
 
 Or- N o ci <N oo m 
 
 V> <N OO O O 
 
 4 9 
 
 S 
 
 iriON ^OOONOO ON O 
 
 C^J O ^~ CO IO "-^ T^ ^s 
 
 OOOO 
 
 60 
 
 .^ 
 
 I 
 
 s; I2S5 .2 5 
 
 ^ 
 
 S 
 
 z z - z 
 
 Q 
 
 C5 
 - 
 ~ 
 
 5 
 1 
 
 d 
 
 c 
 
 r\ 
 
 <N f- OOCNOOO Tj- O 
 
 oo^t (s-^r--^ o <N 
 
 ^J 
 ^ S2 
 
 ON co 01 C^J ro c^) o-i ^^ 
 
 <N *O ^^ O ro O O vo 
 
 | 
 
 I"-* 
 (^ 
 
 1 
 
 X 
 
 q <-M ac z . -*. E o 
 
 or> UU-* U oo 
 
 00 t^"- ^H ^N ON Tf ^N O 
 
 OQ CQ PQ 
 
 <^ 
 
 ^O oo 3^ NTN ON oo *C QO 
 oo ^t U U <N ON o 
 
 ON ^ t* Tt E-. Tt 
 
 
 "^ 
 
 k\ 
 
 o */~) r*^ to o o */"> 10 
 m -^ ^^ ~^ ^^ 
 
 * 
 
 -, 
 
 o- i 
 
 ^ C^i C^ 00 ON ^^ t^ 1 CN 
 i/"i 00 CO O O CO i/") O 
 
 Operation 
 
 H 
 C-J^-Ooo .'So '"2 ^Pi? 
 
 gtu.OucE >'S c w l - T3 o- 8 
 o Q r 2 o **"' O "" "Ho 3 i ^ 
 
 " H a, J2 ^ 3 3* 'S C> '^ iS "3 _T o 
 ea o. a>~O -5 o. o. >.*j"C o,Oi> 
 
 oi co rj-in \6 r-' oo' 
 
 > 
 
 i 
 
 s 
 
 CQ 
 
 ea 
 Q 
 a> 
 
 "a 
 
 a 
 O 
 
 H 
 j 
 O 
 
 T> 
 ea 
 
 C 
 ea 
 
50 
 
 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 Operation 
 
 Computer 
 
 Personnel 
 
 Total 
 
 Unit 
 
 Annual 
 
 1 . Search for main entry 
 
 $.045 
 
 $241.56 
 
 $.015 
 
 $.060 
 
 2. Input P.O., HELD, GIFT 
 
 .153 
 
 2,595.49 
 
 .080 
 
 .233 
 
 3. Prepare P.O. form file, 
 update vendor data, P.O. 
 accounting 
 
 .014 
 
 237.50 
 
 none 
 
 .014 
 
 4. Print P.O. form 
 
 .039 
 
 661.60 
 
 none 
 
 .039 
 
 5. Input P.O. invoice 
 
 .075 
 
 1,080.23 
 
 .036 
 
 .111 
 
 6. Input TF invoice 
 
 .022 
 
 204.45 
 
 .016 
 
 .038 
 
 7. Invoice accounting (P.O. 
 or TF) and list 
 invoice for audit 
 
 .0057 
 
 135.07 
 
 none 
 
 0057 
 
 8. Input catalog data for 
 P.O., remove P.O. from 
 on-order/in-process 
 file 
 
 .114 
 
 1,232.34 
 
 .040 
 
 .154 
 
 Total 
 
 
 $6,388.24 
 
 
 Table 6. Summary of Computer and Personnel Unit Costs for LOLITA 
 
 this purpose. The 494 characters added to storage by this operation are 
 broken down to an average of 446 characters per purchase order form and 
 forty-eight characters of individual purchase order accounting data. When the 
 purchase order forms have been printed, the 446 characters of storage per 
 form are released. The forty -eight characters per purchase order stored for 
 purchase order accounting are accumulated over a month's time, listed for the 
 bookkeeper's easy reference and transferred to magnetic tape. The on-line 
 storage for this temporary purchase order accounting data file is then released. 
 The traffic for batch operations has not been obtained since the increased 
 duration of a batch job caused by the amount of traffic has little effect on 
 the cost of the operation. 
 
 The operational figures for updating the on-order file by inputing invoice 
 data are given in line 5 of tables 4, 5 and 6. This update usually includes the 
 addition of the following data elements: flagword, actual amount (in dollars), 
 invoice date, and invoice number. The order to be updated is accessed by the 
 purchase order number which most vendors list on their invoices. The 
 appropriate data (84 characters) are transferred to a temporary file as a source 
 for a subsequent accounting operation. The remaining storage increase caused by 
 purchase order invoice input is the new data being entered on a back-up file. 
 
ON-LINE ORDER AND FUND ACCOUNTING 51 
 
 As in the case of a new purchase order input, the added invoice data stored in 
 the main file do not increase long-term storage. 
 
 Invoice data for material received on a standing order basis (TF, Hil 
 forbidden) are input for accounting purposes using TFINVO which was 
 described above. Operating data for TFINVO are shown in line 6 of tables 4, 5, 
 and 6. The eighty-four characters of increased storage represent the transfer of 
 data to the temporary TF accounting data file. 
 
 The accounting using the invoice input for purchase orders or TFs is 
 performed by the same program (PREPARE) that prepares purchase order 
 forms. If the program is run on-line only purchase order data are manipulated; 
 no invoice accounting is performed. The program is set to run in this manner 
 to accommodate the preparation of RUSH orders or a small batch of orders. 
 The LOLITA user continues to interact with the system so that knowledge of 
 when the purchase order forms may be printed will be immediately available 
 and printing may commence at the library on the Teletype without requiring a 
 trip to the computer center. By not performing invoice accounting on-line, 
 terminal and user time is saved as well. When PREPARE is run in the batch 
 mode the invoices are processed. The operating data for this process are 
 shown in line 7 to tables 4, 5 and 6. The 128-character per invoice storage 
 increase represents invoice data being stored on a temporary file. This 
 temporary file accumulates invoice transactions for a month and, at a cut-off 
 date, is sorted and listed in a manner similar to the forthcoming controller's 
 list of the checks written for these invoices. The controller's list is compared 
 with the library monthly invoice list to verify the check writing. The pro- 
 cessing of the invoices also produces an invoice audit listing. This audit listing 
 is given to the bookkeeeper with the invoices to verify that the invoices have 
 been input correctly. 
 
 Once a book is put onto the shelf and represented in the main card 
 catalog, a copy of the master catalog card is used to update the on-line order 
 for that book. The data for this catalog data input are shown in line 8 of 
 tables 4, 5 and 6. Any bibliographic data stored on-line which is different 
 from the catalog copy is edited at this time. The LC classification number and 
 date cataloged are also added to the on-line record. This triggers a mechanism 
 which removes the record from the on-order main file and index files. The 
 item is written onto a temporary file which is used to produce "Additions," 
 the library's bi-monthly announcement of new materials added to the library 
 collection. When "Additions" has been produced, the file of cataloged items is 
 copied onto magnetic tape for possible future use. 
 
 On-line operations (lines 1, 2, 5, 6, and 8 of tables 4, 5 and 6) are 
 affected by the number of computer users. A LOLITA user will not normally 
 detect a delay in response until there are more than thirty other users on the 
 system. Usually computer traffic only affects LOLITA's response during the 
 last week of the term when student programs are due. Revisions to the 
 
52 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 computer center system (OS-3) have enabled more users to operate more 
 efficiently than in the past. 
 
 The operations in tables 4, 5 and 6 account for $6,388.24 (the sum of 
 computer costs, annual column, table 6) or 44 percent of the $14,534.63 paid 
 to the computer center for services during 1971. These operational costs do 
 not include on-line disk storage ($3,965.40), CRT rental ($1,200.00), or tape 
 rental ($159.29). Adding these figures to the operational sum gives a total of 
 $11,712.93 or 80.6 percent. The remaining $2,821.70 has not been separately 
 identified but has included the following: 
 
 1. The preparation and listing of five issues of "Additions." Each issue 
 contained an average of 1,826 items which were added to the library 
 collection. 
 
 2. Two productions of lists containing the orders of the on-order/in- 
 process file which had not received invoices (i.e., were outstanding). 
 The first list was used to establish a hard copy record of orders which 
 would not be processed (invoiced) during the fiscal year of the order, 
 and the second was produced to be used as a claims notice to vendors 
 for items which had not been received. Each list required an 
 examination of all records in the on-order file which is stabilized at 
 about 6,000 items. 
 
 3. The preparation of accounting summary statements. This summary 
 contains six pages of accounting information including: allocations, 
 expenditures, encumbrances, balances, last purchase order posted, and 
 last invoice posted for about forty budget lines; a category summary 
 of expenditures and encumbrances for nine different groups of over 
 ninety categories each; the amount of money in HELD orders which 
 exist in the on-order file; the GIFT evaluation to date; and the status 
 of purchase orders, HELDS, and GIFTS. These statements are 
 prepared at least weekly and cost about $.75 each. 
 
 4. The on-line examination of accounting data which is done irregularly 
 to determine accounting status between accounting summary state- 
 ments. 
 
 5. The on-line manipulation of on-line accounting data to correct for a 
 change in budgets or an error in the manual processing before invoice 
 input (e.g., assignment of a wrong TF account number). 
 
 6. The operation of on-line auxiliary programs which include status 
 programs for purchase order preparation or invoice preparation 
 (NOPO and NOIN) and programs which release temporary files after 
 verification of processing (POOK, INVOK, MONTHOK). 
 
 7. The on-line vendor file updates, maintained for the over 2,000 
 vendors being used, which include: adding new vendors, changing 
 existing data, deleting vendors, adding temporary vendors, and 
 changing frequency or dollar amount. 
 
ON-LINE ORDER AND FUND A CCOUNTING 53 
 
 8. The preparation of two vendor status listings which include names 
 and addresses of on-line vendors plus the frequency and amount of 
 money paid to each vendor. 
 
 These operations are executed irregularly with the exception of the 
 on-line vendor file updates, which are usually done before each invoice 
 accounting run. This file is being examined for possible changes to accommo- 
 date multiple school usage and the inclusion of additional data elements to 
 lighten the invoice handling by library and controller's office personnel. The 
 program involving vendor file updates would also need to be changed; there- 
 for cost data for this operation have been ommitted. 
 
 This discussion of LOLITA and her operating costs has centered primarily 
 around computer costs and procedural changes. Personnel costs are discussed 
 only briefly and shown in table 6 for five on-line operations. The library also 
 employs one systems analyst who spends part of his time with LOLITA and a 
 research associate who spends about 25 percent of his time with LOLITA 
 revisions and operations. Non-LOLITA aspects of the Oregon State University 
 Library's operations have been intentionally ignored, not because they lack 
 importance, but because of a basic commonality with most other academic 
 libraries. 
 
 This paper has attempted to give an overview of LOLITA during the past 
 two years: two or three years from now may show differences. A written 
 proposal to the chancellor's office is pending which would extend LOLITA to 
 the other libraries in the Oregon State System of Higher Education. There is 
 also discussion of developing a serials control capability for LOLITA. 
 
 REFERENCES 
 
 1. Spigai, Frances G., and Mahan, Thomas. "On-Line Acquisitions by 
 LOLITA," Journal of Library Automation, 3:276-94, Dec. 1970. 
 
 2. Baker, Robert S., et al. "LOLITA: An On-Line Demonstration." In 
 American Society for Information Science. Communication for Decision- 
 Makers (Proceedings of the 34th Annual Meeting, Denver, Nov. 7-11, 1971). 
 Vol. 8. Westport, Conn., Greenwood Pub. Co., 1971, pp. 397-400. 
 
 3. Graves, Robert. Seven Days in New Crete. London, Cassell & Co., 
 1949. (In the U.S. this novel was published as Watch the North Wind Rise. 
 New York, Creative Age Press, 1949.) 
 
 4. Spigai and Mahan, op. cit., p. 288. 
 
IRWIN H. PIZER 
 
 University Librarian and 
 
 Professor of Library Administration 
 
 University of Illinois at 
 
 the Medical Center 
 
 Chicago, Illinois 
 
 On-Line Technology 
 in a Library Network 
 
 ADVANTAGES OF ON-LINE SYSTEMS 
 
 The advantages of computers in libraries, although not a supposition which 
 one can afford to accept blindly, are as real as the advantages gained from the 
 other pieces of mechanical equipment which have become everyday tools for 
 accomplishing libraries' objectives. A major difference, however, is that a 
 library's investment in computers, attendant staff, supplies, etc., is so much 
 greater in terms of time, money, and energy, and in general commitment to 
 examine minutely the operations the computer is to perform, that the 
 comparison with other machines seems less valid. It is not a crisis if a system 
 planned around a tape-operated typewriter does not work and one is forced to 
 return to a more traditional method. The situations are similar in that it is not 
 necessarily the technology at fault, but perhaps the technique. One might call 
 the problem "The fault, dear Brutus, . . . syndrome." 
 
 The problems which many libraries have had with mechanization become 
 magnified greatly when they begin to work with on-line systems where the 
 stakes involved in success or failure are higher. No one claims that everything 
 ought to be done with machines, and there is no reason to suppose that a 
 combination of manual and mechanical, on-line and off-line systems will not 
 serve the library better than any one type of operation by itself. 
 
 On-line technology offers an unparalleled opportunity to accomplish many 
 of the things which libraries have always said they would like to if they had 
 the opportunity. Now there is the chance not only to catch up with the flood 
 
 54 
 
ON-LINE TECHNOLOGY IN A LIBRAR Y NETWORK 55 
 
 of information pouring into the library, but even to turn some of the flood to 
 advantage and, of course, to the benefit of users. 
 
 The library has been viewed as a total system for years, and many have 
 dogmatized that this approach was the only rational one to take in library 
 automation. There is, however, no reason why all of the parts of the system 
 must be developed simultaneously. The valid approaches are many and varied, 
 and more important, there are many approaches which have worked a success 
 that library automation efforts have not always achieved. The literature is 
 filled with lavish descriptions of planned systems replete with glowing estimates 
 of what they will accomplish, but the search must be long and hard to find 
 reports that these efforts have been successful. One searches in vain for 
 reports that a previously well -publicized system has failed. The expenditure 
 that has gone into abortive system development is scarcely credible and 
 certainly not creditable to the profession. Even the documented reports of 
 failure would have, perhaps, helped someone else. 
 
 Why, then, is there an emphasis on on-line systems, which not only cost a 
 great deal more than off-line systems, but are vastly more complicated to 
 organize and place in operation. The answer lies in societal needs and 
 expectations. We expect things to be fast, we equate speed with machines, we 
 believe that quality is inherent, and we assume that speedy machines are 
 efficient (although with the example set by Detroit for the production of 
 defective machines, one does tend to wonder at the credulity of people). 
 
 On-line technology will make the development of a national or regional 
 library network a real possibility. On-line systems will enable us to learn more 
 quickly, to alter our behavior patterns accordingly, and thus, to advance the 
 sum of human experience and the quality of life. 
 
 The main purpose of on-line technology in a library is to better serve the 
 user, which is after all a library's main purpose for existing. Few libraries 
 today see their major role as custodians of the past for the benefit of future 
 generations. On the contrary, all that we do should improve our service 
 capabilities to the person seeking information now. On-line technology not 
 only allows services to be provided more quickly, but for the first time allows 
 the library to disregard the limitations of its physical structure and interact 
 with users at other sites, and at times of their own choosing. We thus begin to 
 approach the goal of making a library available to users on a twenty-four hour 
 basis with few of the attendant costs of maintaining a physical facility or provid- 
 ing large numbers of personnel. On-line technology allows us exploitation of 
 limited resources of people, money, and information more effectively. On-line 
 technology also frees users from many of the cumbersome restraints which 
 libraries interposed between them and their needs in the past, forcing them to 
 adapt to the internal operations of the library rather than vice versa. 
 
 In discussions of on-line technology, most still think in terms of the 
 familiar computers and the adjunct hardware, but it is already evident that 
 
56 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 this is too narrow an approach to the subject. Other elements of technology 
 which complement the computer must be considered. Libraries have not really 
 considered the possibility of cable television as a major tool to serve them in 
 their role as important educational elements in their community, whether 
 public or university. Users should be able to call the library from their homes, 
 select programs from a printed catalog, and request that they be sent via the 
 phone line for playback through television equipment. Home videotape 
 cameras for making home movies, recording programs from television broad- 
 casts for later playback, purchasable cassette programs and a modified tele- 
 vision receiver to accept them are already on sale in Chicago. If the current 
 test marketing proves successful, it may be assumed that an extensive national 
 sales campaign will follow. 
 
 Few libraries have made computers available to users to solve problems of 
 their own. Not until recently has there been the possibility of using the 
 coin-operated, self-service computer terminal at $0.25 for five minutes of com- 
 puter time. 
 
 There are other possibilities which libraries will need to be aware of and 
 which will radically alter the services and collections of libraries. What holo- 
 graphs and lasers will produce and provide has hardly begun to be explored. 
 
 On-line technology therefore provides the library with a powerful tool to 
 enable it to do new things and to perform many of its present operations in 
 new and better ways. 
 
 USES OF ON-LINE SYSTEMS 
 Interlibrary Loan 
 
 An example of the possible power of an on-line network involves the inter- 
 library loan process. The term "possible power" is used because the problems 
 involved in placing it in operation are not technological. 
 
 The data base in the State University of New York (SUNY) network (fig. 1) 
 consists of citations to journal articles, citations to books, and a union list of 
 serial titles with holdings statements and location information for those titles 
 which are represented in the journal citation file. Therefore all information 
 regarding citations which is necessary for interlibrary loan is available. The 
 user, after obtaining the output to his search and scanning the retrieved titles 
 for relevance, indicates which citations he wishes to see. If the user is in the 
 library where a citation is located, he is given any necessary information to 
 retrieve the document, i.e., call number, shelf title or special location. 
 
 The SUNY system was originally planned to include all circulation records 
 for each member station, and, in that case, the circulation files would also 
 have been checked to determine whether the item was out or otherwise 
 unavailable, in which case a request would have been placed on the record for 
 
ON-LINE TECHNOLOG Y IN A LIBRAR Y NETWORK 
 
 57 
 
 a 
 
 B 
 
 c 
 
 c 
 
 3 
 
 i 
 
 o 
 U 
 
 d 
 u 
 
 c 
 
 z 
 
 a- 
 IL 
 
58 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 the user. For items which were not owned by the user's library an interlibrary 
 loan request in standard telecommunications format was to have been sent 
 automatically to the nearest network station which was able to supply the 
 item; a duplicate copy of that request would have been generated in the 
 interlibrary loan office of the user's library. Prior to this the user was to have 
 been given the opportunity to reject the interlibrary loan segment of the 
 service for each selected citation. 
 
 This service, therefore, tied together the cataloging aspects of the system, 
 circulation, and serials control, and added the journal article citation data 
 from an external source. This type of service begins to approach the "total 
 system" goal toward which libraries have been striving. It eliminates a number 
 of steps for both the user and the library. Gone is the need for the user to 
 copy down his citation from the secondary source and to recopy the citation 
 on an internal interlibrary loan request form after he has determined that his 
 library does not have the item. The library's need to verify the citation has 
 been eliminated since it has come from a verified source and has not been 
 transcribed which might have introduced errors or diluted information 
 content. The step of retyping the verified citation with the attendant 
 possibility of additional clerical error in this third transcription is also 
 removed. In addition, the delays attendant upon these processes within the 
 library are reduced, together with the major delay caused by mailing the 
 request to a library which may be able to supply. It should be noted that 
 since the computer system has already verified the source of supply, the 
 delays caused by repeated efforts to obtain items from libraries which cannot 
 supply are minimized. The net result of this chain of events is a marked 
 increase in the speed of delivery of the document to the requester, a 
 document which will be even more rapidly supplied if telefacsimile equipment 
 is employed. 
 
 This entire process is not a complicated one, and it does not depend on 
 new technology, major reorganization of library functions, or large increases in 
 library budgets. The SUNY network performed all of the necessary program- 
 ming and testing of the required procedures, and the entire system was 
 declared operable in 1969. At that point, the problems which face a library 
 network, but which are unrelated to its technology, became evident. As the 
 librarians of the member institutions were faced with the reality of accepting 
 a larger number of interlibrary loan requests than they had been accustomed 
 to receiving, they balked. The Network Advisory Council felt that the antici- 
 pated avalanche of requests would render normal service in this area unwork- 
 able, thus the automatic interlibrary loan procedure was never tried, even on a 
 limited basis. 
 
 Another use of the bibliographic data base described above is in the 
 verification of requests for interlibrary loan which are not generated through 
 
ON-LINE TECHNOLOG Y IN A LIBRAR Y NETWORK 59 
 
 computer search. Using search options like "title scan," it is possible to verify 
 citations which may be incomplete or only partially accurate. It is not 
 possible to perform an author search of the MEDLARS file on either the 
 SUNY or MEDLINE systems at the present time, although this disadvantage is 
 not as serious as it would be without the printed Index Medicus author index 
 at hand. 
 
 Multiple Data Bases 
 
 One of the principal benefits which can be justifiably expected from computer 
 systems is that which derives from their ability to do repetitive jobs quickly, 
 accurately, and with a minimum of human intervention. Libraries have looked 
 forward to the day when a number of secondary sources could be searched 
 with a single command or search strategy (single in the sense that it needs 
 input only once). Also anticipated was the ability to progress along levels of 
 information in a sequential fashion, depending on the results of the preceding 
 portion of our search. The SUNY network stated this type of search capability 
 as a phase two goal when it was planned in 1966, and the University of Chicago 
 has recently restated that this type of activity is one of its continuing (although 
 unfunded) goals. 
 
 When it is considered what could be achieved for the library user by 
 searching a combination of the data bases available in machine-readable form 
 from Oiemical Abstracts, Biological Abstracts, Excerpta Medico, Science 
 Citation Index, Index Medicus, and a number of other automated publi- 
 cations, it is apparent how far there is to go in on-line or off-line information 
 retrieval, even before the millenium when full texts of documents can be 
 retrieved. If these services were correlated so that the searcher could locate 
 first the bibliographic information, and then the abstracts of articles which he 
 selected, a new level of user service would have definitely been achieved. 
 
 Although the SUNY network is not yet approaching this kind of service 
 capability, it is about to begin an experiment which may finally lead to such an 
 on-line data base. For an experimental period of four months, SUNY will load 
 50,000 citations from the 1971 files of the Drug Literature Index (DLI), 
 published by the Excerpta Medica Foundation. This tool is a hybrid, appearing 
 to be a cross between the bibliographic index and the abstracting service, in 
 that it combines the citation with what might be called a telegraphic abstract 
 comprised of a number of thesaural terms. The DLI provides indexes by drug 
 class, generic name, trade name, author, and a separate listing of new drugs. 
 The citations are somewhat different than those of many other indexes in that 
 the foreign-language titles are first given in English translation, followed by the 
 affiliations of the authors. See Appendix at end of chapter for additional infor- 
 mation. 
 
60 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 The indexing terms used are from a controlled vocabulary called 
 MALIMET (Master List of Medical Indexing Terms), but the DLI also uses 
 what it calls secondary indexing terms. MALIMET consists of some 40,000 
 preferred terms together with see also references and up to five class assign- 
 ments which indicate biomedical fields, subjects areas, or disciplines. In 
 addition to the primary or preferred terms, there are approximately 500,000 
 synonyms which are also keyed to the primary related term. These secondary 
 terms are not those which would normally be used to look up an article but 
 which provide information as to the nature of a given investigation (e.g., 
 anatomical, demographic, or electrophysiological study), the species of 
 experimental animal used, the type of primary document (e.g., review, text- 
 book, etc.) or even quantitative data on the scope of the study and the value 
 of the results (e.g., nineteen patients, result). The sources of the citations are 
 3,400 biomedical journals appearing worldwide, and each monthly index 
 contains about 4,000 citations. The price of this service ($2,000 a year for the 
 twelve monthly issues including two semiannual cumulations) makes it pro- 
 hibitive for most libraries, but the use of the data in a cooperative network 
 brings the information to a number of locations which could not individually 
 afford to obtain it. 
 
 Using the STAIRS operating system developed by IBM, the SUNY 
 network will permit the user to search the file either through the controlled 
 vocabulary or by the use of the secondary, natural language, terms. The in- 
 ternal indexes are constructed as a series of inverted files, and the computer 
 retrieves the citation only after all of the search parameters have been 
 satisfied. This experiment will be monitored closely and evaluated, and the use 
 of the file will be studied by an outside (non-SUNY or network) research 
 team. If this test is successful, the network plans to make available a two-year 
 file of the Excerpta Medico, now published in thirty-nine monthly subject 
 sections, which will also be searchable using the controlled vocabulary or 
 natural language. Excerpta Medico abstracts are English-language summaries, 
 not telegraphic lists of subject headings. This data base would contain 500,000 
 citations, and the abstract words would be arranged internally in inverted files. 
 
 The recent UNISIST Study Report on the Feasibility of a World Science 
 Information System noted the parallel development of MEDLARS and the 
 Excerpta Medico systems and then called for the coordination of the two 
 services in this area in which they closely overlap. Both of the parent 
 organizations have agreed to adopt a common communication format to 
 facilitate the exchange of data and the possible interconnection of the two 
 systems. 
 
ON-LINE TECHNOLOGY IN A LIBRARY NETWORK 
 
 61 
 
 SUNY 
 
 ME DUNE 
 
 
 Citations 
 
 Dates 
 
 
 Citations 
 
 Date 
 
 Medlars files 
 
 
 
 Medlars files 
 
 
 1969- 
 
 on-line 
 
 645,378 
 
 Oct.l967-June 1972 
 
 on-line 
 
 400,000 
 
 June 1972 
 
 off-line 
 
 1,043,114 
 
 1964-1969 
 
 
 
 
 NLM book 
 
 48,000 
 
 1968-1971 
 
 
 
 
 NETBOOK 
 
 15,890 
 
 1962-1970 
 
 
 
 
 DLI 
 
 50,000 
 
 1971 
 
 
 
 
 Total on-line 
 
 
 
 
 
 
 file 
 
 759,268 
 
 
 
 
 
 Table 1. SUNY-MEDLINE Data Bases 
 
 Multiple Networks 
 
 A valid often-raised question concerns the benefit or necessity of having two 
 networks in existence such as MEDLINE and SUNY. Why should a library pay 
 SUNY $8,000 to $10,000 a year when it could participate in the MEDLINE 
 network for the cost of a TWX terminal, which it may already be using? The 
 major reason is that the two networks do not duplicate each other at the 
 present time, and each can do some things that the other cannot. This gives 
 additional power to the library which is able to employ both systems, allows 
 it to provide more services, and, of course, doubles the access of its users to 
 the available data bases. Even as MEDLINE adds additional data bases such as 
 the NLMBOOK files, the networks will not necessarily converge (table 1). 
 Each plans new services and the things that each system is able to do will 
 continue to differ because of the internal operating systems which have been 
 selected. The SUNY Network Advisory Committee has urged the network to 
 select a different type of system for its operation because of the potential 
 that results from testing different methods of doing things, a legitimate 
 function of a university and a capability which might well have been lost were 
 the SUNY network to have turned into a back-up MEDLINE operation. As 
 evidenced by the forthcoming work with the Excerpta Medico data bases, the 
 need for a viable alternative system exists and would benefit the profession in 
 many ways. 
 
 An unresolved problem of on-line systems which does depend on their 
 technology is that which arises when more and more people attempt to use 
 the system simultaneously. A graph produced by the National Library of 
 Medicine (NLM) shows clearly that an important drop in response time occurs 
 when the number of simultaneous users rises from forty-five to fifty-five (fig. 
 2). Considering that there are at least 100 users-some of whom are shown 
 with their use figures in table 2-who constitute NLM's primary population 
 
62 
 
 1972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 ISO- 
 
 160 
 
 MEDLINE 
 
 AVERAGE NUMBER OF USERS 
 
 VS. 
 AVERAGE RESPONSE TIME 
 
 140 
 
 120- 
 
 100 
 
 360/50 
 
 80 
 
 60 
 
 40 
 
 20 
 
 ASSUMES I5MIN. 
 DOWN ON OVERLOAD 
 I I 
 
 20 
 
 25 
 
 30 35 40 
 
 AVERAGE NUMBER OF USERS 
 
 45 
 
 50 
 
 5! 
 
 Fig. 2. How Number of Users Affects Response Time 
 
 (including the medical schools and the regional medical libraries), and that 
 there are plans for extending the service to secondary sites such as hospitals, 
 this is an important factor to consider. Increases in search activity are shown 
 in figs. 3 and 4. 
 
 Although the difference between a response time of 20 seconds and 160 
 seconds may not appear to be great, if we were to stop and wait for those 
 160 seconds to pass it would begin to seem interminable. To the user seated 
 
ON-LINE TECHNOLOGY IN A LIBRAR Y NETWORK 
 
 63 
 
 Z 100 
 
 o 
 
 80 
 
 70 
 
 60 
 
 Cornell and 
 
 Illinois Join 
 
 Network 
 
 Add Mt. Sinai 
 
 12 Locations 
 
 June July Aug Sep Oct Nov Dec Jan Feb 
 
 1971 
 
 1972 
 
 Fig. 3. Average Monthly Searching Activity 
 
 June July Aug S*p Oct Nov Dc Jan Fab 
 
 1971 
 
 Fig. 4. Total Monthly Searching Activity 
 
64 
 
 1 9 72 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 
 OO O 
 
 r- r~ tN wi 
 
 </^ intNC^-^coin f~O OOONVO 
 
 o 
 
 
 * 
 
 fs r- 
 
 ON r- fN u-> 
 
 r- t^vorNTf-oo r-^ VOI^NO 
 
 NO 
 
 
 ^ 
 
 
 (N 
 
 
 r- 
 
 
 
 fr^ 
 
 fN ON CO O 
 
 O OO Vi CO C"! ""^ CO ON CO CO O */> 
 
 CO 
 
 
 1 
 
 NO 00 
 
 r-- r~ o vo 
 
 O OOVOfNONt^OO O^t Tfvo<N 
 
 5 
 
 
 
 +- 
 
 
 r~ wrq- 
 
 ro in-0t-r- -ON v, 
 
 ^ 
 
 
 c 
 
 
 CO OO ON CO 
 
 O t~>/">-""'/">OO NON ^~ 
 
 j*^ 
 
 
 3 
 
 ~ 
 
 04 
 
 *" "* 
 
 (N 
 
 
 
 r 
 
 p-Mt* 
 
 t- cOTT-OOm couo uo 
 
 CO 
 
 
 <j 
 
 <u 
 
 ON 
 
 ON ON 
 
 NO q * co co in ON ON vo 
 
 00 
 
 
 
 ^ 
 
 ON 00 
 
 vo osuocovovoco COO TJ- 
 
 oo 
 
 
 1 
 
 
 fN 
 
 """-"^ 
 
 2 
 
 
 
 fS 
 
 r- o r- 
 
 + 
 
 ON 
 
 
 ^* 
 
 ^H 
 
 t^ OO CN 
 
 00 co vo ^^ vt co NO r*^ ON co 
 
 
 
 O 
 
 ^ 
 
 (N 
 
 
 O 
 
 
 ^ 
 
 O 
 
 -^rs 
 
 ON ~^iy> vovo^ CN^" O 
 
 00 
 
 
 t 
 
 
 
 
 
 
 ON 
 OO 
 
 
 ob 
 
 NO 
 
 TJ-TJ- CO 
 
 "'"^^c^rovo OO 
 
 00 
 
 
 3 
 
 VO 
 
 NO uo -. 
 
 vo <NCO r-cO!- VOON - 
 
 
 
 ^ 
 
 O 
 
 (N NO fS 
 
 co voOfNOvo<N vo-" 
 
 
 
 
 "3 
 
 r- 
 
 vocor- 
 
 ro <N-^<NUO cooo 
 
 TI- 
 
 
 
 
 
 + 
 
 
 
 c 
 
 o 
 
 S CO O 
 
 \O t^ ?) NO JQ ON S? 
 
 CS 
 
 
 ^ 
 
 "" 
 
 ^^ 
 
 
 r- 
 
 
 
 
 H 
 
 * u 
 
 
 
 
 
 
 <0 60 
 
 
 
 
 
 
 Z &" *J > 
 
 
 
 
 o 
 
 !1 
 
 4> M =3 * 
 
 g -"116 eg 
 
 
 'ao 
 
 
 
 
 ^ ^ 
 
 '3 "o 5- 1^, -3 -5 >-J "<3 x 3 . 
 
 
 C 
 
 2 
 
 
 
 k. 
 
 O M *,g 
 
 a> "S *2 " s 3 "** -S '^ 6 
 
 
 CO 
 
 
 G 4) 
 
 *C -2* 4) 
 
 00 i_ M 4> j ^N _* ^ rr ^ gbl ." ^^ 
 
 
 
 
 ^. 
 
 E e 
 
 o ss 
 
 ^W^^>QJ W*QJ>T3 gg >^"^ij.S2^ 
 
 
 
 
 
 "O ^ 
 
 ', ( J5 -^ 
 
 O ^5 O ^ ^3 ^^ *^ '. ^i tn *2 ^^ *i O 
 
 
 w> - 
 
 c 
 
 *"* "" 
 
 Q O ^* -^ 
 
 ^i fe H n&) C* O DQ ^* "i3 ^ ^* C 
 
 
 "* < 
 
 
 
 ?1 
 
 11 
 
 oS. 
 " 
 
 o 2 
 
 O vi 
 
 isla 
 
 !|- 
 
 ^^ V-< ' *- r r 
 
 "*'% a *~ 
 .a S s>- 
 
 "2 - ^ z 
 
 l!fil|i!li||ll 
 
 "S 
 ^> 
 
 2 
 
 5 ! 
 
 1> IU O 
 
 a c 
 
 3 ^J 
 
 111 
 
 
 s ! CO ^ 
 O O C 
 
 
 -"f "fUo-"^ 
 
 
 ill 
 
 
 
 
 ^^ r<<Nrs<N<NCNir>r^ 
 
 
 -_ * 
 
 
 
 
 * * * * 
 
 * * * 
 
 
 * 
 
 v> H 
 
ON-LINE TECHNOLOG Y IN A LIBRAR Y NETWORK 65 
 
 at a computer terminal, who knows that there is a powerful device connected 
 to his station which operates at electronic speeds, a delay of 160 seconds 
 becomes intolerable. We learned very early that the threshold of user 
 impatience when using an on-line system is very low. One can choose to 
 ignore the problem, but one then finds that the system is regarded as 
 unsatisfactory by many, and ignored altogether by others. Driving away the 
 potential user is not the solution to the problem. 
 
 NLM postulates that there may be a need for shifts during which groups 
 of terminals are authorized to use the system; this method of expanding the 
 capacity of the SUNY system was also considered. SUNY has not yet, 
 however, had to face the problem because their terminals still number less 
 than thirty. The system designer must also consider that when the system 
 overloads and fails, it may require fifteen minutes to restore the programs and 
 enable searching to resume. If this happens with any frequency, not only is one 
 faced with the problem of user dissatisfaction, but also with what happens to 
 the data which were being transferred at that time. When dealing with a system 
 other than searching from a file, that is, when entering new data to the 
 system, one does not know, for example, which circulation records were lost 
 when the system dropped without going back and redoing a certain number of 
 transactions at each terminal location-a difficult task if the user's ID card is 
 required as well as the book card, and the user has already left the circulation 
 area. When one is dealing with internal library operations, the problem may be 
 tedious, but no more than that; when the user is involved, however, the 
 problem is far more complicated. 
 
 CASE and CRIB 
 
 The Library of the Health Sciences now has four on-line systems combining a 
 variety of functions and services available for use by the patron. The systems 
 are the SUNY Biomedical Communication Network, the National Library of 
 Medicine's MEDLINE (MEDLARS On-Line) Network, and the University of 
 Illinois at the Medical Center's CASE (Computer Assisted Simulation of the 
 Clincial Encounter) and CRIB (Computer Randomized Item Bank) systems. 
 
 CASE is a unique program which enables the medical student or 
 practitioner wishing to review or test a course of action to select a case study 
 in a particular area from the series available (emergency orthopedics, obstetrics 
 and gynecology, pediatrics, psychiatry, and internal medicine) and proceed 
 with analysis of the problem, diagnosis and treatment. The program provides 
 an introductory description of the patient and other related information and 
 the physician is then able to ask the patient (i.e., the computer) questions, 
 order laboratory tests and review the results, obtain physical information and 
 any other data which he deems significant. After this stage is complete and 
 the physician feels that he understands the case and is ready to proceed, he 
 
66 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 then enters his own diagnosis and treatment of the case. After this is done, he 
 receives the author's diagnosis and treatment plan, and is told what happened 
 to the patient as a result of the course of treatment he prescribed. The system 
 also supplies a list of critical concepts relating to the case which should have 
 been explored and notes whether the physician covered them or not. The user 
 may terminate his interaction with the system at any time by typing the word 
 "quit." 
 
 CRIB is a system designed to allow a student to test himself in a subject 
 to determine his grasp of the material as well as to instruct himself. The 
 subject areas covered by CRIB are: anatomy, dermatology, microbiology, 
 physiology, pathology, histology, pharmacology, medicine and orthopedics. The 
 questions are in multiple choice form and the student is credited with only his 
 first answer, i.e., he cannot change his mind on a particular question after 
 answering it. He can then request the correct answer by typing the word 
 "answer" to see if he was correct. He can skip questions in a series, or 
 terminate his test at any time. The system maintains a record which is 
 available only to the student, so that he can see how he scored on the 
 question group. The system uses a Hazeltine 2000 Cathode Ray Terminal 
 which is connected to the computer using an acoustical coupler and a voice 
 grade telephone line. There are eleven terminals now connected to the system 
 including those in the library's branches in Peoria and Urbana. Terminal 
 access will also be provided in the branch library in Rockford in 1972 when 
 the first class is admitted. 
 
 Plans are also underway for the CASE system to be used through the 
 National Library of Medicine's Biomedical Communications Network using the 
 TYMNET circuits (also used by MEDLINE). 
 
 Coordinated Staffing 
 
 An intriguing area of networking in an on-line mode is that involving the 
 sharing of professional resources. Although this is basically an uncomplicated 
 concept, it is one which has not been applied in an organized program. 
 
 By coordinating staffing patterns, the various stations in a network would 
 be able to provide professional service over a broader range of hours of 
 operation than any one of them could provide alone. In this way, weekend 
 and evening hours, which are usually considered disadvantaged shifts by most 
 staff members, could be distributed among a large group of people. It does 
 not, of course, require a computer system to achieve this type of program. A 
 coordinated staff sharing program can be developed using telephone lines, and 
 the Library of the Health Sciences will be testing the effectiveness of this 
 program using both telephone lines for direct calls to Chicago when a pro- 
 fessional staff member is unavailable in Peoria, and the SUNY terminal, using 
 the computer as a message switching device. One convenient feature of the 
 
ON-LINE TECHNOLOGY IN A LIBRAR Y NETWORK 67 
 
 computer message is that if an addressed terminal is busy, the computer stores 
 the message and transmits it as soon as it can capture the terminal. Messages 
 show the time of input as well as the time of delivery. 
 
 A major problem with this type of service is the human problem of 
 convincing the user to pick up the phone to make the call for assistance, or 
 getting him to sit down and type his message. The use of Picturephone may 
 well be an added inducement to the user to try such a service, and it has the 
 advantage of making the program more personal. Another important feature 
 of Picturephone service is that it enables the professional to place printed 
 copy on the screen for the user to either read quickly or note and removes 
 the disadvantage of much telephone reference work which results from the 
 reading of sections of a book to answer the question. This combination of 
 graphic display and two-way verbal communication has not yet been exploited 
 by libraries; it will be interesting to see what the impact of such service will 
 be. 
 
 STANDARDIZATION 
 
 One would be remiss in discussing network technology without at least 
 mentioning the importance of standardization. The small differences in the 
 ways libraries have recorded information and what information they have 
 required have caused innumerable problems in the development of national 
 data bases. The efforts which went into the establishment of the MARC format 
 were monumental, and the agreement of libraries to use MARC as a communi- 
 cation format has been relatively slow in gaining wide acceptance. The fact 
 that all of the major national library associations have endorsed this policy 
 seems to have made little if any difference. The significance of the term 
 "communication format" should not be lost, for libraries are asked to standar- 
 dize not their internal systems, for which needs differ considerably, but only 
 to provide a common format which will enable the data captured at one 
 location to be used at another. This means, in effect, that each library or 
 computer center need write only one program to convert its data into the 
 standard format and one program to convert MARC format tapes to its 
 internal processing format. 
 
 That standardization should be difficult for libraries is a little strange, 
 since many libraries have standardized their subject heading lists and classifi- 
 cation systems by basing their work on the most common U.S. systems 
 available. But the implied loss of autonomy which standardization means has 
 caused many libraries to resist, and has hindered progress toward a national 
 network or even toward regional centers. 
 
 Nonetheless, networks imply a degree of standardization in both the input 
 to the system, and the techniques used in querying the system. It would seem 
 preferable to be found in the vanguard of such a movement and to assist in 
 
68 1972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 the development of standards, than to be caught in the rear where one may 
 be forced to adopt them for sheer survival. 
 
 On-line technology is the tool which will enable libraries to meet the 
 challenge of providing information services to their constituencies in the 
 1970s, and it is the greatest hope that libraries have for establishing a relevant 
 relationship with their users. 
 
 APPENDIX 
 
 By mid-summer of 1972 the SUNY network had decided not to use theDLI 
 for a test data base, but instead to work with the Excerpta Medico files. 
 
 Plans were made to prepare two to three months of the entire data base of 
 the thirty-nine sections of Excerpta Medico for searching in an on-line mode. 
 Four test centers were selected, John Hopkins Medical Center Library, the 
 Francis A. Countway Library of Medicine (Harvard), the SUNY Upstate Medical 
 Center Library, and the University of Illinois Library of the Health Sciences. 
 
 The network will conduct a comparative evaluative test using both free text 
 and controlled vocabulary searching on the Excerpta Medico file, and using 
 controlled vocabulary searching on the MEDLARS file. Each test center will 
 initiate approximately forty searches and the resultant 160 searches will be 
 performed in each center. After the evaluation of the test data, it is expected 
 that the entire Excerpta Medico file for the most recent two-year period will be 
 loaded into the system and made available to all network stations. 
 
JAMES FAYOLLAT 
 
 Head, Systems Division 
 
 Biomedical Library 
 University of California 
 Los Angeles, California 
 
 On-Line Serials Control at UCLA 
 
 The Biomedical Library at UCLA is the primary library for the UCLA Center 
 for the Health Sciences, which includes the Schools of Medicine, Dentistry, 
 Nursing and Public Health, the hospitals, clinics and institutes, and the Life 
 Sciences Division. The center is one of the largest teaching and research 
 centers of its type. In 1971 it retained 589 full-time and part-time faculty, 
 505 postdoctoral and full-time research appointees, and a support staff of 
 more than 2,500 administrative, technical, clerical and other personnel. 
 
 An important ancillary division within the center is the Health Sciences 
 Computer Facility (HSCF) which has as its primary goal the futherance of 
 biomedical research through the development of the mathematical and 
 statistical methods and the data handling facilities required to enhance such 
 research. One of the most significant products of the facility's interest in 
 developing new uses for its computer is the Terminal Oriented Real-Time 
 Operating System (TORTOS) which allows its user community remote access 
 to the computer via terminals. The computer used by the facility is a large 
 IBM machine, the 360 model 91. 
 
 Within the framework of its environment at the Center for the Health 
 Sciences, the Biomedical Library carries out its objectives of supporting the 
 teaching, research and service functions of the center. The library has approxi- 
 mately 6,500 regular users, chiefly faculty, students and research staff of the 
 schools and departments mentioned. In addition, in the interest of the service 
 
 The work upon which this paper is based is supported by a research grant 
 from the National Library of Medicine, No. LM00739-02. Computing 
 assistance was obtained from the Health Sciences Computing Facility, UCLA, 
 sponsored by NIH Special Research Grant RR-3. 
 
70 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 function of the university, the library extends its services to affiliated hos- 
 pitals and the local health sciences community. Through the extramurally 
 supported Pacific Southwest Regional Medical Library Service and other 
 projects, it provides a variety of sub regional, regional, national and inter- 
 national services. One example of this service is the library's handling of some 
 3,000 interlibrary loan requests per month through the Regional Medical 
 Library Program. 
 
 As is generally the case with libraries in the physical and life sciences 
 fields, particularly in research-oriented institutions, journals and periodicals are 
 the mainstay of the library services. In order to adequately cover the scope 
 and range of materials required by the service function, the library maintains 
 subscriptions to about 6,500 journals. The goal is to collect all important 
 materials within scope which are published throughout the world. 
 
 Recognizing the potential of automation to handle the large quantities of 
 data entailed by our periodical operations, we became one of the first libraries 
 to enlist the use of the computer to manage our files of journal information 
 when the initial efforts at systems design and programming were begun in 
 1963. By 1966 a machine-readable file had been prepared and initial listing 
 and updating capabilities were operational. By the end of 1969 we had 
 developed an integrated card and tape oriented batch process system to handle 
 our check-in, claiming, and binding operations, and in that year published our 
 first annual serials holdings list in conjunction with the Regional Medical 
 Library operations. 
 
 A brief description of the batch processing system will provide the 
 necessary background for a description of the on-line system which has now 
 replaced it. The following figures provide an idea of the activity involved in 
 the batch system: about 150 journals arrived each day to be checked in; every 
 other week over 400 completed volumes were sent to the bindery to be 
 bound; and as many as 100 computer-produced claim letters were processed 
 weekly. New entries due to new subscriptions or changed titles averaged about 
 12 per week; other changes or additions to existing records averaged several 
 hundred per week. In summary, each week at least 15 percent of the records 
 in the file were altered or updated in some way. 
 
 All updates of the type just mentioned were made via punched cards sent 
 into the computer once a week. In addition to the programmer who worked 
 about half time at maintaining and supervising the system, two library 
 assistants working exclusively at the coding, keypunching and other card 
 handling aspects of the system were required to process the work. It should 
 be pointed out that at least one of these two and probably both would in any 
 case have been required to put the manual system into optimum condition 
 and to process the claiming backlog of many years standing. 
 
 Against the computer and equipment costs of $7,542, and the half time 
 programmer salary of $6,000, or a total of $13,542 per year cost, about 
 
ON-LINE SERIALS CONTROL A T UCLA 71 
 
 $15,950 of benefits resulting mainly from increased efficiencies of operation 
 have been calculated in the areas of interlibrary loan, reference services, 
 claiming and binding operations and acquisitions. We estimate that the batch 
 system resulted in a net savings to the library of $2,408 per year, the 
 difference between the $15,950 of benefits and the $13,542 of costs. 
 
 THE PRESENT ON-LINE SYSTEM 
 
 As indicated, the Health Sciences Computer Facility which serves the Center 
 for the Health Sciences at UCLA has an innovative program for developing 
 terminal-oriented facilities and services for its user community. When we 
 became reasonably sure that the facility would be able to provide a general 
 time-sharing system, allowing users to maintain relatively large data bases and 
 allowing several hours per day of access to such a data base at a reasonable 
 cost, we resolved to develop an experimental terminal-oriented system for 
 complete serials control. Our immediate objective was to design an on-line 
 serials control system which would allow us to eliminate all card handling and 
 keep the data base current at all times in all respects. We thereby hoped to be 
 able to reduce the heavy workload of coding and keypunching and to 
 maintain the file on a daily basis. If these objectives could be accomplished 
 we would then be in a position to address ourselves to the important 
 long-range objective of determining the conditions necessary for a system of 
 automated library operations generally. 
 
 All the originally planned facets of the system are now operational and 
 the experiment is no longer an experiment. I will complete the brief analysis 
 of the computer operation costs begun above for the on-line system, and 
 devote the remainder of the paper to the system's operation. Compared with 
 the former batch processing system, the computer charges for the on-line 
 system have gone up from $7,542 per year to $14,280. The difference of 
 $6,738 is almost completely attributable to two factors: rental and usage 
 charges of the cathode ray tube terminals and rental of on-line disk space. The 
 largest category of computer charges is now for disk space, followed in order 
 by the cost of the terminals, listing and paper charges, and finally the central 
 processing unit charges. 
 
 The increase in computer costs is small, however, when compared with 
 the very significant savings totaling $17,425 which we have been able to 
 achieve as a result of converting from the batch to the on-line system. 
 Virtually all coding and keypunching have been eliminated; all data is entered 
 and verified at the source on the terminal. Two full positions have been 
 eliminated and the programmer analyst position reduced from half to quarter 
 time, the latter partly because of decreased supervisory duties, and partly due 
 to the fact that the on-line system runs more smoothly than the former batch 
 system. Time previously used for bindery preparation, updating catalog 
 
7972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 records and maintaining various public service files is now eliminated, 
 representing additional important savings which have been used either to 
 accommodate increase in workloads or for reallocation to other tasks. 
 Increased staff productivity rests on two factors: improvements in tools 
 (terminals and listings) for processing and handling information and improve- 
 ment in morale, especially of nonprofessional staff members who now have 
 greater responsibility and an expanded view of their contributions to the 
 library's overall operation. 
 
 To summarize the cost aspects of going on-line, the savings in personnel 
 are $12,679 and the related savings in binding, cataloging and reference are 
 $4,746 for a total savings of $17,425. Net savings is found by deducting the 
 increased computer costs of $6,738, resulting in $10,687 per year. Combining 
 this with the $2,408 net savings reported above for the batch system, the 
 total is $13,095 of yearly savings over a completely manual operation. These 
 are the measurable direct and indirect savings within the library, but perhaps 
 in some ways more significant are the intangible benefits of better staff 
 morale, greater user satisfaction, and the sharing of products with other 
 institutions. More detail is contained in: "On-Line Serials Control System in a 
 Large Biomedical Library, Part III: Comparison of On-Line and Batch 
 Operations and Cost Analysis." 1 
 
 Lists and Other Products 
 
 The output products of the on-line system are, with minor differences, the 
 same as those of the batch system; the major improvement is in the quality of 
 the output. Because of the decrease in maintenance problems resulting from 
 entry of data at the source, plus visual verification provided by the terminal, 
 the accuracy of the entire operation has been greatly improved. 
 
 The principal product is the daily serials holdings list (fig. 1). It contains 
 the usual data elements of title, call number, frequency of publication, 
 location in the library, complete holdings statement of both bound and 
 unbound issues, and history statement; in addition, certain less usual and very 
 useful elements are included dates on which missing issues were claimed, date 
 on which the latest issue was received, and bindery notes for all volumes sent 
 to the bindery. 
 
 Computer production of claim letters are, of course, a part of this system 
 (fig. 2). Claims are initiated by the computer when an issue is skipped, and by 
 a program which is run periodically to find lagging receipts. The claims 
 assistant checks the selection on the terminal screen before allowing the letter 
 to go out, but the largest part of the work is done automatically; the claims 
 assistant processes more than eighty letters per week in about six hours. 
 
 A large amount of time, mostly in typing, has been saved in the bindery 
 section. Briefly, the computer produces a bindery pickup list to aid in the 
 
ON-LINE SERIALS CONTROL A T UCLA 73 
 
 AUSTRALIAN NATURAL HISTORY. 
 
 Wl AU842 LOAN DESK 
 
 B14- 16 (1962- 68/0) QUARTERLY 
 
 U17N1-2(1971) LAST REC '0-10/2 0/71 
 
 CONTINUES AUSTRALIAN MUSEUM MAGAZINE. 
 
 AUSTRALIAN NURSES 1 JOURNAL. 
 
 Wl AU847 LOAN DESK 
 
 B5M-65(1956-67) MONTHLY 
 
 U66N1- 12 (1968) . LAST REC ' D- 10/30/70 
 
 U68N2-8;AUG.(1970) 
 
 AT BINDERY 66N7- 12, ON SEP 18. 
 
 CLAIMED-- 6 8N1, IN SEP. 
 
 Note: The location of the unbound issues, frequency and date of last receipt are 
 on the right. Note also the "at the bindery" and "claimed" note on the second 
 journal above. 
 
 Fig. 1 . Serials Holdings List 
 
 selection of volumes to be picked up from the shelves for binding, later 
 produces bindery slips (fig. 3) containing the bindery information for the 
 volume, and then runs off the packing list just before the volumes are sent to 
 the bindery. 
 
 Other products of the system include specially formated lists of the file 
 for use by the interlibrary loan department, serials, bindery and catalog 
 departments, as well as a daily receipts list for record-keeping purposes and 
 reorder letters (figs. 4, 5, 6). Upon demand, lists may be produced which 
 utilize certain data elements. In this way a list can be made of journals by 
 subject, language, country or other selection criteria. 
 
 To test potential use of the terminal by reference staff and patrons, a 
 terminal was installed in the reference area for six months and a set of 
 directions assembled to go with it as well as a scheme for reporting usage. The 
 most significant resulting observations are the following: (1) There was a wide 
 range of adaptability in users to the terminal. Many people found it intriguing 
 or "fun," others were quite perplexed and found it difficult to use. (2) The 
 consensus of the reference staff was that until additional data bases become 
 available to be tied to our serials data base, the usefulness of this type of tool 
 is limited. Specifically, the user wants displays of journal articles, together with 
 authors' names and perhaps abstracts. (3) Several users frequently need access 
 to the serials record at the same time; implementing this would mean 
 additional terminals and additional costs. (4) Finally, since terminals are still 
 
74 1 972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 -8- 
 
 FEBRUARY 22, 1971 
 
 GENTLEMEN 
 
 ACCORDING TO OUR RECORDS WE HAVE NOT YET RECEIVED THE FOLLOWING 
 WHICH COMES TO US ON OUR REGULAR SUBSCRIPTION 
 
 CANADIAN JOURNAL OF MICROBIOLOGY. 
 VOL 16 ISSUE 7 (1970) 
 
 PLEASE CHECK REPORT (IF REPORTING ON MORE THAN ONE ISSUE, WRITE 
 NUMBER OR DATE BESIDE REPORT OR CLARIFY UNDER REMARKS. 
 
 WILL SEND IMMEDIATELY: 
 
 WILL SEND WHEN PUBLISHED (ABOUT: WEEKS, MONTHS) 
 
 OUT OF PRINT: 
 
 TEMPORARILY SUSPENDED, VOLUME, NUMBER, DATE OF LAST ISSUE: 
 
 PUBLICATION TO BE RESUMED ON: 
 
 CEASED PUBLICATION: VOLUME, NUMBER, DATE OF FINAL ISSUE: 
 
 REMARKS: 
 
 WE WOULD GREATLY APPRECIATE YOUR SENDING THIS MATERIAL IN ORDER 
 THAT WE MAY COMPLETE OUR FILE. 
 
 OUR MAILING ADDRESS IS 
 
 BIOMEDICAL LIBRARY (SERIALS CLAIMS) 
 UNIVERSITY OF CALIFORNIA 
 CENTER FOR HEALTH SCIENCES 
 LOS ANGELES, CALIFORNIA 90024 
 
 PLEASE NOTIFY US WHAT ACTION YOU ARE TAKING AND PLEASE RETURN 
 THIS LETTER WITH YOUR REPLY. OUR REFERENCE IS 1868800. 
 
 SINCERELY YOURS, 
 
 CLAIMING ASSISTANT 
 BIOMEDICAL LIBRARY 
 
 Fig. 2. Claim Letter 
 
ON-LINE SERIALS CONTROL A T UCLA 
 
 75 
 
 ENTOMOLOGISCHE ZEITSCHRIFT. 
 Ml EN971 
 
 ENVIRONMENTAL HEALTH (LONDON) 
 Wl EN996E 
 
 EUROPEAN JOURNAL OF BIOCHEMISTRY 
 Ml EU726 
 
 YEAR VOL. ISSUE SER NUM PTS/VOL FREQUENCY LOCATION 
 71 81 l-2t 2728SOO 01 SEMI-MO INCOMPLETE 
 
 71 79 1-12 2733900 
 
 INCOMPLETE 
 
 71/2 24 1-3 2782SOO 01 IRREGULAR READING ROOM 
 A. PICKUP LIST (Packing list looks the same except last four columns are omitted.) 
 
 B. BINDERY SLIP. 
 
 03/21/72 VOLS THIS TITLE: 1 
 
 ARCHIVES OF PHYSICAL 
 
 MEDICINE AND REHABILITATION 
 
 1222500 
 
 CLOTH COLOR - BLACK 
 COVERS - BIND FRONT 
 ADS - LAST COPY ONLY 
 INDEX - BIND IN BACK 
 
 52 
 
 JUL.-DEC. 
 1971 
 
 BIOMED. 
 Wl 
 
 AR469 
 V. 52 
 NO. 7-12 
 1971 
 
 Fig. 3. Bindery Products 
 
 relatively expensive, it is difficult to justify them on a cost basis unless 
 constant and highly productive use is made of them. The daily lists have 
 proved to be a much more acceptable method of getting the information to 
 the user than the terminal. The data on the current day's list is virtually as 
 current as that which could be obtained from the terminal; in addition, two-, 
 three-, and four-day old lists left in the reference area provide a multiple 
 access which is impossible with one terminal. To conclude, unless the cost for 
 terminals decreases or larger and more varied files become available containing 
 so much data as to be impractical to list often, a terminal for public use of 
 this type is not practical. The great usefulness is for the input process and for 
 various technical processing procedures for which the serials staff are respon- 
 sible. 
 
 Parenthetically, the reliability of the computer system is a very important 
 factor in determining the usefulness of any termianl system. The test 
 mentioned above was done during the latter half of 1970 when the computer 
 facility was having certain difficulties with both its software and hardware. 
 Although this was an annoyance at the time, we believe the basic conclusions 
 mentioned above would have been the same even with a more acceptable 
 computer system. Since that time the reliability of the system has greatly 
 improved. 
 
76 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 0003600 ACCMA BULLETIN. (ALAMEDA- CONTRA 
 COSTA MEDICAL ASSOCIATION) . Wl AL182 
 (GIFT) 
 
 000600 ADM. REVISTA DE LA ASOCLACION DENTAL 
 MEXICANA. Wl A389 (GIFT) ORG123 
 
 A. List used in bindery dept. 
 
 0006900 1 MIC- 12 FREQ- 1 RT/LOC-B S 
 A.E.T.F.A.T.-INDEX. Z S356 S7 A113 
 B (1953- 56). B(19S9- 67) U (1968)0(1969) 
 U(1970) 
 
 0023400 1 MTC-12 FRQ- 1 RT/LOC-B RFR 
 AMA DRUG EVALUATIONS. QV 740 A2S4 
 B(1971) 
 
 B. List used in serials dept. 
 (list used in interlibrary 
 loans and cataloging have 
 a similar format) . 
 
 Fig. 4. Internal Lists 
 
 BIOMEDICAL LIBRARY 
 
 CENTER FOR THE HEALTH SCIENCES 
 
 UNIVERSITY OF CALIFORNIA 
 
 LOS ANGELES, CALIFORNIA 90024 
 
 FEBRUARY 12, 1972 
 
 CALIFORNIA DEPT. OF FISH AND GAME 
 mi6 NINTH ST., 12TH FLOOR 
 SACRAMENTO, CALIF. 95814 
 
 GENTLEMEN: 
 
 PLEASE CONSIDER THIS A FORMAL PURCHASE ORDER FOR THE FOLLOWING: 
 
 ANNOTATED BIBLIOGRAPHY OF RESEARCH IN ECONOMICALLY IMPORTANT 
 SPECIES OF CALIFORNIA FISH AND GAME. SUPPLEMENT. 
 
 ISSUE 7 
 
 PLEASE INVOICE US IN TRIPLICATE. 
 
 IF THIS PUBLICATION IS NO LONGER AVAILABLE, OR WILL BE 
 AVAILABLE AT SOME FUTURE DATE, PLEASE LET US KNOW AS SOON 
 AS POSSIBLE. 
 
 OUR REFERENCE IS 1075800-9 
 
 PLEASE RETURN THIS LETTER WITH YOUR REPLY. 
 
 THANK YOU FOR YOUR ASSISTANCE IN BRINGING OUR RECORDS UP TO DATE. 
 
 SINCERELY YOURS, 
 Fig. 5 . Reorder Letter 
 
ON-LINE SERIALS CONTROL A T UCLA 
 
 77 
 
 TITLE 
 
 AMERICAN JOURNAL OF MEDICINE. 
 AMERICAN JOURNAL OF OPHTHALMOLOGY. 
 AMERICAN JOURNAL OF OPHTHALMOLOGY. 
 AMERICAN MEDICAL ASSOCIATION JOURNAL. 
 AMERICAN PSYCHOLOGIST. 
 ANTIOQUIA MEDICA. 
 
 CALL NUM. 
 
 YEAR VOL. ISSUE FREQUENCY LOCATION 
 
 Wl 
 
 AM1926 COP. 2 
 
 1972 
 
 52 
 
 1 
 
 MONTHLY 
 
 READING 
 
 ROOM 
 
 Wl 
 
 AM49S9 
 
 1972 
 
 73 
 
 1 
 
 MONTHLY 
 
 READING 
 
 ROOM 
 
 Wl 
 
 AM49S9 COP. 2 
 
 1972 
 
 73 
 
 1 
 
 MONTHLY 
 
 READING 
 
 ROOM 
 
 Wl 
 
 AMSSt 
 
 1972 
 
 219 
 
 "* 
 
 WEEKLY 
 
 READING 
 
 ROOM 
 
 Wl 
 
 AM67W 
 
 1972 
 
 27 
 
 1 
 
 MONTHLY 
 
 READING 
 
 ROOM 
 
 Ml 
 
 AN87S 
 
 1971 
 
 21 
 
 6 
 
 10 PER YR 
 
 LOAN DESK 
 
 Fig. 6. Daily Receipts List 
 
 Hardware and Software 
 
 The system was orginally designed to work from IBM 2260 cathode ray tube 
 (CRT) terminals with a display area of eighty characters across by twelve lines 
 down. Selection of terminal was made on the basis that the IBM 2260 was 
 available and supported by the computer facility. Plans are currently under- 
 way to allow general use of the system with other types of CRT terminals, 
 although there are two major constraints: (1) unless a great deal of reprogram- 
 ming was done, the screen size would have to be eighty characters across to 
 accommodate the displays which the programs sets up; and (2) the data 
 transfer rate would have to be fairly rapid since most displays entail several 
 hundred characters. 
 
 The programs are all written in PL/1 and both the programs and the data 
 file have been designed for use on a large time-sharing computer system such 
 as exists at the Health Sciences Computer Facility. The on-line programs 
 presently run in a 100K region which is dynamically rolled in and out of 
 memory onto drum storage space by the operating system. All programs 
 which run the terminal are linked together into one large program so that 
 they are immediately available for use at all times. Taken together, the 
 amount of memory required for these programs greatly exceeds 100K, but by 
 using overlay programming techniques only a small amount of programming 
 code is in memory at any one time. Considering the overhead required for the 
 terminal system, however, it would appear that 100K, or perhaps 80K at the 
 least, defines the practical size of memory required to run such a system. 
 
 The machine files are set up in one physical file of about 930 tracks on 
 an IBM 2314 disk pack. This is about 7 million characters of storage and is 
 less than one-fourth the capacity of one disk pack of this type. All journal 
 records are in alphabetical order and arranged by the unique access-serial 
 number assigned to them when cataloged. Thus the tracks which contain the 
 master file of data may be thought of in much the same way as a block of 
 records in a sequentially organized tape file. However, with a block of records 
 
78 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 on tape no updating of that tape can be made without copying it onto 
 another tape; with the disk file the potential exists for in-place updating. This 
 capability, of course, lies at the heart of the on-line file maintenance system. 
 
 Not all tracks on the disk file contain the master serials file data, 
 however. Certain tracks have been formated for storage of the retrieval data, 
 others for bindery, claiming and daily receipts data, and so on. There are nine 
 special purpose logical files in all which are maintained in a dynamic fashion 
 by the programs, all contained on the 930 tracks allocated to the serials' 
 control system. 
 
 The master file of serials consists of the 6,500 current journal records, 
 one for each title, together with about 5,500 ceased, on-order and cross- 
 reference records. The record format is somewhat similar to MARC II in 
 concept, containing an average of about eight taged variable length fields and 
 normally two fixed length fields. The records average about 400 characters in 
 length. When the records are blocked together on the disk tracks, a slack of 
 about 600 characters is left at the end of each track. Thus, during daily 
 operations at the terminal causing the length of various records to change, 
 extra space is available as needed from this slack area. Once or twice per 
 month the whole file is regenerated on disk to evenly redistribute the slack 
 area. A more detailed account of the file maintenance concepts is contained in 
 "On-Une Serials Control System in a Large Biomedical Library, Part I: 
 Description of the System." 2 
 
 Retrieval Features 
 
 The system utilizes an inverted file for its primary retrieval technique. About 
 sixty tracks of the disk have been reserved for storage of the inverted file 
 data, which index all title words of significance, and all subjects, languages, 
 and countries to the appropriate records in the master file. This is about 7 
 percent of the total of the 930 tracks which are allocated to the serials 
 system. 
 
 The file is set up as follows. A program reads each master file record and 
 breaks out all words in the title. The program discards some twenty 
 commonly occurring articles and other insignificant words, and also truncates 
 all words containing over fourteen characters. At the same time, the program 
 processes all the subject, language and country codes. To each of these 
 resulting retrieval elements it adds the journal's serial number. The program 
 then sorts the entries found for all the titles by term and by serial number. 
 The last step consists of removing all duplicated terms but one, while saving 
 the serial numbers which provide the link back to the master record in a 
 string and storing the result on the disk space reserved for this purpose. This 
 whole procedure is repeated perhaps once monthly since dynamic updating of 
 this file is not provided for in the present system. 
 
ON-LINE SERIALS CONTROL A T UCLA 79 
 
 The operator who uses the terminal to retireve a journal may key in one 
 or more words of the title of the desired journal. Over 50 percent of all 
 resulting terms in the inverted file have only one title linked to them, so an 
 operator with some experience can very often key only one word to retrieve a 
 unique title. Tests have determined that the correct title is reached about 80 
 percent of the time if an average of three title words are entered. When a 
 unique title is not reached, the operator normally has a list of from two to six 
 titles displayed which have satisfied the keyed search criterion; normally the 
 correct title is among the list and it is a simple matter to pick it out. 
 
 When more than one term is required to find the desired title, the terms 
 may be entered one at a time, waiting for a response each time, or more likely, 
 the terminal operator will key in several terms at once so the program need 
 not keep displaying intermediate results. In either case Boolean anding is 
 performed automatically as long as title words are entered. If the operator 
 should wish to search by subject, language or country, a similar sequence 
 takes place except that the program does not automatically assume Boolean 
 anding, but rather gives the operator the choice of AND, OR, or AND NOT. 
 
 In addition to retrieval by use of the inverted file, the operator may, of 
 course, use the seven-digit accessions number if it is available. This method is 
 slightly faster because it guarantees a single response every time. Most of the 
 bindery and claiming operations entail using a computer-generated list which 
 has the serial number printed on it, so this method of retrieval is often used 
 in these instances. 
 
 The following points should summarize some of the more important 
 aspects of the retrieval scheme: (1) the method of setting up and using the 
 inverted file described above has proven to satisfy the retrieval requirement 
 from a design point of view. It is not particularly expensive nor difficult to 
 maintain. It is easy to use and is sufficiently accurate to be readily understood 
 and accepted by operators of the terminals. (2) Certain features of the 
 concept have useful side effects. For example, transliteration of a title can be 
 accomplished by simply transliterating the easiest word, keying it in and 
 letting the computer display the journal or journals found. The operator 
 should recognize the correct title and can proceed to copy the rest of the 
 transliteration of the title. (3) Since the words may be truncated when keyed 
 in by the terminal operator, it is often a simple matter to key in merely a few 
 letters of a word to retrieve the correct title. (4) Also, related to the 
 transliteration problem, a particularly obscure journal may be retrieved by 
 merely keying in its language or country rather than the title. Finally, any 
 misspelling in a title is soon discovered when this method is used for retrieval. 
 Further discussion of the retrieval aspects of the system is given in "On-Line 
 Serials Control System in a Large Biomedical Library, Part II: Retrieval 
 Features." 3 
 
80 1972 CLINIC ON APPLICA TJONS OF DA TA PROCESSING 
 
 Terminal Operations 
 
 As indicated above, the on-line system has a complete complement of check- 
 in, bindery, and claiming modules. In addition, there are programs to change 
 all fields of a record and to add or delete whole records. There is also a set of 
 system control routines which are used by the systems staff to display and 
 monitor the files in the system. Several special purpose file updating capa- 
 bilities are provided for the programmer's use in this set of routines. 
 
 At the present time there are two terminals; their combined usage of 
 approximately seven hours per day is broken down as follows: (1) four hours 
 checking in an average of about 150 journals, (2) one hour each for bindery, 
 claiming, new entry and other miscellaneous use. Additional time should be 
 allowed for development work by the systems staff and for giving demon- 
 strations. Scheduling the workload would probably become a problem if only 
 one terminal were available since computer downtime, both scheduled and 
 unscheduled, averages perhaps an hour a day, and since the various terminal 
 operations are often done by different members of the staff on different 
 floors of the library. We have not, of course, hired special operators for the 
 terminal. Members of the staff use the terminal as a tool just as they use the 
 telephone or typewriter. The operation of the terminal is relatively straight- 
 forward and only a short time is needed for operator training. For new 
 personnel, use of the terminal is a minor aspect of their normal job training. 
 Library interns, for instance, become reasonably competent at the check -in 
 aspects after one day of working with the check -in person. The great 
 advantage of a CRT-type terminal is that normally all response codes to a 
 given frame can be displayed: the beginning operator merely takes cues from 
 the displayed message to proceed to the next message, and so on. 
 
 The serials control system described above has been fully operational for 
 many months. Although it is fairly large and complex, it has proved to be 
 quite manageable, and, most important, meets our library needs in the area of 
 serials control. Most heartening is the fact that the system has shown definite 
 cost advantages. The computer facility is admittedly subsidized to a certain 
 extent by the federal government on the basis that it is a research facility, 
 but even with somewhat higher computer costs, we believe the system could 
 justify itself. 
 
 Finally, although no further developmental work is now being done on 
 the system, we do have plans for future improvements including the addition 
 of an invoicing module, redesign of the file format to save disk space, and 
 generalization of the system to be able to use a terminal other than the IBM 
 2260. These and other improvements will be predicated on two con- 
 siderations: (1) improving the cost -benefit ratio of the system within the 
 library, and (2) making the system more easily adaptable for other libraries. 
 
ON-LINE SERIALS CONTROL A T UCLA 81 
 
 REFERENCES 
 
 1. Fayollat, James. "On-Line Serials Control in a Large Biomedical Library, 
 Part III: Comparison of On-line and Batch Operations and Cost Analysis." 
 
 2. "On-Line Serials Control in a Large Biomedical Library, Part I: 
 
 Description of the System." 
 
 3. "On-Line Serials Control in a Large Biomedical Library, Part II: 
 
 Retrieval Features." 
 
 These papers were all recently submitted to the Journal of the Society for 
 Information Science for consideration for publication. 
 
JOSEPH T. PAULUKONIS 
 Director, Karl E. Mundt Library 
 
 Dakota State College 
 Madison, South Dakota 
 
 On-Line Real-Time Self-Service 
 Circulation at Northwestern University 
 
 Before discussing circulation, some background on the situation at North- 
 western University might be in order. In the first half of 1967, a detailed 
 study of all the library's operations was made because it was obvious that 
 some changes were necessary. Over the years, many procedures had degene- 
 rated and were now being done primarily because they had been done that 
 way before. The results of the study indicated that a new approach was 
 needed; a completely integrated system should be developed and maintained. 
 It was further apparent that only a system that was efficient and responsive 
 would have substantial impact on the library's operations. Only one direction 
 appeared to provide a possible solution an on-line, real-time system. 
 
 Design and development of a completely integrated library operating 
 system was to be done in modules; the first to be tackled was circulation. The 
 major intent of the circulation module is to maintain control over those items 
 in the circulating collection which are not in the location described in the 
 card catalog. The circulation department as a whole is certainly interested in 
 every item put out by technical services, but the computer-based circulation 
 system is involved only when an item is removed from its assigned place for 
 more than casual browsing or normal in-house use. At that point, a record is 
 created indicating the item in question, the user (student, faculty member, 
 department, another library, cataloger, or the bindery), the date on which this 
 transaction took place, and the date of the end of the particular loan period. 
 If a question should arise about a particular book, the file can be interrogated, 
 the record displayed, and certain changes made, if necessary. Upon return of 
 the book, the record is deleted from the file and the item returned to its 
 
ON-LINE CIRCULA TION A T NOR THWESTERN UNIVERSITY 83 
 
 proper location. Certain other housekeeping chores are accomplished over a 
 period of time, such as overdue notices, fine notices, or requests to return a 
 book. 
 
 The heart of the system is an IBM 360-30 computer which is shared with 
 the university's administrative data processing department. It has a core 
 memory of 96K, with the library teleprocessing system utilizing a 48K 
 foreground partition. The circulation file is maintained on IBM 2311 data 
 cells. The computer is located in an administration building about one-half 
 mile from the library. Two dedicated phone lines are used to connect the 
 computer with the various terminal equipment in the library. This terminal 
 equipment will be described in more detail below. 
 
 The teleprocessing and batch programs are written primarily in assembly 
 language. The teleprocessing package, in addition to circulation, also handles a 
 complete technical services operation. Implemented early in 1972 this part of 
 the system covers all types of material at all stages of processing, from 
 preorder searching of MARC records to production of punched book cards for 
 the circulation module. 
 
 One of the major considerations in designing the module was deciding on 
 the means to collect the book data. Either the data are reconstructed each 
 time the book is presented for charging, or data are carried in machine- 
 readable form by the book. In the former case, manual transcription can lead 
 to many errors, and, depending on the type of data involved, it can be 
 time-consuming and/or difficult to construct accurately. In the latter case, 
 machine-readable data can be used over and over again, will not vary from 
 time to time, and can be ready very quickly by a machine. 
 
 At Northwestern the use of at least the call number for book identifi- 
 cation was anticipated. Although the classification number is generally 
 straightforward (the Dewey Decimal classification system is used), such 
 elements as Cutter letter and number, work letter(s), and the edition, volume 
 or copy, can become fairly complex. Also, in a collection of more than one 
 million volumes, many items differ in call number by only one or two cut of 
 twenty or more characters. Almost everything seemed to indicate that a 
 punched book card was necessary. Once this decision was made, it became 
 necessary to determine the data elements to be converted and the way in 
 which the book cards should be prepared. 
 
 A survey of the literature led to the conclusion that there were two ways 
 of approaching the problem: (1) convert-as-you-go, that is, make book cards as 
 books circulate, or (2) convert-at-one-time, prior to implementation. An 
 interesting discovery concerning the as-you-go method of converting as books 
 circulate was that its major proponent gathered data in the very libraries in 
 which we are working. Unfortunately, no actual cost comparisons were made. 
 While several approaches were mentioned for the one-time method, there are 
 very little data of value. 
 
84 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 Another conclusion that rapidly became obvious was that little, if any, 
 consideration was being given to the need for the presence of certain data 
 elements in the punched card and/or the circulation file. Identification of a 
 book by call number and/or accession number, and some or all of the author 
 and title seemed to be taken for granted. Where this was not so, no reason 
 was given for the particular data elements used or omitted. Answers for many 
 of our questions were not in the literature. 
 
 The data elements to be converted were given first consideration. Since 
 the items to be controlled are normally shelved and retrieved by call number, 
 this would be the most direct means of identification. Also, the call number is 
 unique; only by error would two or more items have the same one. 
 
 An accession number would also be unique, but in looking for a particular 
 book it would become necessary to utilize both the accession number and the 
 call number which would be both cumbersome and redundant. Also, if the 
 circulation file were ever to be analyzed in terms of usage of parts of the 
 collection, the accession number would be meaningless. To use only the 
 author and/or the title would introduce some sticky problems: it is not always 
 easy to determine the exact author and title of a book; these data fields 
 would often be longer than either the call number or the accession number 
 and therefore more difficult to reconstruct accurately; it would be difficult to 
 distinguish between multiple copies, volumes or editions; and foreign 
 materials, especially items in Russian, Chinese or the like, could not be 
 handled in the original language. Again, analysis of the file would be most 
 difficult. 
 
 It became evident, then, that use of the full call number was the absolute 
 minimum. But was it sufficient? Admittedly, it would be "nice" to have at 
 least some portion of the author/title data available in the book card and in 
 the circulation file. This is especially true since the major use of such data 
 would be for printed notices (overdues, fines, etc.) sent to users. Obviously 
 there would be increased (one-time) costs in converting more than the call 
 number. Carrying these extra data fields in the file would also increase the file 
 size by at least one-third but this would be an ongoing increased cost. 
 Would these increases buy more than something "nice"? 
 
 A look at the library's records indicated that less than 5 percent of the 
 items that circulated required any kind of follow-up other than discharge. 
 Those increased costs, then, would be magnified in terms of a percentage of 
 usefulness. Also, if a more complete bibliographic conversion was ever 
 attempted, such partial data would not be usable. Since no estimate of the 
 increased costs due to conversion could be made at the time (the increased 
 file costs could be estimated), no final decision was made only a temporary 
 one to forego author/title during a comparative study to be undertaken. 
 
 While it was estimated that convert -as-you-go was cheaper, the library 
 staff was not anxious to live for an extended period under two systems. It 
 
ON-LINE CIRCULA TION A T NOR TH WESTERN UNI VERSITY 85 
 
 was felt that while living under two systems the best features of either, 
 especially the new one, would be terribly overburdened by the poorest 
 features of either, especially the old one. It was decided to run a short 
 experiment in order to determine the best and cheapest method for one-time 
 conversion. 
 
 Two alternative methods were chosen for study: (1) keypunching directly 
 from the shelflist, and (2) typing sheets, directly from the shelflist, to be 
 scanned later by optical character recognition (OCR) equipment and converted 
 via computer to punch cards. 
 
 Because of the constraints imposed by the scheduled implementation date, 
 very little time was available for rigorous experimentation. While work con- 
 tinued on design of the system, from two to four hours a day over a period 
 of seven days were devoted to the testing. We felt that the results would at 
 least be indicative of the real costs. 
 
 Keypunching, though requiring a somewhat longer period of time, 
 appeared to be the cheapest method. (OCR was less expensive until the 
 computer time for producing the cards and subsequently running them 
 through an interpreter was included.) Use of keypunch machines could also 
 permit a complete in-house operation and would allow day-to-day control over 
 the final product. Moreover, the testing indicated that error rates in the OCR 
 method might be significantly higher, since it was more difficult to read the 
 typed sheets than the punched cards (due to the OCR input being encoded in 
 a manner that made proofreading difficult). The question of adding author/ 
 title data was reopened at this point. Indications were that an additional 
 $50,000-$60,000 would be needed it these two elements were to be included 
 for each record. The call number would have to suffice, and an in-house 
 keypunch operation would produce the book cards. 
 
 The major portion of the operation, conversion of the items in the main 
 stack collection, took sixty-four days. Some 700,749 cards were produced at 
 an average cost of 1.1 cents per card, with the costs broken down as follows: 
 operators $4,200 
 
 equipment (4 IBM 029 keypunches) 960 
 
 card stock 980 
 
 supervisor 1,600 
 
 $7,740 
 
 The keypunching operation was then reduced in scope, other smaller 
 collections were converted, and all new items were routinely routed through 
 keypunch prior to shelving. An effort was subsequently made to put the cards 
 into their respective books. By the time the circulation module was put into 
 operation, over 800,000 books were ready to go. For about $30,000, or just 
 under $0.04 per book, machine-readable cards were prepared and placed in 
 the books, and a general inventory had taken place. 
 
86 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 Part of the decision to use punched book cards was, of course, related to 
 the availability of equipment to read the cards. IBM 1031 badge/card readers, 
 while far from ideal, were found to be at least usable. As used at North- 
 western, these units are one-way machines; they simply transfer data from the 
 library to the computer. Associated with each badge/card reader is an IBM 
 1033 printer. Essentially a Selectric keyboard, this too is a one-way machine, 
 strictly under computer control and only capable of printing out a small 
 variety of messages. The current configuration in the main university library 
 consists of four of these 1031/1033 units. Units are located on the third, 
 fourth and fifth floors of the university library. They are used exclusively for 
 the processing of standard book loans. A standard loan implies a book with a 
 punched card, a user with a punched identification badge, and a normal loan 
 period, currently four weeks. If any one of these three criteria is missing, the 
 user must go to the main circulation desk. The 1031/1033 unit located there 
 is slightly different the badge/card reader also contains a set of twelve slides. 
 These slides allow a variety of transactions to be processed. The only necessity 
 is a punched card with the book information. The slides can then be set to 
 provide for any one of several loan periods and also for user identification if 
 no badge is available. 
 
 The major functions of the unit at the main circulation desk are to handle 
 renewals and discharges. The discharges amount to about 1,000 items per 
 average day, with peak periods during the year being several times this figure. 
 
 For each transaction processed through the unit (in all but two special 
 cases), a message is printed out on the associated 1033 terminal. There are six 
 basic messages currently in use. The most common is the date due. If an 
 attempt is made at a first time charge, and if the data input through the 
 terminal are acceptable (a valid call number which is not already in the file, 
 and a valid user number, by badge or through the slides), a message will be 
 quickly printed, showing the user number, the date due and the call number 
 of the item. This message is then removed from the terminal, placed in the 
 book, and is the user's pass to borrow the item from the library. 
 
 If, however, any of a variety of factors are not as they should be, another 
 message will be printed. In place of the due date will appear UNPROCESSED 
 ERRXX. If this occurs at one of the units in the stack area, the user should 
 take his material and the printed slip to the main circulation desk. The staff 
 at the main desk can then, hopefully, discern the reason for the error message 
 and make the proper adjustments. The types of errors that can occur, and 
 that can be "caught" by the program will be discussed below. 
 
 The third type of message is actually very similar to the first type, the 
 date due. It occurs when an item is renewed. In lieu of the words DATE 
 DUE, RENEW TO is printed, and the new date is calculated by adding the 
 same length of loan period as in the prior transaction to the current date due. 
 Thus, an item may be renewed any time after the initial transaction up to and 
 
ON-LINE CIRCULA TION A T NORTHWESTERN UNIVERSITY 87 
 
 including the third day after the date due. Beyond that date, special handling 
 is required. Also, an item may be renewed only three times; the fourth 
 attempt will be rejected. If so desired, either situation, overdue by more than 
 three days or over -renewed, can be circumvented by simply discharging the 
 item, then starting the cycle anew with an initial transaction. 
 
 The fourth type of message is also similar to the first type. It indicates 
 that the charge is to a carrel and for an indefinite period (in reality, for a 
 quarter). Faculty and students who have assigned carrels have this privilege. 
 The item, however, may not be taken from the library. The word CARREL 
 printed in place of the due date indicates this to the user and to the exit 
 attendant. 
 
 The fifth and sixth types of messages occur when a book is discharged, a 
 simple operation which entails running the book card through the badge/card 
 reader after setting the appropriate slides. In the usual situation, no message is 
 printed when an item is discharged, even if a fine is to be assessed. Fine 
 notices are generated by the evening batch runs. However, if another user has 
 requested that a save, or hold, be placed on an item so that he may have it 
 next, at the time of discharge a message is printed with the identification 
 number of the requester, the call number of the item, and the words SAVE 
 REQ. The item is then put on a special shelf, and the batch program that 
 night prints a notice for mailing that the item is available. 
 
 The fifth type of message occurs when an item that has been determined 
 to be lost or missing is attempted to be discharged. Lost or missing items are 
 routinely put into the master file so that, for example, if a lost item suddenly 
 popped up, the borrower who had reported it lost and probably incurred a 
 fine may be at least partially reimbursed. The message in this case reads 
 LOST/MSG. 
 
 The second type, the error message, covers a wide variety of situations 
 including: 
 
 1. record already in file such as books returned to the stacks before being 
 discharged or attempted renewals on the units located in the stack areas, 
 
 2. invalid record length-including book cards without sufficient data or 
 dropped digits on user numbers entered on the slides, 
 
 3. invalid charge code-e.g., attempt to give indefinite loan to regular 
 borrower, 
 
 4. invalid user number for expired badges, 
 
 5. cannot renew overdue, 
 
 6. cannot renew already three renewals, 
 
 7. cannot renew save on file, 
 
 8. record not in file-for attempted renewal of item not yet charged out or 
 discharge of item not charged out, 
 
 9. record being processed by another terminal, 
 
88 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 10. user number in hold list a small list of numbers can be put into a special 
 hold list, such as users with large unpaid fines or lost badges, 
 
 1 1 . expired badges, 
 
 12. attempted transfer of noncarrel charge carrel charges, to a room or desk 
 number, can be transferred to a user for outside borrowing, and 
 
 13. invalid transaction date in slides it is possible, for example, to have books 
 discharged as of an earlier date (because of backlogs or machine down- 
 time) and dates outside a given range rejected. 
 
 The conditions which generate the foregoing messages are usually easily 
 taken care of by the circulation department staff. Certain other situations- 
 system errors entail a stop of operations and consultation with the computer 
 operator or the programmer. 
 
 The instances where no messages are printed are when a valid discharge 
 takes place and when items charged out do not require date due slips, such as 
 books being put into the reserve room. Suppression of such unnecessary 
 messages saves a great deal of machine and operator time. 
 
 While most error conditions are caught by the system program, there are, 
 of course, some errors that cannot be caught. If a book card or a user badge 
 has transpositional errors, that is the way the data go into the record. Once 
 the record is created, the only way to "see" the data therein is through the 
 IBM 2740 typewriter terminal. There are no hard copy listings of the circ- 
 ulation file. Access to the file can be made only by call number. It was 
 decided that in an academic environment it was most important to know the 
 status of a particular item, what was had by whom, rather than who had 
 what. 
 
 For purposes of searching the file, the call number was broken down into 
 two components, the key and the key extension. The key is made up of the 
 Dewey number, Cutter letter and Cutter number, and work letters (these 
 identify different works by the same author on the same subject). The key is 
 used to compute the address on the data cell where the record is stored. The 
 key extension carries such data as edition, volume, copy, location and oversize 
 indicator. The file can be searched using just the key. This allows for quick 
 access to, for instance, all records in the file for multiple copies of the same 
 title. It also can provide for the display of fifteen records when fifteen 
 volumes of a set are charged out which is a bit inconvenient at times. But this 
 is far overshadowed by the problems that can occur in attempting to properly 
 interpret some of the strange alphanumerics that can be assigned beyond the 
 basic subject, author, title code: copies of volumes of parts of sections of 
 editions, etc. It is far easier to see whether what is in the file fits the question, 
 rather than vice versa. 
 
 It is, of course, possible to go directly to a record by using both the key 
 and the key extension. Either approach has it benefits and drawbacks. 
 
ON-LINE CIRCULA TION A T NORTHWESTERN UNIVERSITY 89 
 
 There are two levels of searching the file. The first uses the search 
 command with the key, and the response, assuming one or more such records 
 reside in the file, gives the address of the record(s) and the key extension(s). 
 Then the desired record can be displayed by indicating the desired record 
 address. This is done primarily because the 2740, being a typewriter terminal, 
 is a very slow device one line of record location is much quicker to print 
 than three or more lines of record data. The other level is to use the display 
 command and both the key and key extension. In either instance, the 
 terminal operator has a choice of displaying the entire record, or any part of 
 it. This particular approach may not be absolutely necessary to the circulation 
 file where most records contain only three data fields. However, the same 
 command language is used in the technical services module, and records in 
 that file are larger. 
 
 It is possible, once the record is displayed, to alter the record by changing 
 or adding another field. In fact, the entire record can be deleted from the file. 
 Since operations through the 2740 do not go through all the error screening 
 routines of the circulation program, care must be taken to avoid entering 
 significant errors into the record. To help guard against such possibilities, 
 there are three distinct levels of operator capability, controlled by operator 
 codes. The lowest level allows only for display of records. The middle level 
 additionally allows for changes of certain fields and addition of others. The 
 top level allows for all activities, including deletion of records. The deletion of 
 a record through the 2740 completely removes it. Discharge through the 
 1031, meanwhile, if overdue or carrying a save, removes the record from the 
 master file to a daily transaction file, against which the batch programs are 
 run each evening. 
 
 Each evening, except Friday and Saturday, the daily batch programs are 
 run. These programs, which generate notices regarding fines, recalls, and book 
 availables, are run agains the transaction file. This file is generated during the 
 period between batch runs. When an item is discharged, the record is removed 
 to the transaction file, and whenever a record is altered at the 2740 terminal 
 in such manner as to necessitate a notice that record is also copied onto the 
 transaction file. The notices are delivered to the library the following morning, 
 where they are stuffed into envelopes and mailed. 
 
 There is no continual machine follow-up on fine notices. The original 
 notice is a four-part form; after the initial mailing, the three remaining parts 
 are used for manual follow-up, if necessary. The notice that a book that had 
 been requested is not available is a one-time thing. If the book is not picked 
 up within a reasonable time, it is returned to the stacks. The recall or 
 book-needed notice, is followed up, but as part of the weekly overdue run. 
 
 Once each week the overdue program is run against the master circulation 
 file. Items usually have a four-week loan period, though there is a built-in 
 capability of making loans for two, four, six or eight weeks, and indefinitely. 
 
90 1 972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 Notices are thus prepared for items based on the due date, provided they fall 
 within a certain number of days of overdueness; for example, first overdues 
 are more than four but less than twelve days and final overdues are more than 
 thirty-two but less than forty days overdue. On a two-week cycle, then, 
 following the initial notice, overdues are automatically followed up. 
 
 In the case of faculty (who are not subject to fines), items are charged to 
 them for the regular loan periods, but no overdue notices are prepared, except 
 for recalls. At the end of each quarter, a listing is sent to each faculty 
 member indicating the items still charged to him. 
 
 Also on a quarterly basis, listings are generated for items on indefinite 
 loan. This includes charges to departments, such as cataloging or reserve room, 
 and to carrels. Also included are those items charged to lost or missing. Thus 
 all items in the file are completely followed up on at least a quarterly basis. 
 
 Management reports, so far, are at a minimum. This has primarily been 
 due to the priority placed on bringing the technical services module to 
 completion. Output is presently prepared on a weekly basis showing, by 
 particular Dewey classification, the number of items charged out under a 
 variety of categories: students, faculty, guest borrowers, reserve room, lost/ 
 missing, other libraries, departments, and renewals. 
 
 One use to which these data have been put is a follow-up on a policy 
 change made early in 1971. During the first year of the systems operation, the 
 loan period was two weeks. The circulation department felt that the number 
 of renewals was using up an inordinate amount of staff time. They suggested 
 that a four-week period would provide a better operating environment and 
 might also serve the user better. It was further anticipated that while the 
 number of save requests would probably increase, these would be offset by a 
 decline in renewals. 
 
 The data studied covered two six-month periods one with the two-week 
 loan, the other with the four-week loan. It was found that the number of 
 saves increased by 109 percent while the renewals decreased by 38 percent. 
 Translated into time units, however, 12 percent less time was spent in 
 processing these requests. This certainly confirmed the department's feelings, 
 especially since there was an increase in overall circulation of just over 31 
 percent. 
 
 Every member of the circulation department is extremely happy with the 
 system. As head of the department has stated, "No one on the staff would 
 consider returning to the manual system." When everything is functioning 
 properly, things could hardly be better. But, being a completely on-line 
 system, it is at the mercy of the equipment. If a 1031/1033 terminal goes 
 down, there is at least some inconvenience. If the 2740 goes down, there are 
 problems. If the phone lines act up, there are big problems. If the computer 
 "gets sick," there goes the ball game-almost. Fortunately, the amount of 
 downtime of these items is generally inversely proportional to the problems 
 
ON-LINE CIRCULA TION A T NOR THWESTERN UNIVERSITY 91 
 
 created. Thus, while some of the equipment may occasionally be out of 
 service, the average amount of downtime for the system as a whole, can be 
 measured in, at most, a few hours per week. Certainly a livable situation, but 
 of sufficient concern to warrant certain back-up capabilities. 
 
 In addition to coping with machine downtime, there must be quick and 
 fairly efficient means for charging out items which have no prepunched book 
 cards. Putting these two conditions together, the back-up system consists of a 
 Standard Register Source Record Punch and a two-part form. This form, with 
 carbon interleaf, provides a date due slip (top part) and a composite card for 
 later processing when the system comes back up. When necessary, the 
 borrower presents the book card and ID badge at the main circulation desk. 
 These are placed in the source record punch and the data are transferred to 
 the two-part form. Also transferred are data from internal slides, thus 
 preparing a printed date due slip and a punched composite card so called 
 because this one card carries all the data needed for the master file record. 
 When the system resumes operation these cards are given priority handling. 
 
 This is a comparatively slow process and the machine is far more sensitive 
 than the 1031. It all too frequently misses punches, especially in poorer 
 quality badges. This is rarely discovered until after the user has departed. But 
 on the whole, it does a much better job than keypunching all the data into 
 the card which is necessary when there is no punched book card. 
 
 In this case, the call number is printed on the form, along with the user 
 number, and the due date is stamped in the appropriate location. The top slip 
 again goes with the book, and the bottom card goes to keypunch where it is 
 turned into a composite card. At the same time a book card is prepared, to be 
 filed awaiting the return of the book. Copying of call numbers and ten digit 
 user numbers is extremely error prone and keypunch errors do occur. Again, 
 these cards must have priority handling to insure their entry into the system 
 as soon as possible. When delays in keypunching occur, it would be possible 
 to have the book returned and "discharged" before the composite card is 
 ready for charging. 
 
 The major problem with this back-up is that transactions take place 
 without the usual error detection in operation. An item being renewed may 
 have a save requested, it may already be in the file for some strange reason, or 
 the user may be one of those whose number has been blocked. 
 
 What has been the impact of the computer-based circulation module on the 
 library? Most noticeable to both the staff and the users has been the change in 
 actual operations involved with charging out an item. For about two-thirds of 
 such transactions, it is a self-service operation. The three 1031/1033 terminals 
 located in the stack areas are not manned. The user, who has a badge and 
 desires to borrow a book which has a punched card, approaches one of these 
 terminals, places his badge in the appropriate slot of the 1031, and places the 
 book card in its slot. In a few seconds the terminal reads and ejects the 
 
92 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 badge and the book card. Then the 1033 printer goes to work and prints the 
 date due slip. The user pushes a specially designed lever on the top of the 
 printer which cuts the paper; and then he removes the slip. The slip and book 
 card go into the pocket of the book and the badge goes into the user's 
 pocket. He shows both the book and badge to the exit attendant and leaves 
 the building. 
 
 Security is a very important factor in today's library. At Northwestern 
 there are attendants at each exit to check on material leaving the library. The 
 computer-produced date due slips offer a means for positive identification of 
 all legitimately borrowed items. The call number on the slip can be compared 
 with the call number on the book pocket and the identification number of 
 the borrower can be compared to the ID card. This has, of course, not 
 stopped all losses, but it has been significantly helpful. 
 
 In almost all instances, the user has spent a shorter period of time doing 
 the charging himself than if he had had to use the services of a circulation 
 assistant. The circulation department staff member, meanwhile, has gone 
 about other business. 
 
 Much of the work of the circulation department personnel has changed. 
 No longer are most of them tied to the task of continually filing and then 
 unfiling charge cards. No longer do they have to spend innumerable hours 
 deciphering names and addresses and then typing overdue notices. No longer 
 do returned books pile up into small mountains because of lack of help or 
 because there is limited space around the filing bins to get at the book cards. 
 No longer can faculty borrow books "forever" because there is not enough 
 time to send out regular (or even irregular) reminders to them. 
 
 No longer do staff members feel that the collection controls them. Now, 
 they control the collection. Filing and unfiling the circulation file is handled 
 by the computer. While renewals must still be handled by a staff member, 
 more and more charging by special borrowers is being done on a self-service 
 basis as punched badges are provided for guest borrowers and carrel holders. 
 The processing of overdue notices has almost been reduced to an envelope- 
 stuffing operation. The slips are inspected prior to stuffing, primarily to catch 
 long overdue items for special handling. Names and addresses for university 
 borrowers are printed on the notices; the batch programs have access to the 
 student and payroll files to gather such information. On most days, only 
 about four to five man-hours are needed to discharge returned books. 
 Requests to check if a book has been charged out are easily processed through 
 the 2740. Usually, there is an assigned operator on duty, both because there is 
 a constant stream of such requests and because there are a number of file 
 maintenance chores to perform-mail renewals, saves, and problems of various 
 sorts. Fine notices, though only partially automated, are much easier to 
 handle. All long-term borrowers are reminded of items charged to them on at 
 least a quarterly basis. The staff knows that the situation is well in hand and 
 that those areas of continued concern will be improved. 
 
ON-LINE CIRCULATION AT NORTHWESTERN UNIVERSITY 93 
 
 Because the system has freed so much time from simple but necessary 
 clerical operations, the department has been able to do things which, while 
 probably in its domain in the past, could not be effectively handled due to 
 this heavy clerical load. Some new responsibilities have even been added: a 
 complete inventory matching the card catalog and the holdings is under way, 
 the collection and the card catalog are being brought into agreement, and 
 incomplete holdings are being brought to attention. 
 
 Now that the collection is under better control, both internally and 
 externally, the user is better served. Items are easier to find because they are 
 more often where they should be, or are kept track of in the master file. This 
 file also contains records of transactions in the Technological Institute 
 Library, the largest branch on campus. (A 1031/1033 unit and a 2740 are 
 used there, although because of smaller volume, there is no self-service 
 operation.) Other libraries on campus may eventually be brought into the 
 system, making the main library's union catalog an even more effective tool. 
 There is much built-in flexibility, so that not only can a variety of due dates 
 be offered, but items can be coded in a variety of ways-Dewey, arbitrary 
 number, LC classification, etc. It should be mentioned that the decision to 
 omit author and title data on the book cards has met with almost no user 
 complaints. In the more than two years of operation, only a few individuals 
 have made any negative comments. 
 
 But the system is not quite perfect. Some of the equipment, especially 
 the 1033 printers, cause problems. Paper jams regularly occur, although far 
 less frequently since the installation of specially designed cutting blades and 
 paper channels. Badge quality is very important, and has at times caused 
 innumerable problems. Improvements can be made, such as an on-line file of 
 valid users and a blocking pattern that could do away with the traditional 
 monetary fines. Automatically suspending borrowing privileges until overdue 
 items are returned might be much more reasonable and effective. 
 
 But these are minor considerations in light of the successes so far 
 achieved. In operation since January of 1970, the system has proven its 
 effectiveness. While there has not been any reduction in staff, added tasks 
 have been easily absorbed, as have significant increases in circulation volume. 
 
 Northwestern University went to an on-line system in order to produce a 
 substantial impact on library operations. There is no question but that there is 
 such an impact. 
 
ELLEN WAS BY MILLER 
 
 Executive Assistant for Planning 
 
 and 
 
 B. J. HODGES 
 
 Manager, Systems Programming 
 
 Shawnee Mission Public Schools 
 
 Shawnee Mission, Kansas 
 
 Shawnee Mission's 
 
 On-Line Cataloging System: 
 
 The First Two Years 
 
 The last detailed article about the Shawnee Mission (Kansas) Public Schools' 
 library system was written during the summer of 1970 and published in March 
 1971. l This paper reports major events from April 1970 through March 1972. 
 It quantitatively describes the on-line system, discusses management issues, 
 and reports on plans for future development. 
 
 Given the general dearth of continuous quantitative and qualitative 
 reporting about library computer applications, it is hoped that this second 
 article will be followed by later performance analyses. Periodic reporting is 
 particularly critical in library areas with relatively little automation, such as 
 school and medium-sized libraries. 
 
 To put this paper in its correct perspective, it is necessary to know that 
 no major changes have been made during the past two years in either the 
 hardware or software support systems for library on-line cataloging. The 
 current configuration includes: IBM 360/40; DOS 256 K; eight 2314 disks; 
 one 2702 line control; 2741 terminals for student use via APL (A Program- 
 ming Language); 2740 terminals for library on-line cataloging; and three core 
 partitions for APL, library FASTER (Filing and Source Data Entry 
 Techniques for Easier Retrieval), and batch operations during first shift. 
 
SHAWNEE MISSION'S ON-LINE CATALOGING SYSTEM 95 
 
 TWO MAJOR EVENTS SINCE SYSTEM START-UP 
 
 The on-line cataloging system began in April 1970 when four elementary 
 collections were entered via terminal: two collections were entered retro- 
 spectively from shelflists, and two represented newly built schools. The four 
 schools contributed about 10,000 titles to the new on-line system. 
 
 Converting 45,000 Batch Records 
 
 During the summer of 1970, work began to merge the 10,000 new elementary 
 title records with 45,000 batch records for secondary schools. The batch 
 records had been created during the previous two years while the first 
 automated library system operated. Three major tasks developed: (1) intel- 
 ligently converting upper-case records to upper- and lower-case records; (2) 
 finding the duplicates among the 45,000 batch records, and (3) enlarging 
 almost all fields. To the authors' knowledge, these tasks have been attempted 
 only at Shawnee Mission; the problems and ultimate success can perhaps aid 
 those with similar tasks. 
 
 Several factors affected the approach taken: (1) aside from the massive 
 bibliographic difficulties of merging the two files, new materials were stacking 
 up; (2) two previously separate central processing groups had joined into the 
 new on-line Library Technical Processing (LTP) group and the LTP staff was 
 anxious to take ownership of the on-line system; and (3) the authors were 
 involved in other projects simultaneously. 
 
 The following steps were taken to merge the elementary and secondary 
 records: 
 
 1. All 45,000 batch records were transformed into upper- and lower-case 
 format and compared with the elementary upper- and lower-case records. 
 Unfortunately, no duplicates were found for several reasons: lack of 
 collection overlap, unstandard data on batch records, and different field 
 sizes. 
 
 2. Therefore, computer programs were written to convert the batch records 
 to upper- and lower-case and to enlarge field sizes. Examples of this 
 computer editing included: (1) expanding author, title, series, collation, 
 and subject heading field size; (2) converting all letters to lower-case 
 except those in selected fields which followed punctuation; and (3) 
 deriving a three-letter "Cutter" from the first three letters of the author's 
 last name to replace the regular Cutter. 
 
 No computer duplicate test was made since librarians feared that 
 nonstandard data from the batch system would prove misleading. Non- 
 standard data had resulted from using variable abbreviations and " . . . " 
 to indicated omitted information on too-small batch fields. 
 
 3. Title lists for all 55,000 records were printed; all bibliographic data was in 
 the new, converted format. Catalogers then edited the lists for duplicates 
 and for inaccurate data. 
 
96 7972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 4. Terminal operators keyed in the revised data. Records were either updated 
 
 and the correct number of copies added or they were deactivated. 
 
 The above steps took from July 1970 through February 1971 to com- 
 plete. Out of 45,000 records, almost 30,000 were transferred to the FASTER 
 files. The rest were dropped as redundant or erroneous. 
 
 A large backlog of new materials accumulated while the file merger 
 continued. However, the then-director of Libraries and Administrative 
 Services, realized that the merged data base was necessary if the cost benefits 
 of a high duplicate rate were to be realized later. The file merger utilized one 
 supervisor, three catalogers, and seven terminal operators during seven months. 
 Three terminals were used in August, six in December, and eight were in 
 operation during February 1971. 
 
 After working elbow deep in the merged file for seven months, both 
 catalogers and operators had confidence in its contents. Catalogers had long 
 recognized several imperfections in the batch system's data, such as 
 unstandard data and cryptic information. The file merging process required 
 that they examine each bibliographic and copy record carefully. Long- 
 postponed standardization of subject headings, publisher names, and author 
 names (personal and corporate) were some by-products of their scrutiny. 
 
 The LTP staffs new confidence in the cataloging data spread to con- 
 fidence in the system. The combination of reliable data and ease in manipu- 
 lating it via terminal resulted in LTP unit taking ownership of the new system. 
 Change in ownership from designers to operators is a requirement for any 
 viable automated system. 
 
 In April 1971, the new director of library services realized that Library 
 Technical Processing, just emerging from its tedious file merger, needed relief. 
 Therefore, book processing arrangements for fiscal year 1971-72 were made 
 with a jobber for all but one elementary school, which elected to stay with 
 LTP. 
 
 With almost all elementary book items diverted to the jobber, LTP 
 proceeded during the summer of 1971 to demolish its backlog of approxi- 
 mately 32,000 items by utilizing eight terminals twelve hours per day with 
 double shifts from mid-June through mid-August. Monthly production 
 statistics show 13,250 new items processed in June; 14,342 in July; and 
 12,482 in August. At this production rate the backlog was removed and 
 incoming new materials were processed. 
 
 Fig. 1 shows cumulative file size since December 1971. Preoccupation 
 with the file merger is revealed by the small increment in new titles processed 
 between December 31, 1970 and the end of the first quarter of 1971. 
 
 Since September 1971, LTP has been able to process all incoming secon- 
 dary materials with no backlogs. This system capacity allowed for the return 
 of all elementary processing to LTP as of July 1972. In the meantime, 
 however, LTP has processed shelflists of older holdings on a time-available 
 basis, resulting in a steadily growing rate of retrospective conversion. 
 
SHAWNEE MISSION'S ON-LINE CATALOGING SYSTEM 
 
 97 
 
 240 ^ 
 
 
 
 - 240 
 
 220- 
 
 
 
 - 220 
 
 
 - 
 
 200,335 
 
 
 
 
 
 
 
 - 200 
 
 h 
 
 - 
 
 
 
 - 
 
 
 o 180 - 
 
 
 
 
 
 -180 
 
 u 
 
 
 172,609 
 
 
 
 
 s 
 
 
 
 
 
 
 
 - 
 
 
 160 - 
 
 
 
 
 
 
 
 - 160 
 
 a 
 
 
 152,463 
 
 
 
 
 
 
 n 
 
 * 
 
 
 
 
 
 
 
 
 
 
 d 140 - 
 
 
 
 
 
 
 
 
 
 - 140 
 
 s 
 
 . 
 
 
 
 
 
 
 New 
 
 . 
 
 
 120- 
 
 
 118.553 
 
 
 
 
 
 
 
 - 120 
 
 o 
 
 
 
 
 
 
 
 New 
 
 
 
 
 
 f 
 100 - 
 
 
 
 
 
 New 
 
 
 
 
 
 
 - 100 
 
 C 
 
 . 
 
 
 
 
 
 
 
 
 
 _ 
 
 
 o an 
 
 
 81. 786 
 
 New 
 
 
 
 
 
 
 
 
 
 p 
 
 68, 089 
 
 
 
 
 
 
 
 
 
 
 
 _ 
 
 
 i 
 
 
 
 
 New 
 
 
 
 
 
 
 
 
 
 
 
 e 
 
 
 New 
 
 
 
 
 
 
 
 
 
 
 
 
 60 
 
 s 
 40 - 
 
 
 
 
 
 
 Retro 
 
 
 Retro 
 
 
 Retro 
 
 
 Retro 
 
 
 - 40 
 
 Retro 
 
 Retro 
 
 20 - 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 20 
 
 
 
 30,000 Copies Transferred From Previous 
 
 
 
 
 
 
 
 
 (Batch System 
 
 
 
 
 
 
 
 
 
 Tile Size 
 
 1st 2nd 3rd 4th 
 
 
 1st 
 
 
 
 
 
 as of 
 
 
 1971 
 
 
 1972 
 
 
 
 
 
 12/31/70 
 
 Quarterly Production 
 
 
 Fig. 1. Total Number of New, Retrospective and Transferred Items in Master 
 
 Cataloging File 
 
 Retrospective Conversion 
 
 Several ways of converting shelflists have been tried during the past two years. 
 The major variables have been: (1) the degree to which the shelflist is 
 compared with actual holdings before a duplicate search is attempted via 
 terminals; (2) location of terminals in LTP or the school libraries; (3) which 
 staff-LTP or building-examines computer-sorted and printed card catalogs 
 and applies new labels; and (4) whether card catalogs and labels are sorted and 
 printed at the end of conversion, or printed on demand during retrospective 
 conversion. 
 
 To date, one secondary and two elementary schools have been completely 
 converted from shelflists. Two secondary schools are now in progress on a 
 time-available basis. This leisurely approach explains the relatively small 
 
98 1972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 increment in retrospective items in fig. 1. All incoming items have higher 
 processing priority than any retrospective items. 
 
 Experience with five schools has shown that a careful comparison of the 
 shelflist with actual holdings is very useful before attempting a duplicate 
 search via terminal. If this step is not taken, inaccurate copy information, 
 missing shelflist cards and poor shelflist data appear. These problems are 
 especially likely in a school system which had for years relied upon cataloging 
 by busy librarians and volunteers; some of the latter not highly trained or 
 supervised. 
 
 Printing cards and labels is flexible. Librarians can choose massively sorted 
 and printed card catalogs, and massively printed label sets in shelflist 
 sequence. Or, they can request item-by-item cards and labels as conversion 
 proceeds. The intent of library management is to provide as responsive an 
 output schedule as possible. 
 
 However, decisions must be made well in advance of the deadline for 
 output. Sort and print time for a large card catalog is considerable; the large 
 number of Shawnee Mission computer applications 2 requires that the Division 
 of Library Services puts its bid in early to the computer center for large chunks 
 of computer time. 
 
 Several manpower options for relabeling and for checking entire card 
 catalogs have been used. One secondary school requested cards to be printed 
 in small clusters by Dewey number; that school's librarians did all filing and 
 replacing of old card files. Two elementary school libraries let LTP staff 
 examine and refile the massively printed card catalogs, and relabel the 
 collection. One junior high school used parent and student volunteers to 
 relabel the collection. In one instance, the terminal was located in a secondary 
 school. The operator worked with the librarians in performing a duplicate 
 search, adding copies for those duplicates, and keying in entire records for 
 new items. 
 
 At the end of March 1972, a total of 36,718 retrospective items had been 
 added to the master copy file; 18,629 were in the file by January 1, 1971. 
 Included are entire collections as well as individual items sent in by librarians; 
 in earlier years some audiovisual items were not cataloged by overloaded 
 librarians. The on-line system has the capacity to process these older items on 
 a time-available basis, and several librarians have taken advantage of this 
 service. One example is the 1,500 film strips submitted to LTP in February 
 1972 by an elementary library; that work was still in process as of March 
 1972. 
 
 LTP staff consider retrospective conversion a good way to keep the 
 terminals busy. However, operators tend to become bored by several hours of 
 keying from shelflist cards because transaction response time, averaging six 
 seconds between hitting the bid key and starting to type the response, is too 
 long. Normally, an operator inputing. books and audiovisual items scans them 
 
SHA WNEE MISSION'S ON-LINE CA TALOGING SYSTEM 99 
 
 while waiting for the computer to respond. Since there is nothing of interest 
 to scan on shelflist cards, operators may get bored. 
 
 Retrospective conversion is an excellent filler for a high capacity on-line 
 cataloging system, but it may cause impatience and frustration in operators 
 when undertaken in lengthy stints. 
 
 QUANTITATIVE DESCRIPTION 
 Total File Characteristics 
 
 A total of 200,335 copies and 78,113 titles are held in the Shawnee Mission 
 on-line library files. Table 1 presents data for each type of physical format 
 currently processed by LTP. 3 Books represent 76 percent of all copy records, 
 compared to 74 percent of all title records. Of the 200,335 copy records, 
 47,280 are for audiovisual items. There are 20,138 unique audiovisual titles 
 among the 78,113 title records. 
 
 The overall duplicate ratio is 2.58 to each new title. This desirable ratio is 
 important for cost reasons: highly paid catalogers are not needed to handle 
 duplicates, fewer terminal transactions are needed to enter each duplicate, and 
 duplicates move through LTP more quickly. 
 
 System Efficiency 
 
 "Efficiency" connotes speed, accuracy, and economy. That definition applies 
 to the Shawnee Mission on-line cataloging system. 
 
 COSTS 
 
 When cost data were compiled in the summer of 1970, 4 the authors did not 
 anticipate the heavy use that would later be made of listings, statistical 
 reports, bibliographies, entire card catalogs and label sets, and other printed 
 products. Therefore, two sets of cost data were computed for this paper. 
 Table 2 shows unit cost estimates for card/label output only, which is 
 comparable with the figures of 1969-70. It also gives unit cost estimates which 
 include the present high rate of auxiliary printing. 
 
 Costs in table 2 are based on: 1) tasks performed at LTP from item 
 arrival to mailing out to the destination library, 2) library and data processing 
 staff, 3) computer time, and 4) supplies. 
 
 A junior high school which requested an entirely new public catalog, 
 shelflist, and set of labels exemplifies the importance of auxiliary printing. Its 
 collection had been added to the batch system; later, the librarian desired 
 uniform printed products from the upper- and lower-case system. An example 
 of another product for which auxiliary printing is needed is the union catalog 
 for all 16mm films, organized by title and subject headings, which will be 
 placed in buildings for teacher and librarian use. 
 
100 
 
 1972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 Physical Format 
 
 Copies 
 
 Titles 
 
 Art prints 
 
 1751 
 
 958 
 
 Books 
 
 153055 
 
 57500 
 
 Charts 
 
 94 
 
 79 
 
 Cassette recordings 
 
 938 
 
 549 
 
 Disc recordings 
 
 5438 
 
 2743 
 
 Flash cards 
 
 53 
 
 19 
 
 Filmstrips 
 
 20401 
 
 7609 
 
 Games 
 
 156 
 
 115 
 
 Globes 
 
 9 
 
 8 
 
 Kits 
 
 224 
 
 140 
 
 Super 8 loop films 
 
 4520 
 
 1990 
 
 Sound loops 
 
 20 
 
 8 
 
 Models 
 
 66 
 
 65 
 
 16mm films 
 
 901 
 
 793 
 
 Maps 
 
 66 
 
 62 
 
 Realia 
 
 10 
 
 9 
 
 Sound filmstrips 
 
 5638 
 
 2061 
 
 Slides 
 
 925 
 
 425 
 
 Study prints 
 
 1791 
 
 475 
 
 Sound slides 
 
 69 
 
 28 
 
 Tape recordings 
 
 1533 
 
 1095 
 
 Transparencies 
 
 2430 
 
 1199 
 
 Viewmaster reels 
 
 245 
 
 181 
 
 Collections 
 
 2 
 
 2 
 
 Total 
 
 200,335 
 
 78,113 
 
 Table 1 . Total Copies and Titles for 
 Each Physical Format (As of March 10, 1972) 
 
 
 Card & Label 
 Sets Only 
 
 Card & Label Sets 
 and All Other 
 Printed Products 
 
 Any Item 
 Duplicate 
 New to system 
 
 $2.25 
 1.91 
 4.36 
 
 $2.53 
 2.15 
 4.91 
 
 Table 2. Estimated Unit Costs for 
 Fiscal Year 1971-72 
 
SHA WNEE MISSION'S ON-LINE CA TALOGING SYSTEM 101 
 
 A large data base encourages a large amount of auxiliary printing. There- 
 fore, cost data should reflect both original data entry and basic cards/label 
 output, and later use in many printed products. 
 
 AVAILABILITY 
 
 Availability is a very important measure of system performance. Specifically, 
 availability means the ratio of downtime to total hours scheduled for 
 operation. Data kept from July 1 through December 31, 1971, reveal a highly 
 dependable on-line cataloging system. 
 
 During that period the system was scheduled for 8,280 terminal hours. In 
 reality, it was down for 880 hours. Of that downtime, 672 hours were for 
 weekly preventative maintenance on the System 360. The remaining 208 
 hours of downtime were due to other causes, including quarterly system 
 dedication to grade reporting. 
 
 Thus, the system was down 10.6 percent of its scheduled time. Downtime 
 for other than preventative maintenance accounted for 2.5 percent of the 
 8,280 hours during those six months. This high rate of system availability is 
 especially significant because another teleprocessing system, APL, runs con- 
 currently with the library FASTER system. In the third core partition, batch 
 jobs are also processed. 
 
 DATA QUALITY 
 
 One area lacking dependable statistics is the correction rate for on-line data. 
 Since no count is made of, or can be derived for, corrections, estimates must 
 be used. The usual caveats accompany the following statements from LTP 
 personnel. 
 
 LTP staff estimates that 1/10 full time equivalent terminal operator 
 corrects erroneous data found on cards, labels, or any other output. Generally 
 errors are spotted by the clerks who match cards/labels with each item. 
 Suspected errors are turned over to the terminal supervisor, who consults with 
 catalogers when necessary. Currently, only one terminal operator actually keys 
 corrections. However, one operator spent about 75 percent of her time on 
 corrections when a second shift of operators was added during July and 
 August 1971. 
 
 RESPONSE TIME 
 
 Another area lacking reliable statistics is transaction response time. Since it 
 was impossible to construct average transaction time from the computer 
 center, the authors timed individual operators with a stop watch. Specifically, 
 the interval between hitting the bid key and receiving a reply was timed. At 
 the time this small, statistically unreliable study was made, all six terminals 
 were operating along with the other teleprocessing system and batch jobs. The 
 
102 
 
 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 
 Week Completed 
 
 
 Week 
 Tagged 
 
 Number 
 of 
 Items 
 
 1 
 
 2 
 
 3 
 
 4 
 
 Total 
 
 1 
 
 1,326 
 
 
 
 
 
 39 
 
 576 
 
 615 
 
 2 
 
 1,000 
 
 
 
 
 40 
 
 169 
 
 209 
 
 3 
 
 543 
 
 
 
 
 
 11 
 
 11 
 
 Total 
 
 2,869 
 
 
 
 
 
 79 
 
 756 
 
 835 
 
 Table 3. Number of Items Completely Processed 
 During Throughput Study 
 
 average for seventy-nine transactions was six seconds, ranging from three to 
 sixteen seconds. 
 
 THROUGHPUT TIME 
 
 Another measure of system efficiency is the time taken for new acquisitions 
 to be processed. In order to study that throughput time, new acquisitions 
 were monitored during a four -week period, March 13 through April 7, 1972. 
 
 The method used included: (1) inserting different colored tags into audio- 
 visual and book materials, (2) stamping the date the item was compared with 
 its purchase order (usually not more than one day later than actual delivery), 
 (3) noting on each tag whether the item was a duplicate, and (4) pulling the 
 dated tag out when the item was fully processed and being boxed for the 
 building librarian. The number of completed tags was compared against the 
 total number inserted. Tags were inserted during the first three weeks of the 
 study; they were gathered when completed during weeks three and four. No 
 tags were ready during weeks one or two, as seen below. 
 
 Table 3 shows the number of items that were completed during each of 
 the study's four weeks. Of the 2,869 new acquisitions, 1,2 16 were audiovisual 
 items and 1,653 were books; 188 of the 1,216 audiovisual items were 
 completely processed during the study. Of those 188 audiovisual items pro- 
 cessed, 182 were duplicates of titles already in the system. Thirty-eight 
 percent of the 1,653 books were completed during the study. Of the 636 
 completed book items, 71 were new to the system; 565 were duplicates. 
 
 Fig. 2 shows the frequency distribution of elapsed working days between 
 tagging and boxing for delivery to the building librarian. An average of one 
 day preceded tagging; tags were inserted when the item was compared with its 
 purchase order. 
 
SNA WNEE MISSION'S ON-LINE CA TALOGING SYSTEM 
 
 103 
 
 200 
 
 190 -- 
 180 - - 
 170 -- 
 160 - 
 
 150 
 
 140 
 130 -- 
 120 -T 
 HO - 
 
 100 
 
 90 -- 
 80 -- 
 70 -- 
 60 -- 
 
 50 
 
 40 -- 
 30 -- 
 20 -T 
 10 -- 
 
 A 
 
 -H 
 
 4 6 8 10 12 14 
 
 Elapsed Work Days 
 
 18 
 
 2. Work Days Needed to Process 835 Book and Audiovisual Items During 
 a 19-day Study 
 
104 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 A full-capacity staff in Library Technical Processing for data entry, 
 cataloging, and physical preparation is six terminal operators, three catalogers, 
 and six preparation clerks. During the first 2.5 weeks of the study, only one 
 preparation clerk was on duty; the others were helping with priority tasks in 
 the schools. During the last 1.5 weeks of the study an average of three 
 preparation clerks were at LTP. The variable number of these clerks helps 
 explain why no sample items were completed during the first two weeks- 
 items already in the processing pipeline had to be completed by available LTP 
 staff. 
 
 During week three, boxing for building librarians was performed twice, on 
 Tuesday and Friday. Thus, tags could be retrieved only on those two days. 
 Boxing occurred each day during the fourth week of the study. 
 
 The fluctuations in manpower symbolize the responsive method of library 
 management used at Shawnee Mission. Instead of assigning staff to permanent 
 positions, clerks and professionals perform tasks as needed whether at LTP 
 or in school libraries. 
 
 File Usage 
 
 Title and copy file usage measures their data's relevancy to library needs. Of 
 the scheduled printed products, approximately 83,700 card and label sets were 
 printed during fiscal year 1971-72 for new items. Terminal transaction 
 statistics are printed weekly, LTP production tallies for each building 
 monthly, and statistics on active title records monthly. 
 
 School librarians and the library management also request specific listings 
 on demand. One union catalog for 901 16mm films has been printed; it 
 consists of a 57-page title index and a 54-page subject index. 
 
 During the five months beginning November 1, 1971, twenty inventories 
 of school holdings were run; sort and print time for the programs involved 
 took 29 hours and 17 minutes. During the same period eight union subject 
 heading bibliographies were compiled by the computer. Total run time for 
 those eight bibliographies was 9 hours and 42 minutes. 
 
 There are two on-line file query transactions: (1) by title number, and (2) 
 by author last name and title. Table 4 shows the rate for each type of file 
 query, and the proportion of the two query transactions to total transactions. 
 
 In general, the author/title query is used to find duplicates among new 
 acquisitions. The title number query is used to enter additional copies and to 
 complete bibliographic data for new-to-the-system titles. 
 
 Daily Operations 
 
 As of March 1972, six operators work weekdays from 8:00 A.M. to 4:30 P.M. 
 Coffee breaks and lunch periods are taken, of course; there is no operator 
 
SHA WNEE MISSION'S ON-LINE CA TALOGING SYSTEM 
 
 105 
 
 
 Fourth Quarter 
 1971 
 
 First Quarter 
 1972 
 
 Terminal 
 Transactions 
 
 Number 
 
 % of Total 
 Transactions 
 
 Number 
 
 % of Total 
 Transactions 
 
 Title Number Query 
 
 24,876 
 
 22 
 
 18,813 
 
 16 
 
 Author/Title Query 
 
 15,815 
 
 14 
 
 22,685 
 
 18 
 
 All Library 
 Transactions 
 
 114,186 
 
 
 120,908 
 
 
 Table 4. Rate of Terminal Transactions upon 
 the Title and Copy Files 
 
 backup for those relief periods. Absentee backup is provided by the terminal 
 supervisor, who also checks newly printed cards and labels, and identifies 
 corrections for operators. No overtime or weekend hours are currently 
 scheduled. 
 
 Monthly production from this work force averages 8,400 new and retro- 
 spective items. On the average, each operator processes 1 ,400 items per 
 month, or 350 per week. Absences and downtime affect production; another 
 variable is the arrival rate of new items. The current batch order system prints 
 orders bimonthly, resulting in a fairly steady flow of new acquisitions to LTP. 
 
 Twenty-one LTP staff receive, catalog, enter, and process new and retro- 
 spective items. They also handle all jobs connected with the 16mm film 
 library. Two staff are certified teachers, the rest are clerks. LTP processes 
 items for the sixty-five Shawnee Mission schools as well as for fifteen other 
 locations, including professional collections and several parochial schools. 
 
 MANAGEMENT IMPLICATIONS 
 
 The Shawnee Mission Public School District has undergone some significant 
 management changes since June 1969. Affecting problemsolving and budget- 
 making are many variables including: (1) unifying thirteen small districts in 
 July 1969; (2) providing management expertise for the resulting K-12 system 
 with sixty-five schools and 44,000 students; (3) adopting middle-management 
 decisionmaking systems; and (4) living with a Kansas State property tax lid 
 that allows no more than 5 percent annual increase in operating funds. 
 
 Changes in the environment and composition of the new unified district 
 required different approaches to problemsolving. The on-line cataloging system 
 was carefully watched by top management, who followed up that positive 
 experience with team-operated system design in other areas, notably account- 
 ing and budgetmaking. 
 
1 06 1971 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 Development 
 
 The following section presents the authors' views on several levels of manage- 
 ment development in the Shawnee Mission School District. 
 
 MANAGEMENT OF THE ON-LINE PILOT PROJECT 
 
 The authors believe that the management of pilot project implementation was 
 generally satisfactory although inexperience led to one major miscalculation 
 about the amount of time needed and the method chosen for editing the batch 
 records to expanded, upper- and lower-case format. Recognizing the impor- 
 tance of file merger, our direct control of the pilot project should have 
 continued until it was completed. Instead, there was no strong control of the 
 file merger, especially in its initial stages. That lack of task management 
 probably lengthened the time taken for the file merger. 
 
 LIBRARY MANAGEMENT 
 
 That we were soon reassigned to other, nonlibrary projects meant that the 
 LTP staff quickly claimed ownership of the on-line system. Any new system's 
 viability depends, of course, on the users' psychological identification with 
 that system. The seven months spent merging the file helped LTP staff to 
 identify with and own the on-line system. 
 
 The same cannot be said for school librarians during that period, however, 
 since relatively few new materials trickled through the backlog into their 
 buildings. The decision to send elementary orders to a commercial jobber for 
 processing was, therefore, a wise one. Both groups of librarians-LTP and the 
 school librarians found library management responsive to their different 
 needs. 
 
 Unit costs decreased from the batch system to the on-line system. While 
 unit costs for any automated system are probably higher than manual pro- 
 cessing, the additional use of the data through file query and auxiliary 
 printing is significant. Indeed, the two major future projects for the library 
 system draw heavily upon the growing data base: (1) on-line control for the 
 booking and circulation of the 16mm film collection, and (2) special biblio- 
 graphies for use by subject areas such as seventh grade unified studies. 
 
 Perhaps most important for the building librarian, improvements in the 
 cataloging and order systems during the past two years have resulted in 
 decreased throughput time for new orders. Two years ago it was not unusual 
 for 12-18 months to elapse between submitting a request and receiving the 
 item. Currently, that time is estimated to be about three months. The on-line 
 system has cut the processing time of new acquisitions; additional savings of 
 time will be possible with a revised order system, scheduled to begin operation 
 in 1973. 
 
SHA WNEE MISSION'S ON-LINE CA TALOGING SYSTEM 107 
 
 DATA PROCESSING MANAGEMENT 
 
 The on-line library system has achieved that highly desirable division of labor 
 between any data processing installation and its users: users have full respon- 
 sibility for data quality and format while data processing guarantees data and 
 file safety. This relationship is especially appreciated at Shawnee Mission, 
 where programmers previously worked daily with library data in the previous 
 batch system. 
 
 The success of two teleprocessing systems student-oriented APL and 
 library FASTER-has encouraged other district offices to request tele- 
 processing. Significantly, educators now requesting this service realize that it 
 must be accompanied by more core, better central processing unit-disk 
 turnaround time, and more disk storage. These traditional computer mysteries 
 are becoming the property of educators, whose growing sophistication helps 
 the computer center explain and expand its current applications. 
 
 One implication of more teleprocessing applications may be a role change 
 for programmers. The bulk of system programming is usually done prior to 
 starting a teleprocessing system. After the system is up, programming efforts 
 tend to shift to general software maintenance rather than application mainte- 
 nance. 
 
 TOP MANAGEMENT 
 
 Top management continued its experiment with team assignments when the 
 authors were asked to participate with data processing and business office 
 staff in setting up a cost-centered accounting system. The subsequent success 
 of the accounting system was due in large part to the business office staff 
 assuming ownership and file control. 
 
 As a result the business manager can say with confidence that he knows 
 the latest status of all district expenditures. By pursuing proven methods of 
 team problemsolving, top management gained a middle level staff expertise 
 that continues to be utilized. The resulting staff skills are usable in many parts 
 of the school district. 
 
 The on-line cataloging system's interest in providing production and 
 operations statistics has been carried much further during the past fiscal year. 
 The business office now prepares a semiannual budget report showing all 
 expenditures cost centered to specific locations and programs. 5 Information 
 about costs, production, and operation for any part of the school district is 
 consistent with the movement to inform and utilize middle management. 
 Without information, middle managers cannot participate fully in problem 
 detection and problem-solving. 
 
 Shawnee Mission's cost-centered accounting system aided in contracting 
 with two national companies to provide audit and computer hardware 
 services. These companies can compare Shawnee Mission's development 
 
1 08 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 with national trends and local staff can benefit from their state-of-the-art 
 knowledge about educational management. 
 
 Finally, the successes of both the library system and the accounting 
 system have provided national publicity for this school district. A summary 
 article written by the superintendent of schools was published in 197 1. 2 The 
 coordinator of public information has provided the local media with stories 
 and interviews. Needless to say, top management of school districts like that 
 in any sector of the economy likes favorable publicity on innovative 
 programs. The fact that no grant funds of any type have been used in these 
 projects has enhanced top management's ownership. 
 
 Throughout this section on management implications is discussion of the 
 changes that Shawnee Mission School District has undergone since unification 
 in July 1969. Since then, ownership of the management process has spread to 
 middle level administrators. Why? They have been encouraged to detect and 
 solve problems; more important, top management has continued to utilize 
 their new skills. By participating in decisionmaking committees, such as the 
 budget review committee which creates a district -wide draft budget, school 
 principals and directors are becoming the critical management cadre upon 
 which future improvements depend. It is intended that such decentralization 
 will result in even more vital and relevant services being rendered to the 
 community by Shawnee Mission Public Schools. 
 
 REFERENCES 
 
 1. Miller, Ellen and Hodges, B. J. "Shawnee Mission's On-Line Cataloging 
 System, " Journal of Library Automation, 4:13-26, March 1971. 
 
 2. Ball, Arzell L. "A Superintendent's View of a Computer System," 
 School Management , 15:12-14, Dec. 1971. 
 
 3. Tomcak, Jackie. "Shawnee Mission's Cataloging and Processing of 
 Non-Book Materials," Mountain Plains Library Association Quarterly, 16:5, 
 Spring 1972. 
 
 4. Miller and Hodges, op. cit., p. 22. 
 
 5. Ferguson, Walter E. "Attendance Center Report by Major Accounts 
 for the Period July 1, 1971, Through December 31, 1971." Unpublished 
 volume prepared for Shawnee Mission (Kansas) School District, 1972. 
 
 Additional Reference 
 
 "Budget Making Procedures (for) Fiscal Year 1972-1973." Unpublished paper 
 prepared by the Shawnee Mission Public Schools, 1972. 
 
A. H. EPSTEIN 
 
 Director, Project BALLOTS 
 
 Stanford Computation Center 
 
 and 
 ALLEN B. VEANER 
 
 Assistant Director 
 
 for Bibliographic Operations 
 
 Stanford University Libraries 
 
 Stanford, California 
 
 A User's View of BALLOTS 
 
 BALLOTS (Bibliographic Automation of Large Library Operations using a 
 Time -sharing System) is an on-line interactive library automation system that 
 supports the acquisition and cataloging functions of the Stanford University 
 Libraries' technical processing operations. The BALLOTS system is being 
 implemented in a series of eleven modules. A large part of BALLOTS' 
 development up to the development of the first module was funded by a 
 grant from the U.S. Office of Education, Department of Health, Education, 
 and Welfare. This paper describes the first module, BALLOTS-MARC (or 
 simply, the MARC module), and various aspects of system hardware and 
 software as they pertain to this module. The MARC module was scheduled for 
 implementation in the late summer of 1972. The other modules are briefly 
 described at the end of this paper. 
 
 The MARC module supports the production of purchase orders, catalog 
 card sets, spine labels, and several types of file slips and management reports. 
 An on-line MARC file stored on disk is updated from the weekly Library of 
 Congress MARC tapes. Several indexes are maintained in the file in order to 
 support extensive on-line interactive file searching. 
 
 The BALLOTS system operates through programmable cathode ray tube 
 (CRT) terminals in the library that are connected to the campus facility, an 
 IBM 360 Model 67 computer in the Stanford Computation Center, approxi- 
 mately one mile away. The campus facility computer also handles the faculty 
 
Fig. 1 . The Sanders PDS 804 Programmable CRT Terminal 
 
 and student academic and research computing requirements. About 2,000 
 computing jobs unrelated to BALLOTS are run on this computer each day. 
 
 The type of video display terminal being used for BALLOTS is shown in 
 fig. 1. It consists of a keyboard, a CRT capable of displaying 1,920 characters 
 at a time, and a 4,096-byte programmable microprocessor. The CRT terminal 
 could be called a window into the BALLOTS system; through it the library 
 communicates with the system. Printed outputs, like the purchase orders, 
 catalog cards, and spine labels, are produced overnight as a result of the daily 
 on-line activity at the terminal. 
 
 One way of describing BALLOTS is to explain how the system looks to 
 the user and how it is used in normal day-to-day library operations. A typical 
 book cycle will be traced in the examples that follow. 
 
 SEARCHING 
 
 A typical book processing cycle begins when the acquisition department 
 receives a book request from a faculty or staff member requesting that a 
 particular book be added to the collection. A sample book request is shown in 
 
A USER'S VIEW OF BALLOTS 
 
 111 
 
 -^ 
 
 x. 
 
 Author f ^T 
 
 White, Jon M. xJ^ 
 
 Title Cortes and the Downfall of 
 Empire 
 
 {U5HJ 
 
 ^m^mf^^ 
 the Aztec 
 
 Edition 
 
 Place Publisher 
 
 New York St. Martin's Press 
 
 Date of Publication Xo. Vols. Series 
 
 1971 
 
 
 No. Cop. 
 *- 
 
 Price 
 
 
 JMB _ .. . Orrtcr From : 
 
 Other Info.: 
 Item: 
 
 
 
 FntHl 
 
 f-bdl 
 
 Acc. No. .... 
 
 NKA-004 
 
 Shehrt 
 
 Stack ^ AH r, t . 
 
 Searcher: 
 
 Date: 
 
 Fig. 2. Book Request 
 
 fig. 2. On receiving the book request, the librarian keys in a search request for 
 that particular book at the CRT terminal keyboard. This search request, 
 shown shaded in fig. 3, is displayed on the CRT screen as it is keyed. (In the 
 following figures, all the data supplied by the terminal operator is shown 
 shaded; all the data supplied by the computer is shown unshaded.) The 
 operator in this example chose to search (FIND or FIN) by one personal 
 name (PN), and because he was unsure of the spelling of the author's name 
 (JON or JOHN), typed J. instead. The operator chose two words from the 
 title. Because he was unsure of the spelling of CORTES, he truncated the 
 word to CORTE#, which would locate a record for any title word beginning 
 with "Corte." 
 
 The search request is entered into the system, the on-line MARC file is 
 searched, and the search results are returned to the screen in about two 
 seconds. In the BALLOTS system, when only one record is found in a search, 
 it is assumed that this record is the correct result, and the full bibliographic 
 record is displayed at the terminal (fig. 4). 
 
 Searching can be done using any word or words in the title (trivial words, 
 like THE and IN, will be recorded in an exclusion list for the file, and the 
 system will reject them as search terms). One can also search using the LC 
 card number, the main entry, the title statement, and added entries. And the 
 personal name can be given to the system in various forms. For instance, in 
 fig. 4 the author's name turned out to be stored in the MARC file as 
 
772 
 
 7972 CLINIC ON APPLICATIONS OF DAT A PROCESSING 
 
 SI 01 BMRC-S 
 
 OROER 
 
 WEO 
 
 Fig. 3. A Search Request on the SI 01 Screen 
 
 BFOl 
 
 BMRC-S 
 
 7211*05*9 
 
 ORDER 
 
 WFP 
 
 fin pn J.M. White and t Corte* and Aztec RESULT: 1 BOOK(S) 
 
 OR01 
 
 IVhlte, Jon Ewhank Manchip, 192U- 
 
 Cortes and the downfall of the Aztec Empire; a study In a conflict of 
 cultures, Hy Jon Manchlp White. Mew York, St. Martin's Press [1171] 
 
 352 p. illus., naps, plans, ports. 25 cm. <11.no 
 
 Bibliography: p. [335]-339. 
 
 1. Mexico - History - Conquest, 1519-15UO. 2. Cortes, Hernan^o, !fc5-15'7. 
 I. TITLE. 
 7?-U0589 
 
 F1230.WU6 1071 97?/ . 02/092U 
 OP:nyu L:en^ REC:am MS:N 
 
 Fig. 4. A Full Bibliographic Display on the BF01 Screen 
 
 WHITE, JON EWBANK MANCHIP. The following variations on this name, or 
 any combination of them, would also be accepted as valid search terms and 
 would locate the same record. 
 
 (initials) 
 
 (some initials omitted) 
 (initials without periods) 
 (capitalization ignored) 
 (surname first or last) 
 (surname first or embedded) 
 (first names implicit truncation) 
 (last name explicit truncation 
 through use of pound sign) 
 
 The BALLOTS system makes extensive efforts to recognize different versions 
 of a personal name, because in many of the library processing cycles the exact 
 name of an author is not known. This helps to insure success in on-line search 
 efforts. 
 
 If the search in fig. 3 had been entered as simply FIN PN J. M. WHITE, 
 the search might have produced more than one result (because more than one 
 record in the data base fulfilled the search criteria). In this case (fig. 5), the 
 
 WHITE, J.E.M. 
 
 White, M. 
 
 White, JEM 
 
 white, jon ewbank manchip 
 
 J.E.M. White 
 
 Manchip White, J.E. 
 
 White, Jo Ewb Man 
 
 Whi#, J.E.M. 
 
A USER 'S VIEW OF BALLOTS 113 
 
 fin pn .1. M. 'lh\t* RESULT: 5 BOOK(S) 
 
 Fig. 5. Search Results Displayed on the SI 02 Screen 
 
 SI 02 BMRC-S ORDER S WED 
 
 fin PJI J. M. White RESULT: 5 BOOK(S) 
 
 Fig. 6. Interactive Searching on the SI 02 Screen 
 
 results would be displayed as a numerical total of the number of records 
 found, rather than the first of these records being displayed in its entirety. 
 Fig. 5 shows a total of five records found that meet the search criteria. The 
 librarian now has the choice of asking for each of the full bibliographic 
 records to be displayed in turn, or of keying additional search criteria that, 
 when added to the previous search request, would reduce the number of 
 records found. This second option is shown in Fig. 6. Such iterative searching 
 would produce the same result as displayed in fig. 4. Figs. 5 and 6 illustrate 
 (very simply) the interactive searching capabilities of the system. 
 
 ORDERING 
 
 If the search described in the previous section has produced the desired 
 record, and the library decides to order the book, then the terminal operator 
 requests an ordering (OR01) screen for the same bibliographic record. This is 
 shown in fig. 7. The terminal operator fills in the appropriate information: 
 vendor data, accounting data, and enough additional information to produce a 
 purchase order. In fig. 7, the values in the unshaded fields were supplied by 
 the system as default options: PO (purchase order) for the method of 
 procurement, 01 for the address code (stands for Stanford University), 2 for 
 the special notification indicator (indicates that a notice is to be sent to the 
 requester when the material is received), and WED for the searcher's initials. 
 The system also supplied a request for one copy (1 c.) and the price ($10.00), 
 but the operator has changed this to 2 c. and $20.00. 
 
114 
 
 1 9 72 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 OROl 
 
 BMRC-S 
 
 72U05R9 
 
 ADD 
 
 DAN 
 
 SO 
 
 SHF 
 
 ORD^R 
 
 CLT 
 PO 
 
 si wen, 
 
 Fig. 7. Preparing a Purchase Order on the OROl Screen 
 
 
 OR01 
 
 BMRC-S 
 
 0\ 
 
 BAC Nl 
 R- 1 
 
 KOOIX 05 SHF 
 B 
 
 
 Rsn 
 
 
 OU 
 
 RCS 
 V- 1 
 
 - 
 
 
 vsn 
 
 
 
 vcs 
 
 
 
 VSP 
 
 
 
 VCT 
 
 
 CAT RUSH 
 
 
 ORM 
 
 
 
 ACQ 
 
 
 
 N- 
 
 
 
 Nsn 
 
 
 
 NCS 
 
 
 ORPRR 
 
 WED 
 
 Fig. 8. Corrected Ordering Screen 
 
 Many of the items on this screen are coded, since a considerable amount 
 of repetitive data is involved in the day-to-day use of this screen. For instance, 
 instead of putting in a specific vendor's name, a vendor ID is entered; the 
 system uses this ID to look up the vendor's name and address in another file. 
 
A USER 'S VIEW OF BALLOTS 1 15 
 
 Sini BMRC-S ORDER S WED 
 
 ENTRY PROCESSED 
 
 Fig. 9. Order Screen Accepted, Return to Begin Search Screen 
 
 In the example shown in fig. 7 there are three errors in the input. When 
 the operator has decided that the ordering information is complete and has 
 transmitted this information to the computer (by depressing the SEND button 
 on the keyboard), BALLOTS programs perform on-line editing of all the data 
 elements on the screen. As part of this, for instance, the budget account code 
 (BAG) is scanned and the codes and values file is searched: this check reveals 
 that the data contains an invalid code. As a result, the ordering screen is 
 returned to the user. An error code, indicating the invalid code, appears on 
 the screen preceding the BAG field. Error codes are also returned to the 
 operator indicating that the vendor ID is an invalid code and that a field 
 where a data element value is required is blank (the shelving location field- 
 SHE). When the screen is edited, the system moves the first line containing an 
 error up to the position of fourth line on the screen. The correct lines above 
 it are not displayed. When these errors have been corrected (see fig. 8), the 
 screen is sent a second time to the computer and the data is then accepted. 
 
 Once the final screen needed to perform a function is accepted by the 
 system, the transaction is considered complete and the system prompts the 
 terminal operator to go on to another activity by responding ENTRY 
 PROCESSED (see fig. 9). As a result of the successful on-line activity shown 
 in figs. 3-9, several outputs are printed overnight in the computer batch 
 partition. These outputs are the purchase order (fig. 10), a catalog work slip 
 (fig. 11) for use by the catalog department when the book arrives, and a 
 temporary order slip (fig. 12) for use by the acquisition department. 
 
 We have looked at a typical BALLOTS ordering cycle. The cataloging 
 cycle consists of a similar sequence of searching, input (using some different 
 screens), and output. This cycle will be discussed in a later section. 
 
 THE PROGRAMMABLE CRT TERMINAL 
 AND BALLOTS SOFTWARE CAPABILITIES 
 
 Several basic functions of the BALLOTS system were demonstrated in the 
 activities just described. But this interaction between the user and the CRT 
 terminal is only the tip of the iceberg that is the BALLOTS system. Having 
 looked at some initial uses of BALLOTS, we can now go a little further into 
 some components of the system. 
 
116 
 
 1972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 _/""\_ STANFOIO UNIVItSITT P U R C H A S 
 
 E ORDER i DA , e0 fo> 
 LJtFigHOiC<EIMtttMHiMi 
 
 OUDtt NO 
 
 O "2" 
 
 1 White, Jon Ewbank Manchip, 192i- 
 Cortes and the downfall of the Aztec E.ipire; a study 
 
 In a 
 
 
 conflict of cultures, by Jon 
 
 Manchip White. Jew York, St. 
 
 \o\ 
 
 Martin's Press [1971] 
 
 
 
 P 
 
 
 
 
 I 
 
 
 SHIP AJD BILL IN DUPLICATE TO: 
 
 b 
 
 
 Order Division 
 Stanford University 
 
 L ibraries 
 
 i 
 
 
 Stanford, CA 9i305 
 
 
 iO 
 
 
 
 
 is'Jc 
 
 i $20.00 | 
 
 "%bei )Wb*.*Kxx < 5rr^jsm 
 
 nxxsstfxyy x x 
 
 O H 
 
 
 DEALC8 SCf OJHEB SIDE 
 
 Fig. 10. Purchase Order 
 
 CATALOG WORK SLIP 
 F1230.J46 1971 
 
 72U0539 
 STK 
 
 White, Jon Ewbank Manchip, 192k- 
 
 Cortes and the downfall of the Aztec Empire; 
 a study in a conflict of cultures, by Jon 
 Manchip White, slew York, St. Martin's Press 
 [1971] 
 
 352 p. illus., maps, plans, ports. 25 cm. 
 
 Sibl iosraphy: p. L335]-339. 
 
 1. Mexico - History - Conquest, 1519-1540. 2. 
 Cortes, Hernando, U85-1547. I. TITLE. 
 DC:072/.02/092U 
 
 MS : N 
 
 Fig. 1 1 . Catalog Workslip 
 
 The terminal used in the BALLOTS system is the Sanders PDS 804 
 programmable CRT terminal. This terminal includes a microprocessor in its 
 hardware that permits specific computer programs to be loaded directly into 
 the CRT terminal. These programs control the display of data entered at the 
 keyboard and the communication of the terminal with the main computer. 
 The Sanders CRT terminal can display 1 ,920 upper- and lower-case characters 
 on a screen, in 24 eighty-character lines. The BALLOTS development staff 
 
A USER 'S VIEW OF BALLOTS 117 
 
 ORDER FILE 10/13/72 721U0539 
 
 White/ Jon Ewbank Manchip/ 192U- 
 
 Cortes and the downfall of the Aztec Empire; 
 a study in a conflict of cultures/ by Jon 
 Manchip White. New York/ St. Martin's Press 
 [1971] 
 
 F1230.WJ+G 1971 
 2 c. 
 
 VENDOR:Abel $20.00 
 
 PROrpo REQ. BY: SKI: 2 
 
 SHIP TO: 01 WED James Breedlove 
 
 3TK NKAOOU Resources Development Program 
 
 REC'D: Main Library 
 
 Fig. 12. Order Slip 
 
 were able to assign specific functions to certain keys (such as the paging 
 keys see the last paragraph under "Protocols and Commands" section), to 
 adapt the Sanders terminal to the uses of the system even further. 
 
 The BALLOTS terminal is programmed so that specified segments of lines 
 on the screen or ranges of lines on the screen can be considered as single data 
 element fields. These fields may be either protected or unprotected. A 
 protected field is one in which the user cannot input data, although the 
 system may display data there. During input at the keyboard, the cursor is 
 prevented from entering protected fields; this constraint is part of the control 
 program loaded in the terminal. (The cursor is a fast-blinking underline 
 character that indicates to the user his position on the screen.) When the user 
 is typing data in a field, he cannot type past that field into another field 
 unless a CR (carriage return) or TAB key is depressed. A CR will move the 
 cursor to the first input position on the next line; a lowercase TAB will move 
 the cursor to the first input position of the next field (which may be on the 
 same line or the next line). An upper-case TAB moves the cursor back to the 
 beginning of the current field. If the cursor is already at the beginning of the 
 field, it is moved to the beginning of the previous input field. 
 
 It should be pointed out that all of the features described here are 
 programmed into the terminal and are not part of the hardwired logic of the 
 terminal. This flexibility was one of the primary reasons for choosing the 
 Sanders programmable terminal. 
 
118 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 There are two types of input fields in the BALLOTS system. One is a 
 fixed length field and the other is an expandable field. In a fixed length field, 
 the amount of space is predetermined, and only the maximum number of 
 characters allowed for that field may be entered. If the user continues typing, 
 the cursor will not move to the next field, but will remain at the last 
 character position in the current field. Each additional character input will 
 simply overlie the previous last character. The only way to get to the next 
 field is to hit a TAB or CR key. 
 
 If data are being input to an expandable field and there is not enough 
 room preallocated on the screen, the user keeps typing. As soon as the first 
 character beyond the current end of the field is keyed, the microprocessor 
 recognizes this and immediately inserts a blank line following the overflowing 
 field, so that the continued data is input in this new line. (An expandable 
 field always extends to the end of the line.) All the lines on the screen below 
 the overflowing field are consequently pushed down one line on the screen, 
 whether they are protected (the cursor cannot enter them during input) or 
 unprotected (the user may alter their contents). Thus the user need not watch 
 the screen to see where the "end" of an expandable field falls, since the 
 computer will provide however much space is needed to input all the data. 
 
 Sometimes, when an input field expands beyond a single line, the last 
 word on a line may be split and continued on the next line. Although this 
 presents no problem for the computer software, it is difficult for the user 
 visually to verify the screen and is aesthetically displeasing. The micro- 
 processor software will therefore automatically adjust the data in the field, 
 reconnecting the broken word by moving the first half of the word from the 
 previous line down to the succeeding line. This adjustment takes place as the 
 user is keying data. 
 
 SCREEN FORMATS 
 
 Given these basic features of the terminal software, we can look at the actual 
 screen format developed for BALLOTS. The ordering (OR01) screen (fig. 7) is 
 the example used; but the rules and methods described here apply to all of 
 the BALLOTS screens. 
 
 1 . The first horizontal line of the screen is called the control line ; it consists 
 of the following fields: 
 
 A. The first field is the screen identification: OR01. This ID identifies 
 the screen format to both the user and the computer programs. 
 
 B. The second field is the file ID: BMRC-S. This ID notifies the user 
 that the BALLOTS-MARC file for Stanford is being used in display- 
 ing the data. 
 
 C. The third field is the record ID: 72140589. The search that 
 preceded the use of the ordering screen obtained a specific title. The 
 
A USER 'S VIEW OF BALLOTS 119 
 
 record ID of this title in the MARC file is 72140589 (this is also 
 its LC card number). 
 
 D. The fourth field is the function code: ORDER. The user supplies this 
 information, which describes the type of work the user will be 
 performing (in this case, ordering). (The use of this field is described 
 in the "Protocols and Commands" Section below.) 
 
 E. The fifth field is the library identification: S for Stanford University. 
 
 F. The sixth field in the control line is the terminal operator's initials: 
 WED. 
 
 2. The second line on the screen in called the message line. This is used by 
 the system to send messages to the user. In it the search argument is 
 redisplayed, together with the search results (see figs. 4 and 5). Other 
 possible messages include a warning that the system will be shut down in 
 thirty minutes, or any other communication that is required from the 
 computer system to the operator. 
 
 3. The third line is the command line; it is used for communication from the 
 terminal operator to the computer. This could be a request to conduct a 
 specific search or to display a specific screen. An entire command 
 language has been developed for the BALLOTS system that includes 
 commands for searching, requests for screens, logging on and off the 
 system, paging commands, etc. (Some of these commands will be dis- 
 cussed below.) Uses of the command line can be seen in figs. 3, 4, and 6. 
 In fig. 3 the command line has been used to request a search; in fig. 4 it 
 has been used to request an ordering screen; in fig. 6 it has been used to 
 add parameters to the search in progress. 
 
 4. The remaining lines on the ordering screen contain fixed length or 
 expandable fields. If the fixed length fields are short, more than one field 
 may be placed on the same line. This is shown in figs. 7 and 8. When a 
 field is expandable, it must be the only field on a line. The CAT field is 
 an example of this. The end of a field is shown on the screen by a "'." 
 The temporary end of an expandable field is shown by a "'"in the last 
 space on the line. 
 
 The first eight positions (character spaces) preceding each input field on 
 the screen follow a consistent pattern. The first two positions are for the error 
 code for the data element. If after a screen has been transmitted the on-line 
 editing detects an error, an appropriate error code will be displayed in these 
 first two positions (see fig. 8). Position 3 is usually protected, although it may 
 be used by the operator in certain cases to indicate updated data elements. 
 Positions 4, 5, 6, and 7 contain the data element mnemonics (right -justified). 
 Position 8 is blank and protected. From position 9 to the"'" mark is the user 
 input area. Some lines may contain more than one fixed length field. In these 
 cases the position allowance is the same for error codes and mnemonics (see 
 SHE on the BAC line in fig. 8). 
 
120 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 PROTOCOLS AND COMMANDS 
 
 An elaborate system of protocols has been developed in the BALLOTS 
 system. A protocol is a logical sequence of operations performed at the CRT 
 terminal, requiring specific screens. The function code in the control line 
 (ORDER in the preceding example) determines which protocol the terminal 
 operator will be following. These protocols prescribe the availability of screens 
 and commands to various parts of the library. Some screens are used only for 
 display; others are used for input and update. Someone in the acquisition 
 department would not be making changes to the holdings portion of a record; 
 therefore, the holdings (HH01) screen would not be available to that depart- 
 ment. On the other hand, the acquisition department would use the ordering 
 screen in order to input vendor information and pricing information; but the 
 ordering screen would not be available to someone in the catalog department. 
 
 In addition to determining the uses of the various screens, the protocol 
 system presents a logical sequence of screens to the terminal operator for each 
 particular function. These screens are default options, and if the user does not 
 request a variance, they are automatically displayed one after the other as 
 each is successfully completed. For example, on the third line of fig. 4, the 
 ordering protocol automatically supplies the next screen request for the 
 ordering (OR01) screen; this is the default request following the display of a 
 full bibliographic (BF01) screen. 
 
 A protocol map of the ordering function is shown in fig. 13. This is a 
 simplified diagram representing the protocols (sequences of operations) 
 possible in ordering. The default path is shown by the heavy line, and the 
 available options are shown by light lines. The options available at any point 
 in the protocol are shown on the horizontal line just below each CRT screen. 
 For example, when the full bibliographic (BF01) screen is in use, the user 
 may: 
 
 1. go directly to an ordering (OR01) screen (default option), 
 
 2. page to the next bibliographic record of several found in a search, 
 
 3. request a bibliographic input (BI01) screen, 
 
 4. request a supplementary input (BI02) screen, 
 
 5. begin a new search, 
 
 6. continue interactive searching (SI02), or 
 
 7. request a fresh search (SI01) screen. 
 
 Each protocol automatically displays certain commands in the third line 
 of the screen; these can be changed by the user if the default option is not 
 desired. (This will be illustrated below, in the "Cataloging" section.) There are 
 several types of commands. One type tells the system which screen the 
 operator wants to use next. These commands are simply the screen IDs (SI01, 
 HH01, BI01, etc.) A second type instructs the system on how to handle the 
 contents of the current set of screens. For example, the ENTER command 
 
A USER 'S VIEW OF BALLOTS 121 
 
 would cause all of the data elements on the current screen and on all previous 
 screens used for the same bibliographic record to be processed and used to 
 update the file. The CANCEL command would cancel all the steps taken so 
 far by the current protocol. 
 
 A third type is the search commands. These commands use any of the 
 available file indexes; search terms can be combined by using the logical 
 operators AND, OR, NOT. An example of the first of these logical operators 
 is shown in fig. 3. Here all three criteria must be satisfied in each record 
 found. If the operator is not sure of a search term, he can input likely 
 alternative terms using the OR operator. This approach will produce a larger 
 number of search results. If the operator has determined certain elements that 
 will not be part of the result he is after, he can include these following the 
 logical operator AND NOT, and thus further refine his search criteria. 
 
 Paging commands are used to instruct the system to display additional 
 data. If the contents of a particular bibliographic record are too large to be 
 displayed on a single screen, these commands would allow the user to "page" 
 forward (by displaying succeeding lines of the record) or backward through 
 the record. This is accomplished by keying "+(P)" (for page forward) or 
 "-(P)" (for page backward) in the command line. The BALLOTS CRT termi- 
 nal has a special key to accomplish this. When a search has produced several 
 bibliographic records, the operator may need to review each of the records 
 found. By requesting a display of the first record and then paging forward to 
 the other records, the operator could inspect the search results until he found 
 the correct record. This is accomplished by keying "+B" (for next biblio- 
 graphic record) or "-B" (for previous bibliographic record) in the command 
 line. Again, the BALLOTS CRT terminal provides a special key to accomplish 
 this. 
 
 There are many more commands in the BALLOTS system; they are 
 described in the BALLOTS reports listed under "Selected References." 
 
 CATALOGING 
 
 The searching and ordering cycles were described above in very simple terms. 
 In describing the cataloging cycle, we can draw on some of the concepts since 
 covered. Fig. 14, for instance, is a protocol map for the cataloging function. 
 Assume that the book ordered in "ORDERING" has been received and has 
 been sent to the catalog department. This time, with book in hand, the 
 operator (the cataloger) can key in a simpler search request. This request is 
 shown in fig. 15 and consists of simply the find command, the index term 
 mnemonic for LC card number (CRD), and the actual LC card number. (The 
 index term refers to one of the indexes to the MARC file.) The hyphen in the 
 number could be eliminated and the search request would still locate the 
 
722 
 
 7972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 Fig. 13. Ordering Function Protocols for the MARC Module 
 
A USER'S VIEW OF BALLOTS 
 
 123 
 
 a At tins point, the results determine the direction taken. If search 
 results are zero, the operator is again presented with the SI01 screen. 
 If one record is found, it is displayed on the BF01 screen. If two 
 or more records are found, the operator is told so on the SI02 screen. 
 
 1 The FINd command can be modified through the use of Boolean operators. 
 At each stage in the search, an up-to-date form of the search request 
 is displayed in the message field of the screen. The operator does not 
 repeat or rephrase the request already issued, but adds modifying criteria 
 to it. 
 
 ' The default command, prompted in the screen's command line. 
 
 The actual commands are " + B" and "-B" for paging from one record to 
 another, and "+(P) n and "-(P)" for paging within a record. 
 
 c Optional screens. If they are not used, data is taken directly from 
 
 f 
 
 the MARC file (BMRC) to produce outputs. 
 
 Here, "IGNore" could also be "IGN/BI02" or "IGN/OR01." 
 
 Here, "IGNore" could also be "IGN/OR01." 
 
 Mandatory screen. 
 
 Here, "ENTer" could also be 
 
 'ENT/FIN<search request>" 
 
 ENT/SIOl" 
 
 1 E NT/ SI 02" 
 
 ENT/BF01" 
 
 'ENT/DIS" 
 
 ENT/SET" 
 
 'ENT/LOGOFF." 
 
 Fig. 13. Ordering Function Protocols for the MARC Module (cont.) 
 
124 
 
 1972 CLINIC ON APPL1CA TIONS OF DA TA PR OCESSING 
 
 Fig. 14. Cataloging Function Protocols for the MARC Module 
 
A USER'S VIEW OF BALLOTS 
 
 125 
 
 At this point, the results determine the directions taken. If search 
 results are zero, the operator is again presented with the SI01 screen. 
 If one record is found, it is displayed on the BF01 screen. If two 
 or more records are found, the operator is told so on the SI02 screen. 
 
 The FINd command can be modified through the use of Boolean operators. 
 At each stage in the search, an up-to-date form of the search request 
 is displayed in the message field of the screen. The operator does not 
 repeat or rephrase the request already issued, but adds modifying criteria 
 to it. 
 
 The default command, prompted in the screen's command line. 
 
 The actual commands are " + B" and "-B" for paging from one record to 
 another, and "+(P)" and "-(P)" for paging within a record. 
 
 Optional screens. If they are not used, data is taken directly from the 
 MARC file (BMRC) to produce outputs. 
 
 ' Here, "IGNore" could also be "IGN/BI02" or "IGN/HH01." 
 9 Here, "IGNore" could also be "IGN/HH02." 
 Mandatory screen. 
 
 ' Here, "ENTer" could also be ' EN T/FlfKsearch request>" 
 
 ENT/SI01" 
 ENT/SI02" 
 ENT/BF01" 
 ENT/DIS" 
 ENT/SET" 
 ENT/LOGOFF." 
 
 Fig. 14. Cataloging Function Protocols for the MARC Module (cont.) 
 
126 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 SI 01 BMRC-S CATALOG S MDS 
 
 fin crd ~72-U05*9 
 
 Fig. 15. Initial Search Input Screen 
 
 BFOl RMRC-S 721U0589 CATALOG S MOS 
 
 fin crd 72-U0589 RESULT: 1 BOOK(S) 
 HH01 
 White, Jon Ewbank Manchlp, 192U- 
 
 Cortes and the downfall of the Aztec Empire; a study In a conflict of 
 cultures, by Jon Manchlp White. New York, St. Martin's Press [1971] 
 
 352 p. Illus., naps, plans, ports. 25 cm. <10.00 
 
 Blhl lography: p. [335]-339. 
 
 1. Mexico - History - Conquest, 1519-15UO. 2. Cortes, Hernando, 1U85-15U7. 
 I. TITLE. 
 72-1U0589 
 
 F1230.WUR 1971 972/. 02/0<m 
 CPrnyu L:eng REC:am MS:N ORn : 10/13/72 
 
 Fig. 1 6. Cataloging Search Results 
 
 record. If the LC card number had been known at the time the book was 
 ordered, it could have been used as a search term as well. 
 
 Fig. 16 shows the results of the cataloger's search. This is essentially the 
 same screen that was displayed to the acquisition department operator when 
 his search had been successfully completed (fig. 4), with the following 
 differences. On the first line of the screen the system copied the function 
 (CATALOG) and the operator's initials (MDS) from the previous SI01 screen. 
 The second line, the message line, reports FIN CRD 72-140589 RESULT: 1 
 BOOK(S). The third line, the command line, displays the next command in 
 the cataloging protocol, a request for the holdings (HH01) screen. The rest of 
 the screen is the same as fig. 4 except for the last line, where the ordering 
 date, recorded at the time of ordering, has been added. 
 
 Reviewing the book in hand and comparing it with the data displayed on 
 the screen (fig. 16), the cataloger notices that the publisher and place of 
 publication given in the book are different from the data found in the MARC 
 file. The file data must therefore be corrected before catalog cards can be 
 produced from it. Since the bibliographic data displayed in fig. 16 are 
 protected and cannot be altered by the operator, an input screen must be 
 used to change them. The operator accomplishes this by overriding the default 
 command line (HH01) with the command BlOl-a request for the 
 bibliographic input screen. (The terminal operator is thus using one of the 
 
A USER 'S VIEW OF BALLOTS 127 
 
 BIOl BMRC-S 72U0589 CATALOn S Mf)S 
 
 HH01 
 
 ME- pn White, Jon Ewhank Manchlp, 192U- 
 TSUT 
 
 1ST Cortes and the downfall of the Aztec empire; 
 TSSR a study In a conflict of cultures, 
 TSRT hy Jon Manchlp White. 
 
 ED ^^^^^^^^^^^ / 
 
 PP London, Hmlsh Hamilton 
 n [IQTl] L *nr, CP nyu 
 
 PG 352 p. 
 ILL Mliis., naps, plans, ports. / 
 
 SZ ?5 cm. 
 
 LPR 10.00 RPC am 
 
 TSTI yx CRD<72-ll05q / NUC MS N 
 
 SRN 
 
 LC F1230.WU6 1<171 
 LCA 
 
 DC 972/.02/092U 
 SST SCH 
 
 AM- 
 PUX 
 RIP 
 
 Fig. 17. Correcting a Record on the Bibliographic Input 
 
 HHOl BMRC-S 721U0589 CATALOG S MDS 
 
 ENTER 
 
 LC F1230.WI6 1971 
 LCA 
 DC 972/.02/092U 
 
 CAL / 
 
 CT Y, ETC LA, SC, L / CKMDS> 
 
 SL Yx FMI * , 
 
 LOC 
 
 nn 
 
 LOC 
 BD 
 
 F 
 P 
 
 LOC 
 BD 
 
 LOC 
 BO 
 
 Fig. 18. Default Holdings (HHOl) Screen 
 
128 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 SI 01 BMRC-S CATALOfi S MDS 
 
 ENTRY PROCFSSFf) 
 
 Fig. 19. Holdings Screen Accepted, Return to Begin Search Screen 
 
 other options in the catalog protocol. This is shown in the shaded portion of 
 fig. 14.) When the operator sends this screen to the computer (by depressing 
 the SEND button on the keyboard), the system responds by displaying the 
 modifiable bibliographic input screen. The operator then moves the cursor to 
 the tenth line (PP) and types in the correct publishing information (fig. 17). 
 
 After this screen has been entered and has been accepted by the system, a 
 default holdings screen would be displayed (fig. 18). The operator would enter 
 the information shown in the shaded areas. The LC default data in the CAL 
 field, if left unchanged by the cataloger, indicate that the cataloger accepts 
 the LC call number. The entries after the ETC data element describe the 
 additional copies of the catalog card requested-in this case, for the Latin 
 American, Sacramento State Union, and New Acquisitions catalogs. The next 
 two data elements input by the operator (LOC and BD) are the permanent 
 shelving locations and the bibliographic descriptors (copy and volume) of the 
 two copies. Here, copy one is located in the main stack and copy two is 
 located in the Institute of American History Library. 
 
 When the holdings screen has been completed and sent to the computer, 
 acceptance of it by the system (showing that the catalog build protocol-see 
 fig. 14-is completed) is signified by the appearance of the search input (SI01) 
 screen (fig. 19). The message line on the screen shows that the holdings entry 
 was accepted by the system and the operator is free to go on to the next 
 task. The SI01 screen is the default screen to begin any new operation. 
 
 Commands can be linked in order to reduce the number of screens 
 required to process a book. For example, the operator can combine the 
 ENTER command (to complete the cataloging process) with the FIND 
 command (to search the file for the next book to be processed), keying both 
 commands in the command line (line 3). If both the entry and the search are 
 successful, a bibliographic display screen will appear for the next book, with 
 ENTRY PROCESSED and the search command displayed in the message line 
 (line 2). 
 
 As a result of the cataloging activity, a set of catalog cards and spine 
 labels will be produced. The default option entered by the system in the CT 
 (catalog cards) and SL (spine labels) data element fields in fig. 18 signified 
 "yes" to the production of these items. This is done in an overnight batch 
 operation. The computerized records for all of the catalog cards to be 
 produced for each physical catalog will be collected and sorted in filing 
 
A USER 'S VIEW OF BALLOTS 129 
 
 sequence by the system before the cards are actually printed. Figs. 20 and 21 
 are samples of main entry and shelflist catalog cards. This completes the basic 
 cycle of cataloging a book found in the MARC file. 
 
 HARDWARE CONFIGURATION AND FILES 
 
 The BALLOTS CRT terminals are located in the Stanford Main Library in the 
 acquisition and catalog departments (see fig. 22). These terminals are con- 
 nected via twisted pair cables to a PDP-1 1 minicomputer in the Stanford 
 Computation Center. The PDP-11 can handle approximately thirty to forty 
 terminals. The PDP-11, in turn, is connected to an IBM 2701 parallel data 
 adapter, which is connected to a selector channel on the Stanford Compu- 
 tation Center campus facility's IBM 360 Model 67 computer. The 360/67 runs 
 the BALLOTS programs along with general timeshared and batch campus 
 computing jobs. The high speed printer at the Computation Center is an IBM 
 1403, capable of printing 1,100 lines per minute. All regular and special forms 
 for the library are printed on this high speed printer except for spine labels. 
 The spine labels are printed on an IBM 2741 typewriter terminal with a 
 modified platen. The spine labels are heat sensitive with a plastic covering to 
 protect the printed information. The characters are printed using an Orator 
 type ball, which was designed for IBM Selectric typewriters but can be used 
 on the 2741 typewriter terminal. 
 
 The BALLOTS files were stored on CDC 23141 direct-access disk drives. 
 Recently, the Stanford Computation Center (SCC) installed CDC 23142 
 double density direct-access disk drives to replace the 23141s. These provide 
 twice as much storage on disk packs of the same physical size as those 
 previously used. As a result, the BALLOTS file storage costs have been 
 reduced. 
 
 FULL SYSTEM DESCRIPTION 
 
 The full BALLOTS system is being implemented in a series of eleven modules 
 (self-contained sets of services). Each module will add services to the library, 
 including new forms, screens, and files. Everything described so far is con- 
 tained in the first module, called BALLOTS-MARC. Fig. 23 illustrates the 
 major features of each module. 
 
 The shaded portions of the figure are those aspects of the full system that 
 are incorporated in the BALLOTS-MARC module. This first module handles 
 the ordering and cataloging of titles found in the MARC file. The MARC file 
 shown in fig. 23 is preceded by the number 1 . This indicates that the MARC 
 file is available in the first module. The output documents produced by the 
 BALLOTS-MARC module are identified in the same way. These include 
 purchase orders, catalog cards, spine labels, process slips, standing search 
 
1 30 
 
 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 r'1230.WU6 Stack 
 
 Joi. Ewuar.k ft.incr.ip, 192U- 
 Coites .^nd *.a? Jew Mall ot the Aztrc 2ipir- :> ; 
 a study in a conflict ot cultures, by Jo a 
 Manchip auite. Loudou, 
 il lus. n'ca ii -i i 
 
 Htaiisn Hamilton, 
 ts. 2 e )cai. 
 
 Biblio 
 
 JJ5-J39. 
 
 1. Cortes, Hrrnaruio, 14o5-15UO. 
 History - Conquest, 1 r >1^-15UO. 
 SC L 
 
 O 
 
 2. Mexico - 
 I. TITLiS. LA 
 
 72-l405b9 
 
 Fig. 20. Main Entry Catalog Card 
 
 F1230.WU6 1971 
 I Ah: c.2 
 STK: c. 1 
 
 White, Jou EwDdnk ,'larichip, 192U- 
 
 Cortes and tL* downfall of the A-ztoc 
 a study 1:1 a conflict or cultures, by Jon 
 Manchip Wuitc. Lohdoii, Hamish riamilton, 1971 
 i^-lu^ ., daps, pj.aus, ports. 2bcm. 
 
 Biolio 
 
 335-339. 
 
 OSL 
 
 rtUS 
 
 O 
 
 Fig. 2 1 . Shelf List Catalog Card 
 
A USER'S VIEW OF BALLOTS 
 
 131 
 
 o 
 
 u 
 
 is 
 
 I 
 
 00 
 
 - 
 
 - 
 
 (N 
 (N 
 
 .2? 
 
 PL, 
 
1 32 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
A USER 5 VIEW OF BALLOTS 133 
 
 requests, and certain statistical and management reports. 
 
 The standing search request capability of the MARC module is a con- 
 venience to the library and performs a unique selective dissemination of 
 information (SDI) function for a specific title. In a search of the MARC file, a 
 title may not be found that the cataloger believes eventually will appear there 
 (because it is a recent publication in English). In such a case, the cataloger can 
 request that the system retain this search request and match it against all 
 incoming MARC records during each weekly update. If a match is found, the 
 cataloger will be notified on a special standing search request (SSR) notice. 
 
 The lower left-hand portion of fig. 23 itemizes the screens added to the 
 system with each new module. The BALLOTS-MARC module uses the full 
 bibliographic display screen (BF01), the bibliographic input screens (BI01, 
 BI02), the general system screen (GSOl-not described in this paper), the 
 holdings screen (HH01), the ordering screen (OR01), and the search screens 
 (SI01 , SI02). 
 
 The eleven production modules that make up the full BALLOTS system 
 are described below in the order in which they will be implemented. 
 
 1. BALLOTS-MARC. The library material processed by the MARC module is 
 English-language monograph material appearing on weekly MARC tapes. 
 (The restriction to English-language material is a consequence of the 
 current scope of MARC; all roman alphabet languages are supported by 
 this module.) The file in this module is an on-line MARC file of the most 
 recent six to twelve months of MARC records. The file is essentially 
 read-only, except for the addition of date codes for records processed by 
 users. The actual size of the on-line file will depend on the requirements 
 of the network libraries (see CLAN section below) balanced against file 
 storage costs. Purchase orders, process forms for technical processing files, 
 catalog card sets, and the spine labels are produced on request for any titles in 
 the MARC file. Automatic weekly searches to match user requests with 
 new additions to the file are available through the standing search feature. 
 In this first module no permanent on-line records are maintained during 
 technical processing other than the full MARC record, although a tape 
 copy of the records for each book cataloged is retained for later use. Such 
 on-line record keeping will appear in modules 2, 5, and 6. This module 
 processes approximately 35 percent of Stanford's acquisitions and 26 
 percent of its cataloging. The percentage of support to network library 
 processing (again, see CLAN section below) is slightly larger than the 
 Stanford figures in this and later modules. 
 
 2. MARC -IFF (MARC In-Process File). This module adds an in-process file 
 and additional printed outputs such as claim and cancellation notices, 
 when requested by library staff. Only MARC material is handled; when a 
 record is found in MARC it is transferred to the IPF and is retained there 
 as an updatable record throughout technical processing. Since the record 
 
134 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 will not be purged from the IFF until modules 5 and 6 have been 
 implemented, the file will represent all titles ordered and cataloged by the 
 library using the automated system. A record in MARC-IPF can be used 
 again if additional copies of a book are ordered. 
 
 3. Purchase Order/Original Cataloging. No new file is added with this 
 module, but the use of the IFF file is expanded considerably with the 
 addition of new bibliographic records input entirely at the terminals. 
 Acquisition and cataloging (NPAC-National Program for Acquisition and 
 Cataloging) notices can be produced. The scope of the material for which 
 a record is created is expanded. It adds all non-MARC roman alphabet 
 material that requires a purchase order in ordering, and any material that 
 requires original cataloging. Thus, if a record is not found in the MARC 
 file, a new IFF record is created using the terminal. This module will 
 process an additional 52 percent of acquisitions and 42 percent of cata- 
 loging. Thus services at this point will cover 87 percent of acquisitions 
 and 68 percent of cataloging. 
 
 4. Non-purchase Order Material. The scope of material added to the IFF is 
 expanded to include non-purchase order material receipt gift, exchange, 
 approval, and blanket orders. In addition, an invoice-claiming feature is 
 included to inform the acquisition department of material for which no 
 invoice has been received within thirty days. This module will process an 
 additional 7 percent of acquisitions and 6 percent of cataloging. Modules 
 1 through 4 will process a total of 94 percent of acquisitions and 74 
 percent of cataloging. 
 
 5. Catalog Data File (CDF). This module involves building the on-line catalog 
 data file. Since the implementation of module 1, BALLOTS will have 
 saved bibliographic information, and this data will be used to create the 
 CDF. From this point on, all catalog records will enter the CDF after the 
 record for a given title is no longer required in the IFF. As the CDF 
 grows, it will become an increasingly valuable reference tool for 
 acquisition, cataloging, and patrons' use. 
 
 When the Catalog Data File module has been implemented, it will be 
 possible for any searcher in the library to search the catalog data file 
 (CDF) for recent acquisitions shelved and in circulation, to search the 
 in-process file (IFF) for new titles on order but not yet cataloged and 
 shelved, and to search the MARC file for recent Library of Congress 
 catalog records in a single search request. As new acquisitions are added 
 to the collection, the catalog data file will become an extremely effective 
 reference tool. After two or three years of use, the catalog data file 
 should reflect all recent acquistions. Any new publication should be in the 
 catalog data file if the book is shelved, or in the in-process file if it is on 
 order. This eliminates a considerable amount of manual searching. 
 
 6. Inventory File. Machine-readable bibliographic and holdings records 
 
A USER 'S VIEW OF BALLOTS 135 
 
 already exist for all 60,000 titles now in Stanford's Meyer Undergraduate 
 Library. In this module, these records will be converted to BALLOTS 
 format and used to build an on-line Meyer inventory file (INV). At this 
 point, Meyer cataloging processing will work directly with the on-line file. 
 This file will be used later on for reference and for the patrons' access to 
 the complete holdings of the undergraduate library. Other libraries with 
 the entire collection in machine-readable form can be handled in a similar 
 manner. 
 
 7. Book Catalog. This module can be used to create any book catalog done 
 in the Stanford format. At Stanford it will allow the Meyer book catalog 
 to be produced directly from the INV file without going through the 
 punched card process presently used. 
 
 8. Automatic Claiming and Cancelling. This module adds programs to review 
 IFF records automatically, to determine if ordered material is overdue. 
 Material may be claimed several times and finally cancelled if the dealer 
 does not respond. The acquisition department may override a scheduled 
 claim or a cancellation. 
 
 9. Circulation. This module is designed to handle the complexities of the 
 research library circulation system. Using data from the inventory file, a 
 Meyer Library self-service circulation system will be implemented first, 
 including charging, discharging, initial check-in, circulation searching, 
 recall, holds, overdue processing, fine handling, and fine payments. 
 
 10. Standing Order and Out-of-Print Desiderata. The capability of establishing 
 standing orders (SO) and receiving the nonserial materials arriving with 
 SOs will be added with this module. In addition, out-of-print items (OP) 
 will be added to the IFF and search and quote letters produced for OP 
 dealers. If an OP item can be procured, it can be ordered using the record 
 already in the IFF. 
 
 11. Reserve Processing. This module adds reserve book ordering and pro- 
 cessing for users. It will be added to the services offered to Meyer staff 
 through the use of the INV and IFF. 
 
 The BALLOTS system design includes several features unique among the 
 major on-line library automation systems using CRT terminals (such as the 
 Ohio College Library Center OCLC-and the Experimental Library Manage- 
 ment System ELMS of IBM). The most notable of these are the program- 
 mable CRT terminal that aids the user in input and display; the protocol 
 structure and the command language associated with it; the standard screen 
 format; the fact that an entire screen is entered and processed at one time, 
 rather than just one data element; and the flexible interactive searching 
 capability. The method of searching used in BALLOTS was developed by a 
 sister project, SPIRES (Stanford Public Information Retrieval System), whose 
 connection with BALLOTS is outlined in the reports listed under "Selected 
 References." 
 
136 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 CLAN (CALIFORNIA LIBRARY AUTOMATION NETWORK) 
 
 The features of the BALLOTS system have been kept as generalized as 
 possible, so that the system could be adopted for use in other libraries. At the 
 present time, the staffs of two autonomous libraries at Stanford (The Law 
 Library and Lane Medical Library) and of five libraries in the San Francisco 
 Bay area are preparing for the implementation of parts of the BALLOTS 
 system in their libraries. These libraries have been reviewing the BALLOTS 
 specifications in order to note any changes or additions they require. To date, 
 the number of these changes seems to be very small, and they do not 
 represent any substantial modification of the BALLOTS system. Assuming 
 adequate funding, the plan for network implementation is as follows. 
 
 For the first four to eight months after a module has been implemented 
 and placed in operation at Stanford, it will be closely observed and 
 monitored. During this period, the network version of the module will be 
 checked out and tested for network use, and the network libraries will install 
 equipment and conduct training classes and acceptance tests. When all this is 
 completed, the module will be put into network pilot operation. Thus, the 
 module will undergo four to eight months of heavy use in its original version 
 prior to its network installation. This will reduce implementation time and 
 effort for the network users. 
 
 The BALLOTS system is intended to provide a library tool operating in 
 the library's daily production environment. The system was designed with 
 the help of the library, and will be used by the library staff. No special 
 terminal operators will be hired. Throughout the designing of the system, 
 continual efforts were made to create a system as convenient and useful as 
 possible to the library staff. At a number of points in the system, smoothing 
 the way for the user has meant increasing the complexity of the BALLOTS 
 analysts' and programmers' tasks. This paper has made no attempt to describe 
 the programmed structure underlying BALLOTS operations. Rather, it gives 
 an overview of these operations as they are seen and participated in by the 
 librarian or technical processing assistant. 
 
 Selected References 
 
 The following publications describe the initial planning and designing of 
 
 BALLOTS, the development of the proposed network, and the evolution of 
 
 the system from 1967 to 1971. 
 
 Epstein, A.H., et al. "An On-Line Network Cooperative Planning with Several 
 Libraries." In Jeanne B. North, ed. ASIS: Proceedings of the American 
 Society for Information Science. Vol. 8. Westport, Conn., Greenwood 
 Publishing Co., 1 97 1 , pp. 227-3 1 . 
 
 Final Report, Project No. 7-1145, Grant No. OEG-1-7-071145-4428, 
 
 Bibliographic Automation of Large Library Operations using a Time-sharing 
 System: Phase I. Stanford, Calif., Stanford University Libraries, 1971. 
 
A USER 'S VIEW OF BALLOTS 137 
 
 Final Report, Project No. 7-1145, Grant No. OEG '-0-7 '0-2262, 
 
 Bibliographic Automation of Large Library Operations using a Time-sharing 
 System: Phase II, Part 1. Stanford, Calif., Stanford University Libraries, 
 1972. 
 
 Montague, Eleanor. Summary of a Feasibility Study on the Participation of Four 
 Colleges and Universities in a Stanford University Library Automation 
 Network. Stanford, Calif., SPIRES/BALLOTS Documentation Office, 1971. 
 
 SPIRES/BALLOTS Project Staff. System Scope for Library Automation and 
 Generalized Information Storage and Retrieval at Stanford University. 
 Stanford, Calif., Stanford University, 1970. 
 
ELLSWORTH MASON 
 Director of Library Services 
 
 Hofstra University 
 Hempstead, New York 
 
 Automation, or Russian Roulette? 
 
 I feel somewhat like Daniel must have felt in the lions' den, and if I respond 
 in something like an ominous roar, let me make clear that I address myself 
 primarily to card-carrying, dogmatically convinced computerators who have 
 wrapped themselves in the security blanket of the computer, and do not dare 
 to think about the basic problem that it presents to librarianship. If this kind of 
 computerator gets mad at some of the things I say, it is because his ego is 
 involved in the computer, the worst form of slavery for man; if he does not, 
 it indicates he is still capable of independent thought about the basic 
 problems, and there is some hope. 
 
 When I was first invited to speak at this clinic because my point of view 
 was "controversial," I thought that, despite the cliche, this would open 
 discussion on the merits of computerizing library operations. After seeing the 
 preliminary program, it was clear there would be no discussion. Rather, I was 
 to be the clinic's token Black. This impression of rank discrimination is 
 reinforced by the fact that I am the last of nine speakers, a kind of soft -shoe 
 shuffle act after the play is over to ease the stir of the audience as it begins to 
 depart. 
 
 We Blacks realize what a powerful "establishment" computerators are. 
 One reply to my May 1971 College & Research Libraries article 1 pointed out 
 that the public relations apparatus of computerators is second only to that of 
 the Pentagon. And on the whole, library computerization still wears a jaunty 
 mantle, like that of Superman, which cloaks it from rules that govern every 
 other aspect of librarianship. But it is no longer new, and the cloak is wearing 
 threadbare. Ellipses of fat are seen jouncing through the shredded cloth. As 
 Tennyson once said, "The old order changeth, yielding place to new," and the 
 endless hoard of gold flowing from the cornucopia has dwindled to a trickle 
 of sand. We are all bankrupt. 
 
A UTOMA TION, OR R USSIAN ROULETTE? 139 
 
 Let me therefore touch lightly on the financial conditions of some of the 
 universities whose prime public relations pieces have been polished up for 
 exhibition during this clinic. 
 
 Two years ago, when I viewed the new Northwestern University Library,! 
 learned from the director that his book budget for the center campus library, 
 where the bulk of demands from a very broad, richly developed program of 
 graduate studies is registered, was less than ours at Hofstra, which is still 
 emerging and has small commitments to a graduate program. When I visited 
 the University of California at Los Angeles Library in 1970, there was severe 
 understaffing in its branch libraries, and its lack of funds for collection 
 development has now become notorious in the profession. In the last two 
 years it has cut its faculty by 200 positions. Stanford University had discon- 
 tinued significant academic programs, and its president is among the most 
 honest in his forthright declaration that they are unable to afford what they 
 are now doing, despite a mountainous endowment. What university is not in a 
 condition of financial restriction? Yet for the past two days we have been 
 hearing of on-line systems, the most expensive condition of computerization. 
 Under these financial conditions, which are not temporary, how long can we 
 go on spending money for playthings? In my estimation, library computeri- 
 zation has about three years left, during which either joint-sharing or mini- 
 computers will prove beyond a doubt the economic necessity of the 
 computer, or it will go. 
 
 When speaking to theologians, one should speak from Holy Script. I, 
 therefore, take as my text Forrester's Law, which states that in complicated 
 situations, efforts to improve things often tend to make them worse, 
 sometimes much worse, and on occasion calamitous. According to Forrester, 
 in complicated situations the obvious thing to do is often dead wrong. With 
 the slides greased in advance by Vannevar Bush and Buckminster Fuller, and 
 oiled by John Kemeny of Dartmouth, librarians slipped into the assumption 
 that the obvious answer to the complexities of radically expanding libraries 
 was computerization of operations. This assumption is dead wrong in general, 
 and I have been exploring for some time to determine whether it is wrong in 
 every particular as well, with no clear indication as yet that it is not. This, 
 briefly, is my central text. I will attempt to bring computerators to realize the 
 depth of their sins, and to lead them to a glimpse of a better world, where 
 the reward is honest living. 
 
 Perhaps I should begin with the basic heresy, which I did not invent but 
 did reassert in my earlier article, 1 that the computer poses a managerial 
 problem no different than any other aspect of the library, whether staff, 
 materials or other machines. One must think about the reasons for using it 
 and justify its costs. The responses to that article were varied. One group 
 wanted me to launch a Moslem holy war, a Jiddah, against the Christian dogs. 
 Four computer specialists, two teaching in graduate library school and two in 
 
140 1972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 charge of library computer operations of some consequence agreed that the 
 whole field was a farce, and ought to be wiped out. 
 
 Within a month of my article, Daniel Melcher's article appeared in 
 American Libraries, 2 stating essentially the same things about library com- 
 puterization, although we had never met or corresponded. When I wrote to 
 him objecting that his optimistic conclusions about the future of computers in 
 libraries were not justified by either his view or the substance of his article, he 
 replied that I had misread him, that he did not really believe that computers 
 would ultimately be economically justified in libraries. Since Melcher had 
 applied the computer extensively in his own publishing operations, he cannot 
 be viewed as lacking in practical knowledge. 
 
 There followed an ad hoc evening session of LARC at the Dallas ALA 
 meeting chaired by William Axford, with Allen Veaner as speaker discussing 
 my article, 1 and with much audience participation. This resulted in a 
 pamphlet by Veaner published by LARC. 3 Veaner gave a good, reasonable 
 discussion of my paper. However, only a few asked themselves the question, 
 "Is Mason really talking about me?" Everyone seems to have assumed that my 
 article referred to computer projects other than theirs. 
 
 There have emerged since then, in letters and in print, some sharp dif- 
 ferences among library computerators about some very basic issues, with 
 eminent practitioners standing firmly on both sides. Is it possible to control 
 with any degree of sensitivity the quality of programming in a system? I am 
 told by one eminent computerator in Los Angeles that it is not possible, and 
 by another in New York that it is. Is it possible to transfer generally systems 
 of programs from one computer to another? I am informed from Arizona that 
 it is done all the time, and from California that it is possible under rare, 
 optimal conditions to transfer limited programs, but that the chances of 
 transferrring a system without accepting totally the same computer machinery 
 are virtually nil. I can add from recent experience on the Hofstra campus that 
 transferring a series of comparatively simple housekeeping programs from an 
 IBM 1130 to a Spectra 7046 has been agonizing, and for a large number of 
 programs impossible, with much reprogramming necessary. 
 
 Does multiplying computerized operations by stringing them together in a 
 system make them economical? From California, I hear claims that the 
 systems approach automatically makes everything economical, from Massa- 
 chusetts, that there is no evidence it does. Is it economical to computerize 
 circulation? From many places I am told this is one of the best operations in 
 which to achieve economy; from New York, the word comes that no one can 
 beat eight to ten cents a manual circulation with computers. And so it goes, 
 vocal opinions on both sides about the economical feasibility of computerizing 
 acquisitions, serials, etc. From these contrapuntal choruses of computer 
 experts I conclude that the field does not really know what it can do 
 successfully, and in what terms, and for what aims. In a very real sense, the 
 
A UTOMA TION, OR R USSIAN ROULETTE? 141 
 
 entire field of library computerization is a floating world. This condition by 
 no means warrants the divine conviction that descends, like the Holy Dove, 
 on librarians who computerize operations. 
 
 This floating-world mentality is apparent in many responses to my 
 article. 1 While my central point was that the computer could not be justified 
 on the grounds of cost, answers like the following were forthcoming: "It's 
 successful." Whether successful in operational, public relations, or economic 
 terms is not mentioned. This is the kind of floating nonthought that angers 
 me because it indicates a total disregard of aims and economics. "Under- 
 graduates like it." Undergraduates like sex, too; are we therefore to provide it 
 in libraries? "Everyone is pleased with it." This makes it sound like a rose 
 garden, emphasizing the charm of the computer. In his Dallas speech, Allen 
 Veaner states the following: 
 
 There are numerous successful applications that he [Mason] failed to 
 mention or ignored completely. The Ohio College Library Center has a very 
 successful card production system based on MARC tapes. Another, is the New 
 York Times Information Bank that is about to become operational. There is the 
 Ohio State University circulation and book information systems that represent a 
 notable extension to traditional library services, and would not have been 
 possible without the computer. What about Northwestern University's self- 
 service book charging system? The Harvard University circulation system and the 
 Harvard shelflist conversion project have been in progress for many years, as has 
 the University of California Union Catalog Supplement project. 4 
 
 Now, my central argument was that the computer costs too much, but 
 Veaner does not even mention costs. The Ohio College Library Center at that 
 time was still in a batch system of card production that was 50 percent more 
 expensive than reasonably good MT/ST card production. The New York Times 
 Information Bank was not running in June 1971, is not running yet in April 
 1972 (after an expenditure of from three to four million dollars), and 
 according to recent reports there is no certainty that it ever will run success- 
 fully in the terms it was originally conceived, and almost certainly will not be 
 economically justifiable. 5 (Note that Veaner, a highly intelligent man, scolds 
 me for ignoring a successful computer application that does not even exist. 
 This is the kind of dislocation of brains that occurs among computerators. It 
 must have something to do with machine vibrations.) 
 
 Ohio State University Library's circulation system interests me very 
 much, but Veaner does not mention its staggering development costs or its 
 operational costs of approximately $300,000 a year. Northwestern University's 
 charging system is a prime example of an operation that was computerized as 
 a public realtions piece, and the 50-page report of this system 6 makes no 
 mention of costs other than the costs of punching book cards. Is this not 
 fraud, that a totally detailed analytical account of a library operation makes 
 no mention of operational costs? If we are to defend Harvard's and Cali- 
 
142 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 fornia's systems on the grounds that they "have been in progress for many 
 years," and with no reference to costs, then most library operations can be 
 defended on exactly the grounds on which computerators have attacked them. 
 
 What Veaner means by calling these operations successful is that they are 
 running, and I return once more to my basic point: when you are running 
 you are in a race, you are competing. The question is: What can these 
 computerized operations compete with, and in what terms? It is precisely to 
 this question that I am urging the entire field of library computerization. But, 
 as I have tried to indicate, one of the characteristics of this field is a highly 
 visible floating mentality that refuses to ask precise questions in a detailed 
 manner about the aims and intentions of computerization about why it is 
 being done at all. 
 
 This mentality has been encouraged by an elaborate smoke screen that has 
 sheltered the entire field from the probes of reality. From the beginning, and 
 as late as Henriette Avram's speech with me to the New York Technical 
 Services Librarians in November 197 1, 7 it has demanded "a privileged 
 sanctuary not accessible to any other library operation, freedom from cost 
 challenge." 8 
 
 The first component in this smoke screen was the assumption that 
 librarianship was behind the times, that the times were represented by 
 industry, and that industry should be copied. To one who grew up during the 
 Depression amidst stark evidence that industry did not know what it was 
 doing, the notion that all is right with the industrial world is curiously 
 perverse. Be that as it may, the argument proceeded on economic grounds, 
 replete with graphs and diagrams, to indicate that operating expenditures in 
 academic libraries were increasing so fast that they were likely to ruin the 
 entire economy. Fig. 1 is a graph from a report by Mathematica entitled On 
 the Economics of Library Operations, submitted to the National Advisory 
 Commission on Libraries in 1967. The Wholesale Price Index, the cost of 
 goods produced in our economy, is fairly stable from 1951-1966. Included is 
 a comparison of the increase in the amount spent for library salaries per 
 student enrolled (oooo), and the amount spent for library materials per 
 student enrolled (xxx). These comparisons are made on the assumption that 
 universities are factories producing students as commodities. If this assumption 
 is accepted, then it follows that the costs of library salaries and library books 
 have increased faster for each unit of commodity manufactured by univer- 
 sities, than have the costs of commodities in the economy as a whole. But this 
 is both ignorant and ridiculous! 
 
 First of all, it assumes that the books bought each year and the staff 
 services each year serve only the students enrolled during that year. Some of 
 libraries' services such as circulation, are indeed consumed on the spot, but 
 the books remain, and all the services that shape finding tools and the 
 location of books in the collection are permanent additions. A large part of 
 these costs is capital investment, not operating costs. 
 
AUTOMATION, OR RUSSIAN ROULETTE? 
 
 143 
 
144 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 Beyond this ignorance lies the basic fallacy of comparing the cost of 
 commodities with the costs of operating a library, which is basically a service 
 industry. There is little comprehensive information about trends in the costs 
 of services in our economy, but we do know that each year a larger and larger 
 proportion of the gross national product goes into services and that their costs 
 are escalating rapidly. If the graph in fig.l had compared the costs of 
 instructional salaries and equipment per student enrolled, it would un- 
 doubtedly have shown that they had gone up even faster than library costs; 
 both together would have indicated what we all know-that a greater portion 
 of the gross national product went into higher education after 1951 than ever 
 before. The sharpest increases in staff salaries and book purchases per student 
 begin in 1960, a short time after Sputnik, when the American public decided 
 that education was the answer to everything. To compare the costs of 
 producing commodities with the costs of services tells absolutely nothing 
 about either of them. 
 
 Nevertheless, continuing along the lines of pseudo-economics, a group of 
 librarians proceeded to argue that libraries must come into line with industry, 
 that industrial productivity increases about 3 percent a year, while library 
 productivity remains relatively the same. Industrial productivity increases, the 
 argument goes, by application of machinery especially the computer. The 
 computer must therefore be applied to the library to bring its costs in line 
 with those of the overall economy. 
 
 Once again we are comparing the production of commodities with a 
 service industry, but this time we are on unfirm factual grounds. Unfortu- 
 nately, the figures on which our analysts have leaned so heavily (Kilgour 
 revived this red herring in American Libraries for February 1972) 9 end with 
 
 1966. In the meantime, we have learned things about our economy. Since 
 
 1967, and at a time when industry has been technologized as never before, 
 and when perhaps 80,000 computers were being used in industry, the increase 
 in productivity ground nearly to a halt. In 1969, which was a boom year, and 
 1970, productivity in output per man hour increased less the 1 percent each 
 year. 10 
 
 This fact has been pointed up sharply by Kenneth Boulding, a high 
 ranking economist, in a speech delivered at Wright State University, in January 
 1972. He pointed out that while productivity in our economy has been 
 increasing 2 to 4 percent a year for the past century, it has hardly increased 
 at all in recent years. He concluded, "Automation seems to be a total fraud. 
 There is not the slightest evidence of greatly increasing productivity in 
 manufacturing processes." 1 ' 
 
 The absence of a surge in productivity as we increased the use of 
 computers in industry over the past twenty-five years does not seem to 
 support claims for the machine by library computerators. Skepticism about 
 computerization is not confined to me and Kenneth Boulding. Last August, 
 
A UTOMA TION, OR R USSIAN ROULETTE? 145 
 
 the annual conference of the Association for Computing Machinery, meeting 
 on the twenty-fifth anniversary of the invention of the electronic computer, 
 was a highly critical, self-lacerating session. A significant paper by Harvey 
 Golub, a principal in McKinsey & Company, an important New York 
 computer consulting firm, described the life cycle of a systems development 
 project as follows: Phase I Wild enthusiam, Phase II-Disillusionment, Phase 
 Ill-Total confusion, Phase IV-Search for the guilty, Phase V-Punishment of 
 the innocents, and Phase Vl-Promotion of nonparticipants. 1 2 
 
 Beyond this note of humor, Golub cited a survey he had recently made of 
 100 companies in eleven industry groups, which showed conclusively that 
 investment in computers did not give a company any significant competitive 
 advantage. In fact, four of the industry groups "exhibited essentially a 
 negative correlation between investment in computers and results." 1 3 That is, 
 the more the investment in computers, the less the results. He concludes, 
 "The companies that do well today are not those with lots of computers but 
 rather those with able management in depth." 14 This may account for a 
 recent report of a large library with a computerized circulation system that 
 takes a week to reshelve books after they are discharged. 
 
 These views from nonlibrarians do not support the view that application 
 of the computer to library operations will automatically increase productivity; 
 indeed, if it costs more to do essentially the same things, productivity will 
 decrease. I think that the get-with-industry smoke screen has by now been 
 demolished. 
 
 Two other reasons advanced by computerators for absolving themselves of 
 cost accountability were that collection growth was escalating at an angle of 
 85 degrees, and that there was a severe shortage of librarians. With the onset 
 of a realistic economy in the academic world, and radical cuts in book 
 budgets during the past two years which will continue, if not increase, in the 
 future, we find that the escalation curve in processing has leveled off or 
 declined. At the present time, the demand for library school graduates pre- 
 cariously meets the supply. In 1973 there will be a surplus of graduates. 
 
 I will devote the rest of my talk to the cost of both conventional 
 operations and computer operations. It is clear to me that librarians will have 
 to defend every nickle they spend in terms of effectiveness in the very near 
 future, or have it taken away from them. So let us see what cost problems 
 are, and how to go about establishing whether or not it is justifiable to apply 
 the computer to any library operation. 
 
 There are four basic problems related to costs in computerizing library 
 operations: (1) the open-ended cost of development, with no ceiling on costs 
 at all; (2) the unpredictability of operational costs after the system is 
 developed and stabilized; (3) the lack of easily available information on costs 
 of competitive manual or manual -machine methods (i.e., what is a reasonable 
 circulation unit cost) to tell us whether what is being done by computer is 
 
146 1972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 extravagant or economical; and (4) the unwillingness of computerators to 
 approach the real complexities of determining the cost of their operations, 
 and set cost components in a list of priorities by their impact on unit costs. 
 
 The first problem has long ago been met by industry, which was so badly 
 burned in converting to second generation computers to the extent that it has 
 held off applying third generation computers because of programming costs. 1 5 
 In librarianship, it is clear that the do-it-yourself phase is over. No one can 
 really afford a programming staff, and the future will depend on the 
 feasibility of large group combination efforts, or easy transferability of pro- 
 grams, with local adjustments made by the central university computer staff, or 
 a single mop-up programmer. The other alternative is one which libraries 
 should have insisted on from the beginning that the computer industry take 
 the library's specifications and bring back a program ready to do exactly what 
 is wanted done, debugged, at a reasonable cost. This is likely to happen, since 
 no longer can a slick IBM salesman charm his bug-eyed, ignorant client into 
 believing that all he has to do is buy a 360/91 and gold will start showering 
 down on him in savings. 
 
 For the second problem, the unpredictability of operation costs, industry 
 is turning to outside service companies which either run the house computer 
 on the property, or perform the operations on an outside machine. In either 
 case, specified services are contracted at a known price, and can be dropped if 
 they prove unsatisfactory. As one executive said, "I would like someone to 
 take the cow away and start delivering the milk." 1 ' The closest librarianship 
 has come to this is with card production services, and I have seen none that 
 can begin to compete with conventional production costs. 
 
 The third problem is not as difficult as it seems, since good cost analyses 
 of "conventional" operations are being done all around the country. The task 
 of gathering and assembling them into a manual should be undertaken. All 
 that is needed is one thorough, reasonable cost analysis of a well-run manual 
 circulation operation to establish a target cost for comparison, and the figures 
 for such an analysis do exist, although they are diffused. 
 
 In the fourth problem, computerators are hesitating because they insist on 
 the possibility of a perfect cost accounting before they will try any. That is, if 
 it is not possible to determine to the fraction of a cent the assignable costs to 
 one operation of a systems group that is doing three things at once, they do 
 nothing. This feeling is unreasonable, since it is easy to obtain valid estimates 
 for purposes of comparison, which is the main purpose of costing at this point 
 in history. 
 
 The other difficulty is that few computerators understand what a valid 
 cost analysis is. During the past year, I have searched in vain for a thorough, 
 honest, reasonable and accurate cost analysis of any computerized library 
 operation. I had been told that a number existed, but upon investigation I 
 found there were really no cost figures available at all. 
 
A UTOMA TION, OR R USSIAN ROULETTE? 147 
 
 About a month ago, a professor of library computerization in a graduate 
 library school, with whom I have had a good-natured running dispute about 
 these matters for a long time, wrote me that a noted recently computerized 
 circulation system in an eastern state had figures that "beyond a shadow of a 
 doubt show money saved." 1 7 I wrote for the figures, and had a call from the 
 head systems analyst who informed me that he did not have any figures that 
 proved beyond a doubt anything. The only figures he had were for con- 
 sumables, and for machine run-time-no figures for systems salaries, no figures 
 for desk costs. That is to say, he did not even have a general idea of what his 
 unit circulation costs or total costs were. Yet this system is in the process of 
 being adopted intact by ten or more other universities who have no idea what 
 it is going to cost. 
 
 If you hired a librarian without setting his or her salary; if you bought a 
 collection of books without setting a price and asked the seller just to send 
 you a bill, denomination unknown, you would be fired on the spot. But you 
 can install a computerized circulation system under the same irrational con- 
 ditions and get a hero's medal. Is this librarianship? 
 
 There are three important reasons why careful cost control of everything 
 in libraries is needed at this time: (1) to be able to defend and maintain, in a 
 fiscal squeeze, those things that we most want; (2) to know what effects 
 budget cuts will have; and (3) to evaluate new changes as they come along. 
 
 Let me tell you what I have been sent as cost analyses for computerized 
 operations. The first group is from one of the most highly regarded library 
 computerized operations, a system which has been adopted by all libraries in 
 its state university system, and transferred to three other university libraries. 
 Figs. 2 and 3 comprise the cost analysis sent by its originator to convince me 
 of its cost effectiveness. The figures (fig. 2) for the circulation system indicate 
 numbers of transactions, machine run-time, and the machines required. The 
 figures for acquisitions (fig. 3) show the number of transactions, machine 
 run-time, machines used, and machine language used. Fig. 4 shows total 
 machine run-time for the two systems above plus a documents processing 
 system, and details of development times. In addition, there is a paragraph in 
 an accompanying letter about computer machine costs (fig. 5). 
 
 I find it appalling that this is all the information I was given. These 
 machine times are interesting, but one can tell nothing about total costs of 
 the operation from them. There is no list of what steps in any operation are 
 performed, and therefore we cannot tell what collateral steps are performed 
 manually to complete the system. There are no systems salary costs. There are 
 no costs of collecting and preparing data for the computer. We do not know 
 what happens after the computer prepares its reports. In fact, this is no more 
 than 10 percent of the information needed to judge whether the system is 
 cost effective. This is not a cost analysis by any means, yet one of librarian- 
 ship's outstanding computerators considers it convincing. 
 
148 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 ^1 CIRCULATION SYSTEM 
 
 Loads 
 Period 7-1-68 to 6-30-69 
 
 1. Transactions 80,000 
 
 2. Computer Hours (clock)* 125 
 
 IBM 360 E40 
 
 System 2-2415 (M2 15KB) 
 Hardware 1-1403 (600 Lines/minute) 
 
 1-2540 
 
 1-2311 
 
 3. Approximate processing time per transaction .1 minute 6 sec. 
 
 4. CPU Hours - about .4 clock hours (or less) for this system. 
 CPU Hours - 50 
 
 * Includes all support processing and special runs. 
 
 Fig. 2. Proof of Cost Effectiveness-Circulation System 
 
 ^BE - LIBRARY ACQUISITIONS INFORMATION SYSTEM 
 System Hardware Requirements 
 
 CPU System 360 with 32k bytes core. 
 
 Model 25 or larger. 
 
 TAPES Two drives. Any Model. 
 
 DISK Total 7.25 Million bytes maximum, 
 
 all work files. 
 
 PRINTER Any Model. 1403 best. 
 
 CARD READER Any Model. 2540 best. 
 
 System Software 
 99% Cobol "F", 17. 360 Assembler 
 
 System Loads (Computer Usage) 
 Period 7-1-68 to 6-30-69 
 
 1. Transactions (new titles) 40,000 
 
 2. Computer Hours (clock) 50.5 
 
 Using: IBM 360 E40 
 
 2-2415 M2 
 1-1403 (600 L/M) 
 1-2540 
 1-2311 
 
 3. Approximate processing time per title .075 minute 
 
 4. CPU Hours about .4 clock hours 
 
 Fig. 3. Proof of Cost Effectiveness- Acquisition System 
 
A UTOMA TION OR R USSIAN ROULETTE? 149 
 
 ANALYSIS OF COMPUTER USAGE BY LIBRARY SYSTEMS 
 AT ^i^B UNIVERSITY 
 
 Period Covered 7-1-68 thru 6-30-69 
 
 Hours used (clock) Production Testing Total 
 
 Library Circulation 
 
 111 
 
 10 
 
 121 
 
 Library Acquisitions 
 
 50.5 
 
 10 
 
 60.5 
 
 1 
 
 ^B Documents 
 
 20 
 
 9 
 
 29 
 
 210.5 
 
 
 ANALYSIS 
 
 mmi 
 
 OF DEVELOPMENT OF SYSTEMS FOR THE 
 UNIVERSITY LIBRARY 
 
 This analysis covers the 
 
 * 
 
 following three systems 
 ^fc in the library. 
 
 presently 
 
 in use at 
 
 1. Library Circulation 
 2. Acquisitions 
 3. flH^^B State Document Processing 
 
 System No. 
 
 1 
 
 2 
 
 3 
 
 A. 
 
 Starting Development 
 
 Date 1-1967 
 
 1-1968 
 
 1-1969 
 
 B. 
 
 Number of Man Hours 
 Development 
 
 in 
 720 
 
 500 
 
 400 
 
 C. 
 
 Number of Programs 
 
 17 
 
 25 
 
 15 
 
 D. 
 
 Implementation Date 
 
 9-1967 
 
 7-1968 
 
 6-1969 
 
 E. 
 
 Support Hours /Month 
 
 10 
 
 30 
 
 30 
 
 F. Total Hours Devoted 
 
 (Development and Support) 
 
 Since Development Date 1360 1400 700 
 
 Fig. 4. Proof of Cost Effectiveness Machine Run-Time 
 
150 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 Several points need to be noted in interpreting the above data. 
 
 (1) The hourly rate charged for the system hardware ^Mt 
 at the time was $80.00 for a commercial user and $40.00 for an internal 
 department. The equipment was as follows: 
 
 IBM 360-E40 
 
 two 2415 (M2 15 KB tape drives) 
 
 one 1403 Printer (600 lines a minute) 
 
 one 2540 Card Reader 
 
 one 2311 
 
 At the institutional rate of $40.00 an hour, our computer charges for the 
 year's operation (210.5 clock hours) was $8420, or $16,820 if you use 
 the commerical rate. To this has to be added $3084 per year for the IBM 
 357 data gathering device for the circulation system and $2016 per year 
 for three IBM 026 key punch machines which supported all three systems, 
 
 Fig. 5. Description of Machine Costs 
 
 The next figure (fig. 6) is an analysis of the costs of a midwestern 
 computerized circulation system. This is a detailed summary of costs by their 
 larger components, which constrasts unit costs of the manual system in the 
 first column with unit costs of the computerized system which replaced it. 
 Note that three disastrous years followed the manual system's removal because 
 of faulty programming. If we assume an annual increase of 5 percent in the 
 manual cost, which is more than it would have been during the three years 
 1967/68 through 1969/70, the computerized system cost the library $115,000 
 more than the manual system would have cost. This should have cost someone 
 his head. 
 
 In 1970/71 they reprogrammed and cut unit costs, and the economies 
 seem to be increasing in 1971/72 to a unit cost of $0.38 compared to a 
 manual cost of $0.37 five years previously, which surely would have been 
 more than $0.38 by now. This seems to be worthwhile until compared with a 
 manual system (fig. 7). Fig. 6 showed costs for charge-out, discharge, and 
 related functions. Fig. 7 shows the total cost of circulation in another library 
 from charge-out to shelf return, including all costs of stack maintenance, and 
 certain other activities centered in the circulation department. The total cost 
 is nearly $0.10 below the previous out-and-in circulation costs, which in the 
 system represented in fig. 7 are probably less than $0.15. This is not a very 
 efficient manual system; it is my own, and we are revising all aspects of it this 
 year. What does the computerized circulation system provide that the manual 
 system does not? Nothing for which there is a demonstrable need. 
 
AUTOMATION, OR RUSSIAN ROULETTE? 
 
 151 
 
 
 5 
 
 
 
 
 
 
 n 
 
 
 
 
 
 
 
 g 
 
 
 
 
 
 
 
 
 
 
 S 
 
 > 
 
 
 
 
 
 
 
 
 
 
 
 
 ;i 
 
 
 
 
 
 
 
 
 
 
 
 i 
 
 9 
 
 
 
 i 
 
 i 
 
 . 
 
 i 
 
 1 
 
 
 
 
 
 
 
 4 
 
 ft 
 
 
 
 S 
 
 rj 
 
 8 
 
 In 
 
 P 
 
 ? 
 
 S 
 
 
 
 in 
 
 S 
 
 g 
 
 g 
 
 S 
 
 vD 
 
 8 
 
 s 
 
 
 
 
 
 
 
 S 
 
 
 
 
 
 
 
 
 
 
 I 
 
 3 
 
 rH 
 
 -" 
 
 * 
 
 rg 
 
 * 
 
 
 
 
 
 
 
 g 
 
 
 
 
 
 
 
 
 
 
 s 
 
 S 
 
 r^ 
 
 i 
 
 5 
 
 Ot 
 
 s 
 
 s 
 
 Os 
 
 s 
 
 1 
 
 D 
 
 VO 
 
 i 
 
 1 
 
 0- 
 
 5 
 
 8 
 
 1 
 
 
 
 
 
 
 
 
 
 1-4 
 
 1 
 
 -3 
 S 
 
 
 
 
 
 1 
 
 
 
 1 
 
 
 
 1 
 
 3 
 
 
 
 ' 
 
 i 
 
 v> 
 
 
 8 
 
 3 
 
 s 
 
 
 
 1 
 
 
 
 | 
 
 " 
 
 
 
 5 
 
 g 
 
 u- 
 
 En 
 
 B 
 
 p 
 
 1 
 
 1 
 
 
 
 rH 
 
 r- 
 
 u\ 
 
 
 
 
 
 
 
 
 
 
 
 | 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 a 
 
 
 
 
 
 
 
 
 C 
 
 
 i 
 
 s 
 
 
 
 49 
 
 g 
 
 s 
 
 H 
 
 5 
 
 
 
 g 
 
 i? 
 
 S 
 
 a- 
 
 H 
 
 
 
 1 
 
 
 
 
 
 o 
 v> 
 
 J2 
 
 
 
 O 
 
 a 
 
 i 
 
 1 
 
 i 
 
 1 
 
 rH 
 
 
 
 
 
 
 
 H 
 
 1 
 
 ' 
 
 1 
 
 K 
 
 i 
 
 
 
 
 
 
 
 
 
 i 
 
 S 
 
 s 
 
 \^ 
 
 .S 
 T3 
 
 H 
 
 Vf. 
 
 O 
 
 q 
 & 
 
 i 
 
 ITS 
 
 S 
 
 2 
 
 s 
 
 r- 
 
 2 
 
 CO 
 
 tr- 
 
 
 
 p 
 
 
 
 M 
 
 3 
 
 
 
 
 
 
 
 
 9 
 
 C 
 
 <u 
 
 
 
 
 S 
 
 
 
 
 
 
 
 
 
 
 
 
 a 
 
 
 
 
 
 
 
 
 *- 
 
 
 t: 
 
 I 
 
 s 
 
 Se 
 
 g 
 
 g 
 
 s 
 
 s 
 
 g 
 
 io 
 
 g 
 
 g 
 
 g 
 
 a 
 
 
 
 1 
 
 
 
 
 
 o. 
 
 g 
 
 s 
 
 Os 
 
 t. 
 
 
 
 1 
 
 2 
 
 S 
 
 H 
 
 s 
 
 s 
 
 1 
 
 r-\ 
 
 1 
 
 - 
 
 K 
 
 1 
 
 r-l 
 
 to 
 
 S 
 
 r-T 
 
 I 
 
 8 
 R" 
 
 
 
 0? 
 
 c^ 
 
 I 
 
 -3 
 
 u\ 
 
 
 
 (M 
 
 O 
 
 CO 
 
 
 
 
 C- 
 
 5 
 
 S 
 
 | 
 
 S 
 
 cr> 
 
 3 
 
 
 
 s 
 
 B 
 
 
 
 r-l 
 
 
 
 B 
 
 S 
 
 s 
 
 g 
 
 
 
 
 
 
 
 
 en 
 _>, 
 13 
 
 
 s 
 
 B 
 
 a 
 
 R 
 
 8 
 
 s 
 
 R 
 
 s 
 
 
 
 S, 
 
 S 
 
 : 
 
 a 
 
 
 
 
 
 h 
 
 
 
 
 
 < 
 
 o 
 
 
 B 
 
 
 
 
 
 
 
 
 
 
 
 
 
 s 
 
 
 
 a 
 
 
 
 
 
 u 
 
 . 
 
 
 gj 
 
 
 
 
 Si 
 
 
 g 
 
 
 -' 
 
 r 
 
 g 
 
 p 
 
 S 
 
 
 
 g 
 
 8 
 
 
 
 s 
 
 CM 
 
 * 
 
 ^6 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 8 
 
 s 
 
 ev 
 
 f : 
 
 rt 
 
 
 S 
 
 K 
 
 
 5 
 
 in 
 
 -! 
 
 S 
 
 5 
 
 2 
 
 ' 
 
 s 
 
 s 
 
 s 
 
 s 
 
 !H 
 
 r 
 
 i 
 
 g 
 
 EC 
 
 
 
 
 
 
 
 
 
 
 
 
 rx 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 I 
 
 ' 
 
 i 
 
 
 
 i 
 
 1 
 
 1 
 
 1 
 
 i 
 
 i 
 
 
 
 
 
 1 
 
 i 
 
 
 
 
 
 
 
 
 
 T 1 
 
 \ 
 
 '. 
 
 i 
 
 
 
 i 
 
 i 
 
 
 
 ' 
 
 ' 
 
 
 
 ' 
 
 i 
 
 ' 
 
 1 
 
 i 
 
 1 
 
 8 
 
 g 
 
 : 
 
 8 
 
 8 
 
 8 
 
 g 
 
 
 
 
 i 
 
 H 
 
 u- 
 
 p 
 . 
 
 : ' 
 
 ' 
 
 
 
 
 
 i 
 
 1 
 
 1 
 
 1 
 
 
 
 1 
 
 i 
 
 
 
 1 
 
 i 
 
 
 
 r 
 
 a 
 
 : 
 
 H 
 
 j 
 
 
 
 r-l 
 
 
 C It, 
 
 C 
 } 
 
 
 
 *-> 
 i 
 
 r 
 
 3 
 | 
 
 CX tober 
 
 i 
 
 K 
 
 i 
 
 6 
 
 
 " 
 
 February 
 
 1 
 
 ^ 
 
 | 
 
 B 
 
 r 
 
 . 
 
 a 
 
 3 
 
 ! 
 
 I 
 
 t. 
 
 < t 
 
 r . f 
 
 Student 
 
 Total 
 
 3] 
 
 i 
 
 .' C 
 
 ? ?. 
 
 r\ 
 
 
752 1 9 72 CLINIC ON A PPLICA TIONS OF DA TA PR OC ESS ING 
 Circulation Costs - 1970/71, Main Desk 
 
 Salaries Staff $Vr,350 
 
 Students 18,257 
 
 Student assistants & tempo 
 
 Total Salaries $68,038 
 
 Sysdac rental 360 
 
 Supplies (tape, ribbons, etc.) _25 
 
 Total costs 69.3^8 
 
 Total Main Desk Circulations 198,902 
 
 Cost Per Circulation 28.6^ each 
 
 This cost includes the following procedures; 
 Circulation 
 
 Charging 
 
 Discharging 
 
 Placing "holds" and notification 
 
 Recalling overdue s 
 
 Billing fines and lost books 
 
 Collecting fines 
 
 Stack Maintenance 
 
 Re shelving circulating books 
 Re shelving stack-used books 
 Exhibiting new books 
 Shelving new books 
 Reading shelves for accuracy 
 Maintaining faculty studies 
 Maintaining book lockers 
 
 Searching 
 
 Searching misplaced books 
 Miscellaneous 
 
 Holding duplicate book sales 
 
 Forwarding orders for lost books 
 
 Forwarding books for repair and binding 
 
 Making change for photocopy machines 
 
 Servicing paper in photocopy machines (nights & weekends) 
 
 Fig. 7. Cost Analysis of a Manual Circulation System 
 
A UTOMA TION, OR R USSIAN ROULETTE? 153 
 
 From the report of a computerized library operation in Australia which in 
 1971 had 60,000 volumes in its collection, ten doctoral programs, and was 
 1,500 miles from the nearest substantial library comes this quote: 
 
 COSTS 
 
 Computer time is free, so the main cost is salaries (approximately $11,000 
 Aust.) which is absorbed into the total library budget. [They say "absorbed 
 into the total library budget" as though some magic made the cost disappear.] 
 In addition there is a budget component to cover equipment and stationery 
 costs. In 1971 this was $2,000, most of which was spent on 1 disk pack ($600) 
 and DEC Tapes ($600). 18 
 
 This is the only account of costs of the following current operations: an 
 on-line listing of reserve books, a batch acquisitions system, a batch subject 
 catalog of the collection, an on-line circulation system, and a browsing 
 collection index. How casual can a library afford to be about computer costs 
 in a university library that is running ten Ph.D programs on a junior college 
 collection? 
 
 The one good cost analysis that has come in the various replies to my 
 article was from Robert L. Taylor, library systems analyst at the University of 
 Wisconsin at Green Bay, who wrote saying that he agreed with much of what 
 I said, but had a COM catalog production system of great interest. I wrote 
 back asking for cost analyses and got, in two sequential letters the best cost 
 analysis I have seen. Most of the costs are not for computer production, 
 unless you consider the MT/ST a computerized machine. 
 
 The first sheet of information (fig. 8) begins where one must begin, with 
 a list of all of the steps in the process of the system. Total costs for 
 cataloging, from acquisitions to shelf, are $2.35. I was particularly interested 
 in his costs on steps nine to thirteen, card production by MT/ST, and again he 
 sent me an impeccable cost account (fig. 9). Figs. 8 and 9 contain all the 
 components of a cost analysis that are required to compare one system with 
 another, taking into account differences in staff salaries: (1) a complete list of 
 the detailed steps performed; (2) unit costs of each step, over a considerable 
 span of time, backed by statistics of production, and average salaries per hour; 
 (3) a description of all machinery used; and (4) a report of all applicable 
 costs everything that is required to produce the end product. If we would 
 begin to publish cost analyses in these terms, and with this degree of precision, 
 within a year we would be able to make the best processes visible. 
 
 This paper is in a sense my third generation attack on the central problem 
 the computer has presented for libraries, that is, whether the machine is going 
 to do libraries any good. The question has been twisted beyond any recog- 
 nition by an army of pitchmen, public relations grimmickers, self-servers, and 
 
154 
 
 1972 CLINIC ON APPLICATIONS OF DATA PROCESSING 
 
 The processing steps are: 
 
 1. Title from acquisitions searched for MF copy. 
 
 2. -copy printed - copy placed in book on book, truck (100 
 
 books on a truck) . 
 
 3. -typist removes copy and alphabetizes it. 
 
 1*. -copy is searched in authority and catalog files. 
 
 5. -copy in pack and truck of books go to cataloger. 
 
 6. -book is cataloged. 
 
 7. -call no. put in book. 
 
 -book goes to labeling then shelf. 
 
 -catalog copy goes to MT/ST operator. 
 
 -MT/ST edit copy is produced 128-32 titles per cartridge). 
 
 -edit copy checked for errors . 
 
 -edit used in playback to correct tape . 
 
 -cards are played out and tape is corrected at the same time. 
 
 -corrected tape is sent for conversion to computer tape 
 (about *1.50/cartridge) 
 
 -cards are separated for filing. 
 
 -computer tape is cleaned and compacted and formated on a 
 360/UO system. 
 
 -records will be sorted by LC call no. 
 
 -data base will be indexed and run through a computer Output 
 Microfilm unit (COM) to produce an MF catalog of our collec- 
 tion. (We also hope to do this on an interlibrary basis). 
 
 Fig. 8. Processing Steps 
 
 Input (Items 9, 10 ) 
 
 Typist (2.71/hr. average) 
 MTST (280/mon. average) 
 Proof cards (2) 
 
 Input subtotal 
 
 Edit (Item 11 ) 
 
 Typist (2.69/hr. average) 
 
 Input and edit subtotal 
 
 Output (Items 12, 13, 15) 
 
 Typist ( 2. 25/hr. -operates 2 machines at once) 
 
 MTST 
 
 Cards (7.2/set average) 
 
 Output subtotal 
 
 Input and output and edit total 
 
 13.100 cents/title 
 
 6.500 cents/title 
 
 .Oil* cents/title 
 
 5.000 cents/title 
 2l*.6ll* cents/title 
 
 7.893 cents/title 
 6.500 cents/title 
 0.050 cents/title 
 
 ll*. 1*1*3 
 
 39.057 cents/title 
 
 All figures are based on monthly average title production of 3,020 
 (for first 9 months of 1971). 
 
 Fig. 9. Cost per Title 
 
A UTOMA TION, OR R USSIAN ROULETTE? 155 
 
 self -deceivers both outside and inside the library profession. Many library 
 experts recognize this army and are highly critical of its members when I talk 
 with them personally. But public repudiation is never made even though many 
 librarians know they are doing irreparable damage to any sensible con- 
 sideration of the place of computers in the spectrum of library services. 
 
 Michael Barnett, director of research and development at the H. W. Wilson 
 Company, wrote a very good letter in reply to my article, 1 which indicated, 
 among other things, that he had seen far greater horrors in computerization 
 than any I had witnessed: "I have been appalled by the intellectual corruption 
 and the waste of funds that I have seen in ill-conceived and dismally mis- 
 managed automation projects in a variety of fields; and by the drivel that has 
 been promulgated as so-called computer science." 19 And, later: 
 
 It is possible for a crew of systems programmers to keep an installation in 
 a state of constant upheaval quite unnecessarily, and in particular without the 
 slightest change of hardware or software by the manufacturer. I have seen 
 computer center staffs force users out of compatibility with other installations 
 in matters that are completely standard for reasons that seem to range from 
 downright incompetence, to an arrogant desire to exert control over other 
 people's work, to regarding the computer as a toy for their personal amuse- 
 ment and a vehicle for practical jokes that verge on the malicious. 1 9 
 
 Yet when I wrote him asking why you experts did not cleanse your own 
 Augean Stables, he did not reply. 
 
 Until the computer is placed in the same condition as every other 
 component in a library of being considered useless unless it can be proved 
 otherwise until we can look at operational cost analyses with confidence in 
 their validity, until we can see precisely what can be obtained at what costs, 
 we are not going to get very far with the use of computers in library 
 operations. 
 
 REFERENCES 
 
 1. Mason, Ellsworth. "The Great Gas Bubble Prick't; or, Computers Re- 
 vealed-by a Gentleman of Quality," College & Research Libraries, 32:183-96, 
 May 1971. Reprinted in Liberal Education, 57:394-412, Oct. 1971. Reprinted in 
 Katz, William, ed. Library Literature 2-The Best of 1972. Metuchen, N.J., 
 Scarecrow Press. 1972, pp. 90-1 11. 
 
 2. Melcher, Daniel. "Cataloging, Processing and Automation," American 
 Libraries, 2:701-13, July 1971. 
 
 3. Are Computer-Oriented Librarians Really Incompetent! Excerpts from 
 the Proceedings of a LARC Meeting held during the ALA Conference in 
 Dallas, Texas, June 24, 1971. N.p., Library Automation Research and Con- 
 sulting, n.d. 
 
156 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 4. Ibid., p. 1. 
 
 5. "All the News That's Fit to Print Out," New York Magazine, 5:45-47, 
 Jan. 17, 1972. 
 
 6. "On Line, Real Time Circulation; A Report on the Northwestern 
 University Library System," The LARC Reports, Vol. 3, Issue 4, Winter 
 1970-71. 
 
 7. Mason, Ellsworth, and Avram, Henriette D. "Perspectives on Libraries 
 and Computers: A Debate," Library Resources and Technical Services, 
 16:5-18, Winter 1972. 
 
 8. Jackson, Sidney L., Kent State University School of Library Science. 
 Unpublished letter to the editor of Library Resources and Technical Services 
 dated March 21, 1972. 
 
 9. Kilgour, Frederick. "Evolving, Computerizing, Personalizing," 
 American Libraries, 3:141-47, Feb. 1972. 
 
 10. "Productivity and the Economy." U.S. Department of Labor, Bureau 
 of Labor Statistics Bulletin 1710. Washington, D.C., U.S.G.P.O., 1971, p. 9. 
 
 11. Boulding, Kenneth: quoted in the Dayton Herald, Jan. 13, 1972, p. 
 9. 
 
 12. Golub, Harvey. "A Quarter Century View of Computers Lessons for 
 Management, The Last Twenty-Five Years." Unpublished paper presented at 
 the ACM 71 Annual Conference, August 4, 1971, Chicago, Illinois, p. 1. 
 
 13. Ibid., p. 7. 
 
 14. Ibid., pp. 5-6. 
 
 15. Alexander, Tom. "Computers Can't Solve Everything," Fortune, 
 80:126, Oct. 1969; and Smith, Dan. "The Accident-Prone Miracle," The 
 Economist, 238:viii-xxxvii, Feb. 27, 1971. 
 
 16. Smith, Dan, ibid., p. xi. 
 
 17. Undated letter received March 10, 1972. I think the writer might not 
 like to be identified in this context. 
 
 18. "Report of the Library's Data Processing Activities," Nov. 19, 1971. 
 Unpublished report; I think that the library might not like to be identified in 
 this context. 
 
 19. Barnett, Michael P., in a letter to the editor, College & Research 
 Libraries, 32:390-92, Sept. 1971. 
 
GLYN T. EVANS 
 
 Coordinator of Library Systems 
 
 Five Associated University Libraries 
 
 Syracuse, New York 
 
 Summary of the Clinic 
 
 In this paper I want to indicate the significant elements in the papers and 
 demonstrations given at this clinic and then speculate on some of their 
 implications. The first significant fact is that there have been reports and 
 demonstrations. Examples of successful applications of on-line technology to a 
 variety of jobs which cut across the board of library operations-from 
 acquisitions, cataloging and serials control, through two circulation systems, to 
 the retrieval of biomedical information have been heard and seen. 
 
 Further, each of the contributing groups were able to claim that on-line 
 input and processing produced cost savings or cost benefits over batch 
 processing. Everyone was, in general, happy with their systems. 
 
 One or two unresolved, perhaps unattacked, technical problems, did 
 surface during the discussion. One was system size, or perhaps more precisely, 
 file size. Fayollat was asked about expansion of his serials system from 7,000 
 to 70,000 current titles, and answered that he expected file arrangement and 
 file access to be the critical problem with such an expansion. (Actually, it 
 seems that check-in would be the big bugaboo.) Epstein, in answer to a 
 question in the same vein, said that he would depend on Warheit; that is, he 
 would expect technology to provide the answer. This reply caused some 
 amusement, but Epstein may not be far wrong in his attitude. Certainly thus 
 far history has been on his side. At the 1972 Educom Spring Conference, an 
 account was given of the progress of the development of the first trillion-bit 
 laser memory and the peripheral equipment which must surround it, which is 
 expected to be delivered to the ARPA network shortly. However, how long 
 technology can stay ahead in the game of logical optimum file construction is 
 an open question. 
 
 Other technical problems mentioned were transferability, file security, 
 downtime and back-up systems, all of which I will refer to later. 
 
158 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 The first, exciting lesson of this clinic is that on-line library automation is 
 now technically feasible. Another aspect of the clinic was provided by its last 
 speaker. 
 
 I have been intrigued by an interesting rivalry in innovation among 
 conference organizers, a phenomenon which has manifested itself in strange 
 ways in recent years. It started, to the best of my knowledge, with the 
 Medical Library Association in New Orleans in 1969, with the superb Olympia 
 Jazz and Marching Band, smuggled in under the guise of a lecture entitled 
 "New Orleans Funeral Music- A Dying Art!" The 1970 ASIS Conference at 
 Philadelphia countered with Middle Eastern music, and quite the most 
 beautiful belly dancer I have ever seen for which I am forever in their debt. 
 This clinic, with studied calm, gives us Ellsworth Mason. 
 
 Mason is a brilliant performer. His enviable command of language, his 
 elegant turns of phrase, the dismissive wave of the hand, his unremitting 
 rhetoric, bedazzle and bemuse us to our and his loss. For his supporters are 
 hypnotized by the silken glitter of his top hat as he soft shoes his cane- 
 twirling, spats-twinkling, white-spotlit way across the stage. And his 
 opponents, infuriated and goaded, attack the shadow of his cape and not the 
 substance of his argument. 
 
 The result of this kind of encounter is a trivial event. Supporters, roaring 
 from the gallery, applaud, unfeelingly and insensitively, at the wrong 
 moments; while the opponents are always one step behind the nimble hoofer. 
 Mason's performance at this clinic was no different, and the attempts at 
 rebuttal, with one or two honorable exceptions, fell into the well-laid trap. 
 And the undeniable brilliance of the spectacle obscures the game, more's the 
 pity, for there are real issues at stake. 
 
 Mason rather gives the game away in the second sentence of his paper 
 when he says that computerators "do not dare to think about the basic 
 problem which it [the computer] poses to librarianship." There is no evidence 
 that the computer threatens bibliographic procedures or records, indexes or 
 abstracts, reference services, accounting systems, book publishing and the 
 thousand other areas in which it affects the daily activities of librarianship. 
 Indeed, many of our tools could not exist without the computer. 
 
 The computer does, however, pose problems to the library administrator 
 who, already burdened with uncertain budgets, staff problems, inadequate 
 buildings and an almost total lack of real planning, is reluctant or unable to 
 introduce one more variable into an already impossible situation. Of course 
 someone was going to lash out in sheer frustration. At least it is merciful that 
 the inaccuracies and woeful misconceptions, exaggerated though they be, were 
 presented by Ellsworth Mason with eloquence. The tragic irony is that at 
 precisely the moment when the breakthrough is being made, misguided attack 
 could damage hard won achievements and jeopardize, not further develop- 
 ment, but massive implementation and exploitation. 
 
SUMMARY 159 
 
 Having said some things which may be disagreeable to Mason, I will now 
 attempt to please him by saying that two parts of his message are absolutely 
 right. These are that new systems have to be cost beneficial, and that group 
 development will probably produce the highest yield from investment. 
 
 Cost Benefit 
 
 The new on-line systems must be cost beneficial to the libraries which use 
 them. The central issue facing libraries today is survival. Libraries must move 
 from being a labor-intensive, capital-intensive economic system. For a forceful 
 presentation of this proposition see the papers of the National Commission on 
 Libraries in Libraries at Large and Kilgour's article in American Libraries. 1 
 
 Four outcomes to the installation of a new system should be considered: 
 (1) a clear financial gain, new vs. old, (2) cost break even, new vs. old, (3) 
 greater expense justified by improved service, and (4) greater expense not 
 justified by improved service. Of the four, the last is clearly unacceptable. An 
 even cost break, (2), is a neutral situation where a decision is governed by 
 personal predilection. 
 
 The clear financial gain noted in (1) will presumably override other 
 considerations. (I assume here that the standard of service remains even, if it 
 is not an actual improvement.) Fayollat, for instance, was able to report a 
 clear dollar saving for the UCLA Biomedical Library. 
 
 The difficult case is (3), where a greater expense has to be justified by 
 improved service. Both Ohio State University (OSU) and Northwestern 
 University's circulation systems reported dramatic increases in the number of 
 transactions 31 percent at Northwestern; and OSU reported that its costs are 
 now even with what they were before it installed the system; nonetheless its 
 circulation has increased over 40 percent. Much of this increased service 
 occurred before recent budget changes increased costs to their present even 
 point. 
 
 Cost benefit analysis in libraries is almost nonexistent. Libraries have 
 lagged behind management and industry in developing methods for assigning 
 value to the benefits of improved service. I was told the other day of a cost 
 benefit study which concerned the search for a power station site. One of the 
 sites under consideration would have affected an existing ski slope and resort 
 area. The cost benefit analysis attempted to account for any interference with 
 the skiing by measuring such factors as the amount of play time spent on the 
 slope by skiers, the investment in equipment by skiers, the investment in 
 equipment by ski slope developers, and the value to the community of the 
 availability of the skiing facility. The outcome of that cost benefit analysis is 
 not important for this discussion. What is important is the fact that the 
 planning authority was prepared for, and felt that it had the tools to perform, 
 such an analysis. 
 
160 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 All of the systems reported at this clinic claim some extra benefit, such as 
 improved control, better management information, and so on. The most 
 unexpected claim was Miller and Hodges' report that an overwhelming benefit 
 was the development of a team planning attitude in the total organization. 
 Clearly, this last is an enormous benefit, and it should be possible to place a 
 dollar value on the benefit as decisionmaking within the organization 
 improves. 
 
 In general, however, we in libraries do not know how to measure the cost 
 benefit of improved service. I submit that we have to develop some under- 
 standing of the problem as we encounter increased competition for dwindling 
 resources. We should be able to face management with confidence in our own 
 calculations when we seek funds. When Atkinson was asked if his budget and 
 credibility had increased as a result of the system, he answered, "credibility, 
 yes; budget, no." He surely is heading in the right direction though. 
 
 Modes of Implementation 
 
 There are a number of ways in which libraries can acquire the benefits of 
 on-line service. They can develop it themselves; they can participate in joint 
 development; they can link into an existing development which is capable of 
 and prepared to accept expansion; or finally, they may be able to exploit 
 existing facilities to their particular advantage. 
 
 Let us take the last case first. There is a small library situated on a large 
 research reservation which found available an elegant package of text pro- 
 cessing and retrieval programs maintained for the on-line access of its own 
 research community by a central computing facility. By utilizing this package 
 the library was, within a few days and at no capital cost to itself, able to 
 develop a library system in which current acquisitions from all sources were 
 entered onto the file via terminals, and a variety of outputs were produced, 
 including catalog cards, announcement lists and KWIC indexes. The system has 
 the capability of expanding into an abstracting service, with Boolean text 
 search facility, whenever the library feels that it is able to take advantage of 
 these modules. The cost to the library is maintenance cost only. It is clear 
 that, as on-line networks develop, more libraries can exploit such situations // 
 they are alert to the possibilities which present themselves. 
 
 One approach is to develop the system for one's own library. There have 
 been accounts of different attacks on this problem during this clinic. Miller 
 and Hodges discussed their adoption of the IBM package FASTER; Auld and 
 Baker reported on a computer system which developed its own operating 
 system. Atkinson contracted IBM to do the job. I do want to draw attention 
 to a statement by Auld in which he warned that locally developed software is 
 a major undertaking, particularly if it means playing with operating systems. 
 As the number of networks increases and our understanding of networks 
 improves, the unique library-developed on-line system will become the rarest 
 example of on-line development. 
 
SUMMARY 161 
 
 The next case to be considered is that of the library or consortium which 
 links into an on-line system which is capable of expansion. Pizer presented a 
 map of the Biomedical Communication Network (BCN) and told about the 
 growth of the National Library of Medicine's Medline system. 
 
 The Five Associated University Libraries (PAUL) and the New England 
 Library Information Network (NELINET) are two consortia which have been 
 fortunate in being able to pursue this course of action. Both PAUL and 
 NELINET are presently negotiating agreements under which they will link 
 into the Ohio College Library Center (OCLC) system by the direct terminal 
 hookup of their member libraries. This is seen to be an interim step prior to 
 planning the eventual replication of the OCLC system in their respective 
 regions and the direct linkage of three major computers. The advantages of 
 this kind of arrangement are obvious. In the short term, the incoming consortia 
 will avoid the heavy development cost of building the system themselves, and 
 yet their usage of the system will significantly reduce costs for the original 
 members. The long-term advantage is even more important. 
 
 I believe we are witnessing the birth of a national on-line bibliographic 
 network, particularly since it seems possible that the system may expand 
 beyond OCLC, PAUL or NELINET. The prospect of, for example, Ohio 
 State University, Yale, Cornell, University of Pennsylvania, and Dartmouth 
 sharing and contributing to the same MARC data base is exciting, to say the 
 least. A similar growth situation is taking place at Stanford as Epstein and 
 Veaner related. 
 
 The characteristic which underlies the expansion of these systems is that 
 it is possible to demonstrate the potential for clear cost savings. Both PAUL 
 and NELINET performed internal feasibility studies before making their 
 decision to seek formal relationship with OCLC. The published cost studies on 
 the expansion of the Stanford BALLOTS system network performed by 
 Eleanor Montague are a model of their kind. 2 
 
 Finally, in modes of implementation, we have to look at the joint 
 development of on-line systems. Probably the most successful example of joint 
 support for such a development is the OCLC system. The Ohio College 
 Library Center has been running its on-line shared catalog service, including 
 the submission of original records in MARC II format by member libraries to 
 the central data base for the common good, for a year. The sharing of costs 
 and expertise in a successful system development project is clearly very 
 attractive to the participants in such a venture. 
 
 Consortia 
 
 The present economic situation points to the joint development of such 
 systems. Library consortia can provide both the necessary financial base and 
 an adequate resource of expertise, but the development of a consortium is not 
 
762 7972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 an easy undertaking. The human problems which can be encountered must 
 not be underestimated. The consortium must have a clear mission, and objec- 
 tives which are understood and accepted by all. Program priorities must be 
 assigned which will certainly not suit every participant. The consortium 
 members need to have patience and courage; results cannot be expected 
 overnight, while uninformed criticism comes easy. The difficulties must be 
 assessed realistically and adequate funds provided. 
 
 We have to face the fact that no one library is strong enough to do this 
 alone and we must be prepared to work cooperatively. Institutional pride is 
 vital to any organization, but common sense must prevail and a reluctance to 
 seek and exploit any opportunities to better serve one's institution is a 
 disservice to it. Enlightened institutional awareness is better than misplaced 
 institutional loyalty. 
 
 Standardization 
 
 Pizer devoted a section of his paper to standardization a concern which 
 immediately emerges when considering cooperative on-line library technology. 
 Standards apply in a variety of forms -standard data, standard formats, 
 standard outputs, and standards of service and are essential if systems are to 
 be transferred or replicated. 
 
 A standard format is an absolute necessity for the interchange of data. 
 Libraries are indebted to the Library of Congress for the MARC formats and 
 the distribution of data in that format. Standard data is harder for librarians 
 to accept, wedded as they are to old practices and traditions. I am impressed 
 that OCLC, when faced with either forcing total acceptance of data or 
 facilitating easy modification of data through an on-line system by its 
 members, chose the latter course. Some essential changes do have to be made 
 to records before they may be accepted locally. As Kilgour states, "Uni- 
 formity [is] a requirement by which libraries have never been able to 
 abide. . . . Uniformity and standardization are not synonymous." 3 
 
 At the same time we have to recognize that making such changes costs 
 money. Careful thought should be given to the question of which elements in a 
 record should be changed, and what will be the real effect of such changes on 
 the library operation. For example, a recent internal study performed at the 
 University of Rochester examined the effect of total acceptance of LC class 
 numbers on shelving. 4 It was found that 61 percent of books would be 
 shelved in the same place, 13.5 percent would be between one and three 
 places off and 20 percent more than three places off. A subsequent smaller 
 study on the final 20 percent showed that (in class N) 70 percent would be 
 within twenty places, or on the same shelf. In other words, (with the 
 exception of classes P and Z) acceptance of an external data source might not 
 be as damaging on reflection as it seems at first. 
 
SUMMARY 163 
 
 This brings us to internal standards of service vis-a-vis on-line cooperative 
 systems. David Kaser stated the problem clearly when he wrote "Some 
 [libraries] would in certain operations have to raise their individual standards 
 to those adopted by the group, and that costs money. In other operations 
 some would have to settle for lower standards, and that is expensive in its 
 impact upon institutional pride, dignity, and morale." 5 Librarians will have to 
 face a complete reexamination of their standards for both records and 
 services. The new technology presents this opportunity since things undreamed 
 of by our predecessors can now be done as we realize that many articles of 
 professional faith are really statements of temporal expediency. 
 
 Finance 
 
 I remarked earlier that we are entering a phase of massive implementation. 
 The difference between possible and feasible is precisely the difference 
 between an intriguing research task and a successful, attractively priced 
 system. A number of the systems reported on at this clinic clearly fall into 
 the latter group, but their consolidation and expansion demand a high level of 
 capitalization. 
 
 What are funds needed for? We will need to run the systems for some 
 time, perhaps two or three years, before we can claim anything like maximum 
 savings, or before they break into a cost -benefit mode. Meanwhile, terminals 
 have to be bought, computers and telephone lines leased, operating staff hired 
 and changes made in existing procedures, all of which costs money. Federal 
 agencies, state and local governments, grant foundations, and parent insti- 
 tutions should be prepared to support this revolution in technique. 
 
 Librarians as managers of their systems should have as much confidence in 
 their requests for capital and their ability to deliver on investment funds as 
 they as individuals have when they approach a bank manager for a mortgage. 
 Of course this may present difficult problems in the internal accounting 
 structure of many organizations but such a condition should not act as a 
 deterrent to change. Requests also presuppose efficient cost-benefit analysis. 
 
 There is one other significant area in which federal funding in particular 
 should play a major role, and that is in the development of major data bases. 
 For instance, it is, to put it mildly, a disappointment that there is still no 
 major machine-readable data base of standard serials catalog data, particularly 
 since the absence of such a resource will clearly retard the development of 
 on-line serials control systems. Such data bases should be created as ex- 
 peditiously as is possible. 
 
 While discussing finance I want to refer to one of the recurring questions 
 which appeared all through the clinic -the problem of downtime and back-up 
 systems. It is important that we realize that these problems are, in general, of 
 financial rather than technical origin. We just cannot afford to run a second 
 
164 1972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 complete computer and communication system as back-up to the first so that 
 it automatically kicks in when something goes wrong. To use a simple 
 analogy, it would be like towing around a second car in case the first breaks 
 down. Only space flight can afford that kind of technical duplication and 
 perhaps only space flight needs it. Rather, we have to do the best we can to 
 prevent failure by good system design, and to minimize the effects of failure 
 when it does occur by protecting files and data. 
 
 People 
 
 Before we get started with the available technology, the human aspect of the 
 task must be considered. First, as librarians try to convince administrations 
 both inside and outside libraries that they deserve financial support, they also 
 must convince their professional colleagues. Libraries are facing problems. One 
 reasonable solution to some of the problems is on-line computer technology. 
 Librarians are reasonable people and are prepared to accept reasonable 
 solutions. (I use the word reasonable to mean based on "reason" or "sound 
 thought and judgment," rather than merely tolerable or acceptable.) They 
 have a responsibility to present the answers in such a way that they can be 
 understood by the profession. They should not shrug this off as an unworthy 
 exercise, since the failure fully to understand the new technology will surely 
 wreck our efforts. If clarity of thought and felicity of expression can prevent 
 sabotage of systems, librarians should seek them. 
 
 Second, librarians have to recognize that cost savings will come largely 
 from the personnel budget, which presents a human problem. After 150 years 
 of industrial revolution librarians should know enough to be able to solve the 
 problems of staff retraining and reallocation with humanity and patience. 
 Decisions on how to achieve the essential savings will be necessary, and I hope 
 that normal attrition is a strong enough tool. I do not believe that librarians 
 are Luddites who will destroy machinery. Librarians must consciously decide 
 that the necessary changes will be implemented with compassion; on the other 
 hand, as a profession we cannot respond with blind, unreasonable opposition 
 to measures which will save libraries. 
 
 There is a logical alternative to clumsy staff reduction, and that is not less 
 but more librarianship. For example, the present bibliographic description is at 
 best a poor tool which librarians should be prepared to augment and enhance 
 with analytics and better subject description. The art of subject bibliography 
 barely survives since so much of our time is taken with routine procedures. 
 But this alternative requires that funds realized by savings made through the 
 enlightened use of technology be used to enhance the services offered to the 
 user, an action which must be presented to the administrator with cogent 
 argument and firm cost-benefit projections. 
 
SUMMARY 165 
 
 Total System Service 
 
 Finally, I want to look at the future which Warheit denied himself in the 
 excellent paper which opened this clinic. In the papers which have been 
 presented there are some clues as to the final shape of the on-line systems 
 which will be used by libraries. I believe that we will eventually see, in the 
 center, an arrangement of very precise task-oriented files, made up of very 
 short records of carefully selected data elements being used to perform the 
 housekeeping functions of circulation, acquisition, fiscal control, serials 
 control and, probably, the shelflist. Surrounding and supporting these will be 
 the major standard, almost static (once a record is established) files of full 
 bibliographic description which will support and supply the volatile task files. 
 Further out will be the files of indexes and abstracts which will be searched 
 either currently for selective discrimination of information or retrospectively 
 for or by the library users, and which will also link into the center files to 
 provide location and availability information, and, perhaps rarely, to the 
 middle circle for bibliographic data. 
 
 The remarks made by Atkinson on the feeding of the OSU on-line 
 shelflist for circulation purposes by OCLC tapes and the way in which 
 BALLOTS is expected to develop, clearly point in this direction. Pizer's 
 account of the proposed interlibrary loan module of BCN attacked the 
 problem from the other direction. The work being done at Syracuse Univer- 
 sity, not reported at this clinic, also points this way. 
 
 I have talked throughout this summary of funding for implementation, but 
 the research is not yet over. Rather, it may soon be moving into a phase of 
 synthesis as the discrete building blocks are joined into a comprehensive 
 system, and the need for adequate funding for research is just as urgent. But I 
 believe that the systems which are presently available and the quality of 
 achievement which they represent should give librarians confidence as they 
 seek support. 
 
 On-line library systems have moved from being technically possible to 
 being technically feasible, as we have seen demonstrated both at this clinic 
 and by other workers in the field. If we can continue in this direction we can 
 develop a total system of service which is aimed at a vastly improved 
 individual service for the user and an efficient operation for the library. 
 
 REFERENCES 
 
 1. Knight, Douglas M., and Nourse, E. Shipley, eds. Libraries at Large. 
 New York, R.R. Bowker, 1969; and Kilgour, Frederick. "Evolving, Com- 
 puterizing, Personalizing," American Libraries, 3:141-47, Feb. 1972. 
 
766 7972 CLINIC ON APPLICA TIONS OF DA TA PROCESSING 
 
 2. Montague, Eleanor. Summary of a Feasibility Study on the Partici- 
 pation of Four Colleges and Universities in a Stanford University Library 
 Automation Network, Stanford, Calif., SPIRES/BALLOTS Documentation 
 Office, 1971. 
 
 3. Kilgour, op. cit., p. 142. 
 
 4. University of Rochester. Library Catalog Department. Study reported 
 in Five Associated University Libraries Newsletter, 3:3, May 1972. 
 
 5. Kaser, David. "Extra-library Barriers to Interlibrary Cooperation." In 
 Rationalizing Research Libraries in the 70's (Proceedings of a Symposium 
 sponsored by the Five Associated University Libraries, Nov. 12, 1970.) 
 Syracuse, N.Y., PAUL, 1971, p. 35. 
 
INDEX 
 
 Abstracting services, 8, 9, 59-65. 
 Association for Computing Machinery, 
 
 145. 
 Automation of libraries, 53-68; 
 
 critique and cost of, 138-65. 
 Avram, Henriette, 142. 
 Axford, William, 140. 
 
 Barnett, M. P., 155. 
 
 Batch system: serials, 70-72; catalogs, 
 
 95-96. 
 Biomedical Communications Network 
 
 (BCN), 57,64, 65,66, 161. 
 Biomedical Library, University of 
 
 California (Los Angeles), passim, 
 
 69-81, 141-42, 159, 161. 
 Book order system. See On-line book 
 
 order system. 
 
 Book storage and retrieval, 7. 
 Boulding, Kenneth, 144. 
 
 California, University of (Los 
 Angeles): Biomedical Library, 
 passim, 69-81, 141-42, 159, 161. 
 
 Chemical Abstracts, 8, 9, 59. 
 
 Computer editing, 4, 95. 
 
 Computer hardware and software, 
 25-26, 77-78, 83, 86+, 94, 110-11, 
 115-18, 129-35, 141. 
 
 Computer time sharing, 5, 66-67, 71, 
 
 77, 161-62. 
 Computer: value for libraries, 30, 
 
 53-56; critique and cost of, 138-65. 
 Consortia, on-line computers, 161-62. 
 
 DASD (Direct Access Storage De- 
 vices), 4. 
 
 DB/DC (Data Base/Data Communi- 
 cations) systems, 6, 7. 
 
 Drug Literature Index (DLf), 59. 
 
 Editing, use of computer, 4, 95. 
 Excerpta Medico, 59-60, 61. 
 Excerpta Medica Foundation, Drug 
 Literature Index, 59. 
 
 Files and indexes: organization of, 
 7-10, 17-19; services, 59-65, 95-96; 
 usage of, 104-05; capacity of, 
 133-135. 
 
 Food and Drug Administration, 8. 
 
 Golub, Harvey, 145. 
 Gray, James Morris, 96. 
 
 Hardware and software. See Computer 
 
 hardware and software. 
 Harvard University: on-line system at, 
 
 140-41. 
 
 767 
 
168 
 
 1972 CLINIC ON APPLICA TIONS OF DA TA PR OCESSING 
 
 Health Sciences, Library of the, 65, 
 66. 
 
 IBM STAIRS operating system, 60. 
 Index and files: organization of, 7-10, 
 
 17-19; services, 59-65, 95-96, 164; 
 
 usage of, 104-05; capacity of, 
 
 133-135. 
 
 Index Medicus, 16, 59. 
 Information: costs of, 10-15, 70-72, 
 
 145-55, 159-60, 163-64. 
 
 Kansas: Public Schools Library system, 
 
 94-108. 
 
 Kaser, David, 163. 
 Kilgour, Frederick, 30, 144, 159. 
 
 Library automation, 53-68; critique 
 and cost of, 138-65. 
 
 Library budget constraints, 139, 
 141-42. 
 
 Library loans: on-line system for, 
 56-59,70. 
 
 Library of Congress, 4, 5, 11, 24. 
 
 Library of the Health Sciences, 65, 66. 
 
 Lipetz, Ben-Ami, 24. 
 
 Los Gatos Library Management 
 System, 8,9, 14. 
 
 Mahan, Thomas, 43. 
 
 MALIMET (Master List of Medical 
 Indexing Terms), 60. 
 
 MARC system, 5, 9, 11, 16, 20, 67, 
 78,83, 109+, 161, 162. 
 
 McKinsey & Company: survey of com- 
 puter efficiency, 145. 
 
 Medical uses of on-line systems, 65-66. 
 
 Melcher, Daniel, 140. 
 
 MT/ST (Magnetic Tape/Selectric Type- 
 writer), 4, 11, 141; costs of, 153. 
 
 National Academy of Sciences: report 
 on Libraries and Information 
 Technology, 10. 
 
 National Advisory Commission on 
 Libraries, On the Economics of 
 Library Operations, 142. 
 
 National Commission on Libraries, 
 Libraries at Large, 159. 
 
 National Library of Medicine: Bio- 
 medical Communications Network, 
 8, 11, 57, 60-61, 64, 65, 66, 161; 
 graph of on-line users, 62. 
 
 National Union Catalog, 5, 9. 
 
 New York, State University of: on-line 
 computers, passim, 54-68. 
 
 New York Technical Services Librari- 
 ans, 142. 
 
 New York Times Information Bank, 
 141. 
 
 Northwestern University Library: on- 
 line system at, 8 2-9 3, 141, 159. 
 
 Ohio College Library Center, 141, 
 161. 
 
 Ohio State University: on-line hard- 
 ware at, 25-26, 141. 
 
 On-line book order system: effect on 
 workload, 31-35, 38, 4143, 44, 53; 
 costs of, 31, 32, 35, 45-53; print- 
 out, 34; accounting procedures of, 
 35-36, 48-53; flagwords in, 37-38; 
 author search program of, 38-40; 
 purchase orders of, 40-42, 48, 
 50-5 1 ; use in libraries, 43-44. 
 
 On-line computer consortia, 161-62. 
 
 On-Line interactive systems: access to, 
 101; applications of, 15-20; cata- 
 loging with, 94-108, 121-29, 130; 
 cost of, 10-15, 70-72, 99-1 01; criti- 
 que of, 138-65; efficiency of, 
 101-04; error detection with, 91, 
 93, 101, 115; flowchart for, 30; 
 hardware and software for, 77-78, 
 83, 86+, 94, 110-11, 115-18, 
 129-35; history of, 3-10; 
 implementation of, 160-61; man- 
 agement aspects of, 105-08; mul- 
 tiple uses of, 61-65; operation of, 
 1 3, 80-8 1 , 1 04-05 , 1 20-2 1 ; ordering 
 with, 113-15,116, 1 1 7 (See On-line 
 book order system); reference and 
 retrieval systems, 18-19, 59-65, 73, 
 75, 78-79; screen formats for, 
 118-19; searching with, 110-13, 
 121-29, 132-33; staff morale with, 
 72, 92, 164; staff sharing with, 
 66-67; standardization of, 67-68, 
 162-63; workload of, 92-93. 
 
 Oregon College of Education Library: 
 use of on-line book order system, 
 44. 
 
Index 
 
 169 
 
 Oregon State University Library: use 
 of on-line book order system, 
 passim, 29-53. 
 
 Pacific Southwest Regional Medical 
 
 Library Service, 70. 
 Picturephone, 67. 
 
 RAMAC disk file, 4, 17-18. 
 Reference and retrieval systems, 
 18-19,59-65,73,75,78-79. 
 
 Security: use of on-line equipment, 
 
 92. 
 Serials holdings: printout, 73, 74, 75, 
 
 76-77; retrieval of, 78-79. 
 Shelflist: Computer conversion of, 
 
 97-99, 141. 
 Standard Register Source Record 
 
 Punch, 9 1 . 
 Stanford University Library, passim, 
 
 109-36. 
 
 Storage and retrieval systems, 7, 
 
 59-65. See Reference and retrieval 
 
 systems. 
 
 Taylor, Robert L., 153 
 Technology: value for libraries, 30, 
 
 53-56; critque and cost of, 138-65. 
 Time sharing, 5, 66-67, 71, 77, 
 
 161-62. 
 
 UNISIST Study Report on the Feasi- 
 bility of a World Science Infor- 
 mation System, 60 
 
 U.S. Atomic Energy Commission, 
 Library of Technical Information 
 Division, 14-15. 
 
 Veaner, Allen, 140, 141, 142. 
 
 Wisconsin, University of (Green Bay): 
 
 computer cost analysis, 153. 
 Wilson, H. W. Companv i* 
 
UNIVERSITY OF II LINOIS-URBANA 
 
 30112071033333