276 ON-LINE ACQUISITIONS BY LOLITA Frances G. SPIGAI: former Information Analyst, Oregon State University Library; and Thomas MAHAN: Research Associate, Oregon State University Computer Center, Corvallis, Oregon. The on-line acquisition program (LOLITA) in use at the Oregon State University Library is described in t erms of development costs, equipment requirements, and overall design philosophy. In pa1'ticular, the record format and content of records in the on-orde1' file, and the on-line pro- cessing of these records (input, search, correction, output) using a cathode ray tube display terminal are detailed. The Oregon State University Library collection has grown by 15,000- 20,000 new titles per year (corresponding to 30,000-35,000 volumes per year) for the past three years to a total of approximately 275,000 titles ( 600,000 volumes); continuing serials account for a large percentage of annual "volume" growth. These figures would indicate an average input of 60-80 new titles per day. On an average, a corresponding number of records are removed each day upon completion of the processing cycle. A like number of records are updated when books and invoices are re- ceived. In addition, approximately 200 searches per day are made to determine whether an item is being ordered or to determine the status of an order. Since the mid-1960's, and with the introduction of time-sharing, a handful of academic libraries ( 1, 2, 3) and several library networks ( 4, 5, 6) have introduced the advantages ( 7) of on-line computer systems to library routines. Most of the on-line library systems use teletypewriter terminals. Use of visual displays for library routines has been limited, although Stanford anticipates using visual displays with IBM 2741 type- On-Line AcquisitionsjSPIGAI and MAHAN 277 writer terminals in a read-only mode ( 1), and the Library of the IBM Advanced Systems Development Division at Los Gatos, sharing an IBM 360/50, uses an IBM 2260 display for ordering and receiving ( 8). In addition, an Institute of Library Research study, focusing on on-line maintenance and search of library catalog holdings records, has concluded that even with the limited number of characters available on all but the most expensive display terminals " ... the high volume of data output associated with bibliographic search makes it desirable to incorporate CRT's as soon as possible, in order to facilitate testing on a basis superior to that achievable with the mechanical devices." (9). Many academic libraries, during shelflist conversion or input of acqui- sition data, use a series of tags for bibliographic information. Some of these tags are for in-house use, while others presumably are used to aid in the conversion of MARC tape input to the library's own input format. The number of full-time staff required to design and operate automated systems in individual academic libraries typically ranges from seven to fifteen. This doesn't seem to be an inordinate range, since most depart- ments of a medium-large to large academic library require a similar size staff for operational purposes alone. LOLITA (Library On-Line Information and Text Access) is the auto- mated acquisition system used by the Oregon State University Library. It operates in an on-line, time-shared, conversational mode, using a cathode ray tube (CDC-210) or a 35-KSR Teletype as a terminal, depending upon the operation required. Both types of equipment are in the Acquisi- tions Department of the Library; each interacts with the University's main computer ( CDC-3300, 91K core, 24-bit words), which, in turn ac- cesses the mass storage disk ( CDC-814, capable of storing almost 300 million characters) through the use of LOLITA's programs in conjunction with the executive program, OS-3 ( 10). Under the OS-3 time-sll,aring system, LOLITA shares the use of the central computer memory and processor with up to 59 other concurrent users; the use of the mass storage disk is also shared with other users of the University's Computer Center. (LOLITA will require approximately 11 million characters of disk storage). LOLITA's programs are written in FORTRAN and in the assembly lan- guage, COMPASS, and are composed of two sets: those which maintain the outstanding order file, and those which produce printed products and maintain the accounting and vendor files. Several key factors have shaped the design of LOLITA. An on-line, time-sharing system has been operating at OSU since July 1968, and on- line capabilities have been available for test purposes since the summer of 1967. Programming efforts could be concentrated exclusively on the design of LOLITA and an earlier pilot project ( 11) , for no time was needed to design, debug or redesign the operating system software, as was necessary at Washington State U. and the U. of Chicago (2, 12) . - Heavy reliance was put on assembly language coding for the usual 278 journal of Library Automation Vol. 3/4 December, 1970 reasons, plus the knowledge that the Computer Center's next computer is to be a CDC-3500, with an instruction set identical to that which the Library now uses. In short, neither the OS-3 operating system nor the assembly language will change for the next few years. An added motiva- tion influencing program design was the desire to minimize response time for the user. In view of the transient nature of a university library's student and civil service staff, the need for an easily-learned and maintained system is paramotmt. The flerible display format of the CRT allows a machine readable worksheet, with a built-in, automatic, tagging scheme; it ob- viates the need for a paper worksheet, and thus eliminates a time-consum- ing, · tedious, and error-prone conversion process. The book request slip contains the source information for input. Proofreading and correction are done on-line at time of input. Alterations can be made at any later time as well. LOLITA has used from 1.5 to 3.0 FTE through the period of design to operation. After an initial testing and data base buildup period, anticipated to last about six months, and during which LOLITA will be run in parallel with the manual system, it is expected that the on-order/in-process, vendor, and accounting files will be maintained automatically and that reports and forms currently output by the Acquisitions Department staff will be generated automatically. Specifically, records comprising three files will be kept on-line : 1) the outstanding order file (a slight misnomer since it includes and will include three types of book request data: out- standing orders, desiderata of high priority, and in-process material), 2 ) name and address for those vendors of high use (approximately 200 of 2500, or about 8% ), and codes and use-frequency counts for all vendors, and 3) accounting data for all educational resource materials purchased by the Oregon State University Library. It should be kept in mind that, although LOLITA is designed for book order functions, the final edited record, after the item has been cataloged, will be captured on magnetic tape as a complete catalog record. Thus, all statistics and information, except circulation data, will be available for future book acquisitions. This project is being undertaken for two reasons: 1) the Oregon State University Library is concerned that librarians achieve their potential as productive professionals through the use of data processing equipment for routine procedures, and that cost savings may be realized as the Library approaches a total system encompassing all of the technical serv- ices routines, and 2) a uniquely receptive Computer Center and a success- ful on-line time-sharing facility are available. RECORD FORMAT AND CONTENT Each book request is described by 27 data elements which are grouped into three logical categories and are displayed in three logical "pages" On-Line AcquisitionsfSPIGAI and MAHAN 279 of a CRT screen. The categories are: 1) bibliographic information, 2) accounting information, and 3) inventory information; Figures 1, 2, and 3 list the data elements in the same sequence as they appear on the CRT screen. Though most data elements listed are self-explanatory, eight require some description. ORDER NUMBER FLAG WORD AUTHOR TITLE EDITION ID NUMBER PUBLISHER YEAR PUBLISHED NOTES Fig. 1. Bibliographic Information. ORDER NUMBER DATE REQUESTED DATE ORDERED ESTIMATED PRICE NUMBER OF COPIES ACCOUNT NUMBER VENDOR CODE VENDOR INVOICE NUMBER INVOICE DATE ACTUAL PRICE DATE RECEIVED DATE 1ST CLAIM SENT DATE 2ND CLAIM SENT Fig. 2. Accounting Information. ORDER NUMBER BIB CIT DATE CATALOGED VOLUME ISSUE LOCATION CODE LC CLASS NUMBER Fig. 3. Inventory Information. 280 l ournal of Library Automation Vol. 3 f 4 December, 1970 Flag Word This data element indicates the status of a request. The normal order procedure needs no Hag word. Exceptions are dealt with automatically by entering an appropriate Hag word. As more requests are added to the system, and as more exceptional instances are uncovered, more Hag words will undoubtedly be added. To date there are twelve Hag words, plus one data element which serves both as a data element and as a status signal. Flag words and procedures activated are described below. CONF.: Confirming orders for materials ordered by phone or letter, and for unsolicited items which are to be added to the collection. The order form is not mailed, but used for processing internal to the Library only. Accounting routines are activated. GIFT: For gift or exchange items, a special series number prefixed by a "G" is assigned and the printed purchase order is used internally only. This Hag word also acts as a signal so that accounting routines will not encumber any money. The primary reason for assigning a purchase order number is to provide a record indexing mechanism (this is also true for HELD orders) . HELD : Selected second-priority orders being held up for additional book budget funds. These order records are kept on line, and are assigned a special series of purchase order numbers, prefixed by an "H." No account- ing procedures accompany these orders, although a purchase order is generated and manually filed by purchase order number. LIVE : HELD orders which have been activated. This word causes a reassignment of purchase order numbers to the next number in the main sequence ( instead of "H" -prefixed numbered) and sets up the natural chain of accounting events. The new purchase order number is then written or typed on the order form, the order date added, and the order mailed. CASH: Orders for books from vendors who require advance payment. An expenditure, instead of an encumbrance, is recorded. RUSH: Used for books which are to be rush ordered and/or rush cataloged. RUSH will also be rubber-stamped on the purchase order for emphasis. No special procedures are activated within the computer pro- grams; RUSH is an instruction for people. DOCS: Used when ordering items from vendors with whom the OSU Library maintains deposit accounts (e.g. Government Printing Office). This causes a zero encumbrance in the accounting scheme; CASH is used to put additional money into deposit accounts. CANC: Cancelled orders. Unencumbers monies and credits accounts for CASH orders. REIS: Used to reissue an order for an item which has been cancelled. A new purchase order containing a new order number, vendor, etc. will automatically be issued. Re-input is not necessary; however, changes in vendor no., etc., can be made. On-Line Acquisitionsj SPIGAI and MAHAN 281 PART: Denotes a partial shipment for one purchase order. No catalog date can be entered while PART appears as the flag word. INVO will replace PART when the final shipment has been received; CANC will replace PART if the final shipment is not received, and the order is reissued for the portion received. · INVO : When invoice information is entered into the file, INVO is typed in as the flag word. This causes accounting information (purchase order number, vendor code, invoice number, actual price, invoice data, account number) to be duplicated in the accounting file. KILL: Used to remove an inactive record from the file ( cf. DATE CATALOGED). DATE CATALOGED: A value entered for this data element signals the end of processing. The record is removed from the main file and trans- ferred to magnetic tape. Changes and additions to inventory and bib- liographic data elements are anticipated at this final point, to bring the record into line with those of the Catalog Dept. Author(s) All authors are to be included in this data element, corporate authors, joint authors, etc. The entry form is last name first (e.g. Smith, John A. ). For compound authors, a slash is used as the delimiter separating names (e.g. Smith, John A. I Jones, John Paul) . ID Number Standard book number, vendor catalog number, etc. Order Number The order number is automatically assigned to one of three series depending on the flag word: the main number series with the fiscal year as prefix; HELD order series with an "H"-prefix (stored in the order number index as 101, the "H" is what is printed on the order forms); and GIFT series with a "G" -prefix (likewise stored in the order number index as 102). Vendor Code A sample of 18 months of invoice data (obtained from the Comptroller's Office) for the Library resource account number indicates the use of 2200 vendors during that period of time. By sorting by invoice frequency and dollar amount, about 200 vendors were identified who either invoiced the Library more than 12 times during this time period (since the invoices tended to contain more than one item for frequently used vendors, the number of purchase orders issued could easily be several times this amount), or whose invoices totalled over $110.00. Of these, 171 have been selected for on-line storage. They will be assigned code numbers 1 to 171, and names and addresses of these vendors will be included on the computer generated purchase orders. Authority files for all vendors 282 Journal of Library Automation Vol. 3/4 December, 1970 are kept on Rolodex units; one set is arranged alphabetically by vendor name, the other by vendor code. Account Number The Library account to which the book is charged. The number is divided into four sections: 1) a two-digit prefix identification for OSU, 2) a four-digit identification for OSU Library resource expenditures, 3) a one- or two-digit identification of the particular Library resource fund account to be charged (e.g. Science, Humanities, Serials, Binding, etc. ), and 4) a one- or two-digit code identifying the subject which most closely describes the request. From this data, statistics will be derived which describe expenditures by subject as well as by fund allocation. This will provide a powerful tool for collection building and . may also be a political aid in governing departmental participation in book selection. BIBCIT Bibliographic citation code which cites the location by Acquisitions Dept. personnel of bibliographic data ( L.C. copy, etc. ). This information is included on the catalog work slip (4th copy of the purchase order) so that duplicate searching by the Catalog Dept. can be avoided. LC Classification Number Refers to the call number as it is assigned by the OSU Catalog Dept. FILE ORGANIZATION On-Order Record The operating system for Oregon State University's on-line, time-sharing system reads into memory a quarter page (or file block) of 510 computer words at a time. Each on-order (outstanding order) record is composed of a block of 51 computer words ( 204 6-bit characters), or linked lists of blocks, in order to best use this system. Thu·s, each quarter page is divided into ten physical records of 51 computer words apiece. For rec- ords requiring more than one block, the nearest available block of 51 words within the same 510 word file-block is used; but if none is vacant within the same file-block, the first available 51-word block in the file is used. If none is free the file is lengthened to provide more blocks. A bit array is used to keep track of the status (in use, vacant) of records in the main file. In the bit array, each of 20 bits of each 24-bit computer word corresponds to a 51-word block in the main file. As in Figure 4, the 13th bit has a zero value, indicating a vacancy in the 13th 51-word block of the main file; the 14th bit has a value of 1, indicating the 14th 51-word block in the on-order file is in use. A total of 10,120 block locations can be monitored by each file block of the bit array. Records in this file are logically ordered by purchase order number, the arrangement effected by pointers which string the blocks together. On-Line Acquisitiansf SPIGAI .and MAHAN 28$ 510-word ftle - block unused 4 bits one -word b i t array Fig. 4. Bit Army Monitor of Record Block Use in the On Order File. Access Points Order Number The order number index is arranged by the main portion of the order number, and within that, it is in prefix number sequence. The sequence in Figure 5 illustrates order number index arrangement (as well as the logical arrangement of the on-order file). The order number index allows quick access to selected points within the main file. Conceptually, the ordered main file is segmented into strings of records whose order numbers fall into certain ranges. More specifically, items whose sequence numbers range from 0 to 4 (ignoring the prefix of the order number) comprise the first segment, 5 to 9 the second, etc. The index itself merely contains pointers to the leading record in each (conceptual) segment. Thus, in the records whose purchase order numbers are shown in Figure 5, there would be pointers to the second (69-124) and sixth (70-125), but not to the others. To reach the fourth ( 101-124) one follows the index to the second, and then follows the block pointers through the third to the fourth . 102-118 69-124 70-124 101-124, 102-124 70-125 102-125 . 70-126 Fig. 5. Fiscal Year 1969, Order Number 124 Fiscal Year 1970, Order Number 124 HELD Order Number 124 for the Current Year Gift Order Number 124 for the Current Year ( Note : The prefix 'H,' which is printed on the purchase orders is represented as the number 101 for internal computer processing; likewise 102 represents the prefix 'G') Order Number Index Sequence. 284 Journal of Library Automation Vol. 3/4 December, 1970 P.O. Number Forward Pointer ' P.o. Number Backward Pointer Time of Last Update . P. 0. Number Title Forward Pointer v Title Backward Pointer v Pointers to Author( s) / ~ ~ Title > Date of Re_quest Date Ordered Encumbered Price Number of C<>E_ies Account Number (2 words) Vendor Number FlAG Word ~ Publisher 1 Date of Publication ~ Notes ~ ~ Edition ~ lD Number ~ BlBCIT ' LC Classification Number )' Volume Number Issue ~ Location Code ; ~ ~ Vendor's Invoice Number ~~ Invoice Date Actual Price Date Received Date First Claim Sent Date Second Claim Sent Fig. 6. "On Order" Record Organization. On-Line AcquisitionsjSPIGAI and MAHAN 285 Author(s) The author index is in the form of a multi-tiered inverted tree. The lowest tier is an inverted index containing the only representation of the author's names (it is not stored in the on-order record (Figure 6), and, for each author, pointers to the records of each of his books (Figure 7). The entries for several authors may be packed into a single 51-word block, if space permits. Each higher tier serves to direct the indexing mechanism to the proper block in the next tier below, and to this end as much as needed of an author's name is filed upwards into higher tiers; this method is described in more detail by Lefkovitz ( 13) as "the unique truncation variable length key-word key." AUTHOR INDEX DIRECTORY (Level 0 + 1) JOHN/ JONES, J 927 INVERTED AUTHOR INDEX (Level 0) Control Word (II chars. in record; # chars. in full name of author; # of titles JONES, T JONES, JOHN PA UL 928 JOP K.A 1282 TOW ~ ~~~3 in on order file ~~2~66~7------------~ ON ORDER FILE 1072 927 10/20/69 10/29/69 $4.95 . 30-1061-6-20 16 0000 1282 10 Fig. 7. Author Index Organization and Access to On Order File. Title Not yet programmed. ON-LINE RECORD PROCESSING Record Creation After a number of new book requests have been searched to determine their absence from OSU's collection and after they have been bibliograph- ically identified, they are hatched for vendor assignment and readied for entry into the on-line file of book requests via the CRT (Figure 8 ). L-.:> 00 0) g '"'t i5 -c -~ N ... /Y'RIFIID "-.. N _/ NOT ""I ASSIQl vrNOOR 1•..-::-::-. _ I .... ~ a ~ y I > ~ ...... c ~ ...... .... c ;:s N < 0 !-' CN -~ d (!) () (!) !3 0"' (!) ~'"I ..... tO -..1 0 Fig. 8. Book Request Processing. On-Line AcquisitionsjSPAGAI and MAHAN 287 LOLITA's starting page is obtained by typing in the word LOLITA on the CRT screen. The text illustrated in Figure 9 is then displayed on the screen of the CRT. When 'T' is typed in, indicating a wish to create a record, the first data element of the first page of input appears (Figure 10). (Since the majority of records do not need a flag word upon input, the flag word fill-in line appears only on a redisplay of this page, and the flag word may be inserted at that time.) MAIN FILE PLEASE INDICATE A CHOICE 1. CREATE A NEW ENTRY 2. LOCATE AN EXISTING ENTRY 9. TERMINATE ALL PROCESSING Fig. 9. "Starting" Page of Function Choices. AUTHOR(S): EXAMPLES: JONES DEQUINCEY, THOMAS WASHINGTON, BOOKER T. ADAMS, JOHN QUINCY/ DOE, JOHN AMERICAN MEDICAL ASSOCIATION Fig. 10. First Data Element Displayed in New Record Creation Process. At this point the user can go in one of two directions. The first page of input information may be entered one data element at a time, each element being requested in a tutorial fashion by LOLITA. Alternately, all of the first page data may be input at once, with data elements separated by delimiters. The user can switch from one method to the other at any point. A control key (RETURN) is the delimiter used to signal the end of each data element, and, at the same time, RETURN repositions the cursor (which indicates the position of the next character to be typed on the CRT screen) to the location of the next data element to be filled in. Another conh·ol key (SEND): 1) serves as a terminal delimiter, and 2) transmits data on the screen to the computer, thereby 3) triggering the continuation of processing until the next screen display is generated. Thus, with page one, data elements are displayed, filled in and sent one at a time in the tutorial approach, or, all seven data elements are typed in at once, a RETURN mark following items 1-6, then sent after the last data element. RETURN or SEND must be used with each data element, even with those for which there is no information. This secures the sequence of element input, thus providing an easy (for the user) and automatic way of tagging elements for any future tape searches to provide statistics or analytical reports. In particular, this process obviates all content restrictions on variable (ie., free-form) items. Each of the pages is redisplayed after 288 Journal of Library Auto'TIUltion Vol. 3/4 December, 1970 input, and corrections can be made at this time. The CRT is used for all input and its write-over capabilities are utilized for corrections, as com- pared to the "read-only" use planned for CRT displays used for Stanford's BALLOTS ( 1). Except for the flag word, all the data elements on the first page are variable in length and unrestricted as to content. Data elements on page 2 and 3 (Figures 2 and 3) are more of a fixed length in nature; thus with these pages, a whole page at a time is always filled in and sent: the tutorial function is inherent in the display. The concluding display is shown in Figure 11. SEND IF ALL DONE, TYPE 1-3 TO REVIEW PAGES. Fig. 11. Review Option. Because hatched searching and input are assumed, when one search or input is finished, the program recycles to continue searching or inputting without going back to the starting page (Figure 9) each time. Record Search Searching programs have been completed which will search by order number and by author. Title searching will be implemented within the next few months, although a satisfactory scheme for title searching ( im- proving on manual methods, yet economical) has not been uncovered. Methods suggested or used by Ames, Kilgour, Ruecking, and SPIRES have been noted (14, 15, 16, 17). The procedure for searching within the outstanding order file begins with the display of choices shown in Figure 9. One types a "2," indicating a desire to locate an existing entry, and the text shown in Figure 12 is displayed on the CRT screen. At this point one chooses to search either by order number or by author. If one selects a valid order number rep- resenting a request record, the first page of that record, containing bib- liographic information, is displayed. This is followed by the display shown in Figure 11, so that accounting and inventory information may also be reviewed. For the user's convenience the order number is displayed in the upper right-hand comer of each of the three pages, both upon record input and search redisplay. To search by author, one types the author's name on the second line of Figure 12, using the same format as that used in record creation. If the ------------------------- : ORDER NUMBER ------------------------------- : A UTH 0 R SUPPLY ONE OF THE ABOVE (START ON THE APPROPRIATE LINE) Fig. 12. Display of Search Options. ' On-Line AcquisitionsjSPIGAI and MAHAN 289 author has only one entry in the outstanding order file, the first page of the entry will appear, etc. (as in the order number search above) . If the author entered has more than one entry in the on-line file, information depicted in Figure 13 will be displayed on the screen of the CRT. __ _____________ : ENTER NUMBER OR 'NF' (NOT FOUND) 1. NIGHT OF THE IGUANA 2. THE MILK-TRAIN DOESN'T STOP HERE ANYMORE 3. CAT ON A HOT TIN ROOF n. THE GLASS MENAGERIE Fig. 13. Display of Multiple Titles on File for One Author. If the requested title is one of the titles displayed, one types its number and the record for that title will be displayed. If the title isn't among those displayed, typing NF would result in a redisplay of the text in Figure 12 in order for searching to continue. For personal authors, variant forms of the name may be located using the following procedure. The word OTHERS is entered at the top of the screen, after an unsuccessful author search, so that a search for author J. P. Jones would find all documents by John Paul Jones, Joseph P. Jones, J. Peter Jones, etc., as well as J. P. Jones. A search for John P. Jones would find all documents by J. P. Jones, John Jones and J. Peter Jones as well as John P. Jones. Record Changes Additions and corrections to the original record are made by first locat- ing the record (by order number, author, or eventually, title), adding to the data elements, or writing over them (for corrections), and transmitting the information. Examples of this procedure include: 1) entering the date received, 2) recording the vendor invoice number, invoice date, and actual price and 3) inserting or changing a flag word. In addition, after an item has been cataloged, the record is revised to include catalog data, as well as to exclude extraneous order notes. Output Aside from the CRT displays, output is in three forms: off-line tape, printed forms and on-line files (Figure 14). Examples of output are library purchase orders, accounting reports, vendor data, and records of cataloged items. The number of potential reporting uses is limited only by money and imagination. 290 Journal of Library Automation Vol. 3/4 December, 1970 Fig. 14. Output from On-Line On Order File Input. I ORDER NUMBER I I DATE I ID NUMBER AUTHOR TITLE PUBLISHER VENDOR NAME VENDOR ADDRESS VOUJMES EDITION Fig. 15. Purchase Order. f ESTIMATED PRICE I NO. Of COPIES I VENDOR COOE I ACCOUNT DATE OF PUB. * * * • FLAG** • * GIFT OR HELD ORDER NO. BIBCIT LIBRARY PURCHASE ORDER 00 r CD !il~ iii r= ::0 r < . > SP >Cil r-i ~ C/l c~ X C/lfTl :v 0 c: -i ::0 z 0 "' < Q "' ~ ::0 C/l ~ :::; -< On-Line AcquisitionsfSPIGAI and MAHAN 291 The purchase order, shown in Figure 15, is composed of four copies: 1} the vendor's copy to be retained by him, 2) a vendor "report" copy, 3) the copy which is kept as a record in the OSU Library, and 4) a catalog work slip to be forwarded to the Catalog Department with the book. Purchase orders are printed on the Library's Teletype, which is equipped with a sprocket-feed. Orders can also be printed on the line printer in the Computer Center. While this is a slightly cheaper data processing procedure, since no terminal costs are incurred, convenience and security have produced a victory in "economics over economies" ( 18 ), and the librarian's time has been considered in the total scheme. For gift items, purchase orders are produced as the cheapest means of preparing a catalog work slip. HELD purchase orders are produced and manually filed in purchase order number sequence, but when their status is changed to LIVE, the old numbers are automatically replaced by a purchase order number in the main series. These new numbers are written onto the purchase orders, along with any other changes, and the orders are mailed. The flag word LIVE also activates accounting procedures. There are two sets of accounting reports. The first is generated when the purchase orders are issued and contains tabulated information for the Library's Bookkeeper, the Head of Business Records in the Acquisitions Dept., and the Comptroller of the Oregon State System of Higher Educa- tion. The second summary report is issued after the book and invoice have been received and will contain additional information, pertinent to the invoicing procedure; this report has the same distribution as the first. Periodic reports are planned for the Library's subject divisions summariz- ing expenditures by account number, reference area, and subject. Pro- gramming for this has not yet been done. A frequency count will be stored with each vendor code and periodic listings will be printed for use in retaining vendors. Mter an item has been cataloged, the catalog work slip and a slip equivalent to a main-entry catalog card are sent to Acquisitions, and all remaining information and changes are recorded in the on-line record. This record is then transferred to a file from which it is dumped onto a magnetic tape. This off-line file will be used for statistical analyses and will be the start of a machine readable data base. Future plans will, of course, depend on funding; however, two logical steps which could follow immediately and require no additional conversion are: 1) additional computer generated paper products (charge cards, cata- log cards, book spine labels, new book lists, etc. ) , and 2) a management information system using acquisition and cataloging data. The construction of a central serial record in machine readable form would produce many valuable by-products. A program for the translation of the MARC II test tape has been written which causes these records to be printed out on the Computer Center's line printer; and since a sub- 292 Journal of Library Automation Vol. 3/4 December, 1970 scription to the MARC tapes is now available to OSU for test purposes, its advantages and compatibility with LOLITA will be investigated as time permits. Unsolved problems, aside from those which everyone working in a data processing environment faces (e.g. syst~m and hardware breakdown, con- tinued project funding, and lengthy dehv~ry times for hardware), include: 1) the widely varying system response tunes (commonly from a fraction of a second up to 60 seconds; usually 2-15 seconds); 2) the lack of per- sonnel skilled in both data processing and library techniques; 3) the limited print train currently available on the line printer ( 62 character set); and 4) bureaucratic policy, which can render the most sophisticated plans for automation unfeasible if properly applied. It is recognized that all these problems can be solved by money, time, and priorities. Meanwhile, the period of in-parallel operation will be valued as a time to educate, to test, to gather statistics, and to further refine the programs and procedures which comprise LOLITA. EVALUATION Preliminary input samples indicate that a daily average of from 8 hours, 20 minutes, to 10 hours and 45 minutes will be necessary for input, searches, ~ting and corrections using the CRT. An additional 3 hours per day ~f terminal time using the Teletype will be required to produce the pur- chase orders, answer rush search questions if the CRT is busy, and activate the daily batch programs (accounting reports, etc.). The sad economic plight of most libraries causes librarians to cast an especially suspicious eye on the costs of automation; a few words on OSU's data processing costs may b~ of interest. The cost of total develop- ment efforts to produce LOLITA IS under $90,000 (though considerably less was actually expended), or an average annual cost of $30,000 over a three-year period. This compare~ favorably with average annual incomes of from $50,000 to over $300,000 m Federal funds alone for other on-line library acquisition projects in ?Tiiversities ( 19, 20, 21, 22). A total of 6.75 man-years was required to des1gn LOLITA. The 6.75 man-years comprises 2.5 years of programming, 3.25 years .of systems analysis, coordination and documentation, and 1.0 year of clencal work, and represents the efforts of four students and six professional workers. This total does not in- clude the time spent by Acqu~sitions Department personnel in reviewing LOLITA's abilities or in leammg to use the terminals. Current data processing rates charged by the Computer Center include the following: CRT rental-$100/mo.; CPU time-$300/hr.; terminal time -$2.00/hr.; on-line storage costs-15c/2040 characters/mo. The Teletype has been purchased, thus only local phone lines charges are incurred. The on-line system is available for use from 7 :30 A.M. to 11:00 P.M. each week-day, and from 7:30 A.M. to 5:00 P.M. on Saturday, which more than covers the 8-5 schedule of the Acquisitions Department. il On-Line AcquisitionsjSPIGAI and MAHAN 293 ACKNOWLEDGMENTS The work on which this paper is based was supported by the Adminis- tration, the Computer Center and the Library of Oregon State University. Special mention is due Robert S. Baker, Systems Analyst, OSU Library, and Lawrence W. S. Auld, Head, Technical Services, OSU Library, for their extensive participation in the LOLITA Project and for their many suggestions which benefitted the final version of this paper. Hans Weber, Head, Business Records, OSU Library, also contributed much to LOLITA's design. REFERENCES l. Veaner, Allen B.: Project BALLOTS: Bibliographic Automation of Large Library Operations Using a Time-Sharing System. Progress Report, March 27, 1969-June 26, 1969, (Stanford California: Stanford University Libraries, 29 July 1969), ED-030 777. 2. Burgess, Thomas K.; Ames, L.: LOLA: Library On-Line Acquisition Sub~System~ (Pullman, Washington: Washington State University, Systems Office, July 1968), PB-179 892. 3. Payne, Charles: "The University of Chicago's Book Processing Sys- tem." In Stanford Conference on Collaborative Library Systems Development: Proceedings, Stanford, California, October 4-5, 1968 (Stanford California: Stanford University Libraries, 1969). ED-031 281, 119-139. 4. Pearson, Karl M.: MARC and the Library Service Center: Automa- tion at Bargain Rates (Santa Monica, California: System Develop- ment Corporation, 12 September 1969). SP-3410. 5. Nugent, William R.: "NELINET -the New England Library Infor- mation Network." In Congress of the International Federation for Information Processing (IFIP), 4th: Proceedings, Edinburgh, Aug- ust 5-10, 1968 (Amsterdam, North Holland Publishing Co., 1968 ). G28-G32. 6. Blair, John R.; Snyder, Ruby: «An Automated Library System: Project LEEDS," American Libraries, 1 (February 1970), 172-173. 7. Warheit, I. A.: "Design of Library Systems for Implementation with Interactive Computers," ] ournal of Library Automation, 3 (March 1970)' 68-72. 8. Overmyer, LaVahn: Library Automation: A Critical Review (Cleve- land, Ohio: Case Western Reserve University, School of Library Science, December 1969). ED-034 107. 9. Cunningham, Jay L.; Schieber, William D.; Shoffner, Ralph M.: A Study of the Organization and Search of Bibliographic Holdings Records in On-Line Computer Systems: Phase I (Berkeley, Cali- fornia University: Institute of Library Research, March 1969). ED- 029 679, pp. 13-14. 294 Journal of Library Automation Vol. 3/4 December, 1970 10. Meeker, James W.; Crandall, N. Ronald; Dayton, Fred A.; Rose, G. : "OS-3: The Oregon State Open Shop Operating System." In American Federation for Information Processing Societies: Proceed- ings of the 1969 Spring Joint Computer Conference, Boston, Mass., May 14-16, 1969 (Montvale, New Jersey: AFIPS Press, 1969), 241- 248. 11. Spigai, Frances; Taylor, Mary: A Pilot-An On-Line Library Acqui- sition System (Corvallis, Oregon: Oregon State University, Com- puter Center, January 1968), cc-68-40, ED-024 410. 12. University of Chicago. Library: Development of an Integrated, Com- puter-Based, Bibliographical Data System for a Large University Library (Chicago, Illinois: University of Chicago, Library, 1968). PB-179 426. 13. Lefkovitz, David : File Structures for On-Line Systems (New York: Spartan Books, 1969 ), pp. 98-104. 14. Ames, James Lawrence: An Algorithm for Title Searching in a Com- puter Based File (Pullman, Washington : Washington State Uni- versity Library, Systems Division, 1968). 15. Kilgour, Frederick G.: "Retrieval of Single Entries from a Com- puterized Library Catalog File," Proceedings of the American Society for Information Science, 5 (New York, Greenwood Publishing Corp., 1968)' 133-136. 16. Ruecking, Frederick H., Jr.: "Bibliographic Retrieval from Biblio- graphic Input; the Hypothesis and Construction of a Test," Journal of Library Automation, 1 (December 1968), 227-238. 17. Parker, Edwin B.: SPIRES (Stanford Physical Information REtrieval System). 1967 Annual Report (Stanford California: Stanford Uni- versity, Institute for Communication Research, December 1967), 33-39. 18. Kilgour, Frederick G.: "Effect of Computerization on Acquisitions," Program, 3 (November 1969), 100-101. 19. "University Library Systems Development Projects Undertaken at Columbia, Chicago and Stanford with Funds from National Science Foundation and Office of Education," Scientific Information Notes, 10 (April-May 1968), 1-2. 20. "Grants and Contracts," Scientific Information Notes, 10 (October- December 1968), 14. 21. "University of Chicago to Set Up Total Integrated Library System Utilizing Computer-Based Data-Handling Processes," Scientific In- formation Notes, 9 (June-July 1967), 1. 22. "Washington State University to Make Preliminary Library Sys- tems Study," Scientific Information Notes, 9 (April-May 1967), 6.