lib-s-mocs-kmc364-20140601052432 118 Journal of Library Automation Vol. 5/2 June, 1972 AUTOMATION OF ACQUISITIONS AT PARKLAND COLLEGE Ruth C. CARTER: System Librarian, University of Pittsburgh Libraries. When this article was in preparation, the author was Head of Technical Services and Automation, Parkland College, Champagne, Illinois This paper presents a case study of the automation of acquisitions fun ctions at Parkland College. This system, utilizing batch processing, demonstrates that small libraries can develop and support lm·ge-scale automated systems at a reasonable cost. In operation since September 1971 , it provides machine-generated purchase orders, multiple order cards, budget state- ments, ovet·due notices to vendors, and many cataloging by-products. Th e entire collection, print and nonprint, of the Learning Resource Center is being accumulated gradually into a machine-readable data base. INTRODUCTION-BACKGROUND Parkland College, opened in 1967, is a two-year community college located in Champaign, Illinois. Before the librarian-analyst, who combines a library degree with several years' experience as a computer systems analyst and six months of programming training, was hired by Parkland, the administration decided that automation of some library procedures was feasible. At the time the library decided to initiate automation planning (December 1970), it had a book collection just under 30,000 plus 1000 audio-visual items. The decision to automate would not have been possible unless a computer was available at the college. In the spring of 1970 when the librarian-analyst was hired, Parkland owned an IBM 360/ 30 with 32K. Before automation plans were under way, the college purchased an IBM 360/30 with 64K. The computer's increased capacity provided even more incentive for utili- zing the computer for significant projects in addition to instructional and administrative functions. Among the reasons in favor of automation was a Automation of Acquisitions/CARTER 119 general consensus indicating that automation was the way to go, and that the library with its many individual records is a natural for utilizing the computer. The automation of library acquisitions at Parkland is notable for several reasons. First, automation was done relatively easily and rapidly; actual systems design and programming were completed in six months. Full implementation was achieved within nine months of the formal beginning of the project. Second, documentation of the system is exhaustive and is based on a detailed method of communication between the system's librarian-analyst and the programmer. Third, automation in this instance was accomplished economically. Fourth, the entire system can be run on an IBM 360/30 with 32K having two disk drives and two tape drives, and a standard print chain consisting of just upper-case letters. WHAT TO AUTOMATE? This, of course, is a crucial question. Where out of the various alternatives of circulation, acquisitions, cataloging, and others does one begin? Neither the librarian-analyst nor the rest of the library staff made any attempt to work out an answer during the fall of 1970. The librarian-analyst, as head of Technical Services spent the first four months concentrating on cataloging and learning the problems in the acquisitions area. By December she was ready to begin planning for automation. Meetings were arranged with the director of the Learning Resource Center and the director of the Computer Center. Informal discussions with the library staff were held. Circulation was eliminated early from consideration, since Parkland is in temporary quarters. It seemed more logical to develop the area of circula- tion with the move to the permanent campus. In addition, the volume of circulation did not appear to warrant the time and personnel commitment necessary to develop a comprehensive system at this time. Several possi- bilities remained: the acquisition of new materials, conversion of our whole catalog, and periodicals control, including automatic claim notices. Periodicals seemed the least likely of the three, because our holdings numbered less than 700, and it was felt that the volume involved did not justify the effort and expense of going to a computer system, particularly the first computer system within the library. Converting the whole catalog had some positive arguments. It would provide a data base for later circulation efforts and also make it possible to produce bibliographies and other service features for faculty members. However, this idea was discarded due to the large initial data-conversion problem, and because it did not provide relief for existing problems within the library. The library staff concluded that acquisitions had first priority for automa- tion. To this the director of the Computer Center heartily agreed on the grounds that it was a conventional data processing type of application, and it would dovetail with existing data bases already maintained for admini- strative purposes, in particular, the Vendor File and Financial Reporting 120 Journal of Library Automation Vol. 5/ 2 June, 1972 Files. Furthermore, the library could then produce its encumbrance data to be entered into the budget programs for the Business Office accounting records. From the standpoint of the library staff, it was believed that by utilizing the computer in acquisitions we could improve the overall staff utilization in the area. Probably the strongest point is that, while we did not expect clerical work time to be decreased, its nature would be changed. One specific function to be eliminated was the manual bookkeeping done, although a machine system would still require checking for accuracy. We expected that the acquisitions librarian, once freed from some routine responsibilities concerning the budget, would be able to devote that time to more professional activities. Other advantages in automating acquisitions were: more accurate and up-to-date information, especially in regard to budget figures would be available; human errors in sending out orders would be cut down; and statistics on orders could be compiled automatically. At this point, as well as previously, the literature was searched for relevant discussions of acquisitions systems and/or mechanization applications in small libraries. Relatively little had appeared in print describing library automation in junior colleges. Those articles found to be helpful included: Burgess, Cage, Corbin, Dobb, Dunlap, Macpherson, Morris, and Vagianos (see references 1-5 and 7-9). Also, Hayes and Becker's Handbook of Data Processing for Libraries ( 6) became available at this time. It was especially useful for the summary of features usually present within the scope of standard acquisitions applications. Along with use of the literature, several visits to other libraries with operational systems were made. A visit of particular importance was made in January ( 1971) to study an established off-line acquisitions system. As soon as there was general agreement on proceeding with plans for acquisitions, a list was prepared of the criteria the library staff would expect from the automation of acquisitions. The list items included: 1. The system should be open-ended, i.e., it should be planned with other potential future systems in mind. 2. It should handle the preparation of outgoing forms such as purchase orders, book-order cards, notifications to faculty requestors, and overdue notices to vendors. 3. The system should perform bookkeeping functions and provide many different access points for inquiry into the data base. 4. There must be a status list of items in the acquisitions process, up to and including the point of receiving cataloging. 5. It should have as much automatic editing of input data as possible. 6. The system must have flexible updating and file maintenance routines. 7. It should provide the library staff with decision-aiding information including many of our previously manually maintained statistics. Automation of Acquisitions/CARTER 121 8. It must be flexible. 9. It should maintain simplicity. And, 10. It should provide better service to the faculty through faster and more accurate ordering and notifications. Along with the criteria for an acquisitions system, a Possible Sequence of Automation Development was submitted. This was to provide a means for keeping clearly in mind that, while acquisitions would get first attention, this was only a starting point, and that the system should be planned in such a manner as to facilitate its compatibility with future developments. As originally stated, acquisitions, strictly speaking, represented Phase 1, and materials added to the collection were Phase 2. However, Phases 1 and 2 were planned and programmed at the same time. Thus, from the beginning, Parkland College has included in its system cataloging information such as the complete call number, and up to three subject headings of fifty charac- ters each. The decision regarding number and length of subject headings will be discussed later. (See master record layout at Figure 1.) TIME ESTIMATE-SCHEDULE In January, 1971, a proposed time estimate (see Figure 2) was submitted to the director of the Computer Center for his approval. This time estimate was prepared with the goal of automating acquisi- tions beginning with the fiscal year 1972 (i.e., July 1972). The proposed schedule also took into account the fact that most of the librarians were expected to be on vacation all (or at least most) of August, and also that during September, with the registration of students and other demands on the computer resulting from the beginning of a new academic year, com- puter time and personnel would be tight and probably could not provide the necessary support to a system still in its developmental stages. The schedule called for the librarian-analyst to begin full -time work on analysis on February 15 with final implementation of the system by the end of July. Preparation of this estimate was based on computer output if everything went right. It was an extremely rigorous schedule. Considering that problems did arise, the implementation of this system during the first week of August is truly notable. Of course, bugs remained after the system was actually in operation, and, as with all systems, changes were still being made several months later both in specifications for programming and in the programs conforming to the specifications. When the time estimate was submitted, it was also necessary to make firm decisions regarding personnel to perform all the necessary tasks. The librarian-analyst assumed responsibility for all systems analysis and program definitions. The library staff supplied the keypunching support. One clerk had been hired previously because of her keypunch training. On July 1, an additional clerk was hired with this skill. The main problem was program- TAP'E LAYOUT FOI'IM TAPE NO. I PREPARED BY: I REMARKS R. CARTER LIBRARY MASTER FILES: ON ORDER, I N PROCESS, ~!STORY NO , LENGTH, BLOCK : 400 x 9 IJi"i'l ·~ ~~·I I Ill I II II I I Ill I I j";'i" I ~ II Ill II I I II II I Ill I I~ ~j""t"l" I rJ,IIIIIIIIIIIIIIIII 'i'j"llllllllllllllj~ llll.~ k '"''''' "''""' '"· ' J l 1111111111111111111111111111111 1 111111111111111 F ~ositions 301-350 • Subject Hesding No. 2; 35 1-400 • Subject He &ding No. 3. Fig. 1. Master record layout. 1-' ~ 0' ~ !::l --a t'"' .... Cl"' ~ > ~ ...... 0 ~ ...... o· ;! < 0 ~ CJl ......._ l~ ._ c :l v(!) 1-' CD -l 1:-0 Automation of Acquisitions/CARTER 123 ming, because the Computer Center did not have the full-time personnel to support a major new effort. This was resolved by hiring a programmer on a special three-month contract running from April 15 to July 15, 1971. Prior to implementation, the library was forced to rely on the availability of keypunch machines at the Computer Center. In September 1971, an IBM Model 129 keypunch and verifier was installed in the Technical Services Department of the library. A Model 129 was chosen for the library in con- formance with the initial requirement set by the director of the Computer Center-that all library data for the computer be verified. This has proven to be a wise decision, as we have had relatively limited problems with invalid or erroneous data. REQUIREMENTS SPECIFICATION PHASE (ANALYSIS) Three weeks were allowed for identification and specification of all output desired from the initial system. Many of these requirements were alluded to in the preliminary list of criteria for the system. To meet the library's needs we decided that the system must produce: purchase orders, individual order cards (including a copy used to order catalog cards from the Library of Congress), budget statements including all encumbrances and payments as well as other financial data, lists of all books on order or in process or cancelled, notices to vendors regarding items on order more than 120 days, notices to each faculty member of the additions to the collection of items they requested complete with call number, and a monthly accession list of all newly cataloged items that could be circulated to all faculty members. Time Date to Date to Development Steps Required Start Complete I. Requirements specifications 3 weeks Feb. 15 March 5 II. Detailed design-System How 3 weeks March 8 March 26 Ill. Detailed design-Programming specifications 10 weeks March 29 June4 IV. Programming-Acquisitions 10 weeks April15 June 23 v. Programming-Materials accessioned 3 weeks June 24 July 14 VI. Computer Program System Test -Acquisitions & Materials Accessioned 2% weeks July 1 July 26 VII. Implementation July 1971 Fig. 2. Time estimate for automation of acquisitions at Parkland College as submitted in January 1971. A beginning and ending date for each phase is indicated and the actual time in weeks required is shown. 124 Journal of Library Automation Vol. 5/2 June, 1972 Once it was known what forms were required, orders were placed for the necessary pre-printed forms. With some outside advice in the matter of forms suppliers, specifications for three new forms were delineated, two of which would be for use on the computer. The first form encountered in outlining the acquisitions process was a request form. The request form is used to make a record of all items ordered and to serve as a checklist in the searching process (see Figure 3). Later, it is stamped with a six-position control number and serves as the source document for keypunching new orders, which require three input cards per item ordered. The request form is then retained in control-number sequence until the item has completed its way through the technical services process. Specifications for the purchase orders were drawn up by Parkland's business manager. The machine-generated purchase orders used by Park- land are almost identical to the conventional manual purchase orders used throughout the college. In this case, automation of the library's purchase orders is a likely precursor to automation of the purchase orders for the remainder of the college. The most complicated form to design, from the library's viewpoint, was the individual order form. This was required in five parts, including a copy complying with Library of Congress specifications for use with OCR equipment. (This is illustrated in Figure 4. ) PAPER PATO IY N.CJI. CO. SPEEOISET e MOORE BUSINESS FOAMS, INC., 26 SEARCHED IN BIP PBIP 8PR PTLA O. P, PIL FUND VENDOR FORMAT CODE AUTHOR (LAST NAME FIRST) TITLEfVOL. CARD CATALOG PUBLISHER OTHER YEAR NO. COPIES REVIEWED IN: SERIES/EDITION lCCARD NO. REQUESTER CONTROL NO. ORDER CODE PRICE SBN Fig. 3. Request form, used as a control record for each item ordered. -------r-------------------------------------------------------------------- I 0 0 0 0 0 I SUBSC RIBER NO I m I AlPHA PREF' I I 220111 I I I AUTHOR WESTHEIMER, DAVID TITLE LIGHTER THAN A FEATHE R PUBLISHER lITTLE DATE 1971 NO. COPIES l CONTROL NUMBER 103921-B ORDER DATE ·V ENDOR ll TTLE BROWN & co J L C CAR D NUMBER r 174 -15494 7 I I 10 I LIST PRICE I lo I ' w '; I r •· " ~ II 0 7.95 I 1-14-72 I L01375 I 0 p 0. NO . I PARKLAND COLLEGE LIBRARY I IO 11111111111111111 i 0 I A B c D E F G SBNI H I J K L M N 0 I I b_ -------i------------------------------- ----- ---------------------------------~---~-- . 01 1 o I I ------- ------- _L__ Original copy, used to order catalog cards rrom me Library of Congress. ---~----------- -- ---------------------,-- 0 i 1 r;:·-t,m7 ! o 0 [ AUTHoR·wesTH£JMeR, oAvio l ... o ... ee•o TITLE LIGHT fit THAN • FEATttfR I o-m 0 'O PUBLISHER ll TTLE DATE 1971 LIST PRICE 7. 95 0 0 0 0 . NO. COPIES 1 CONTROL NUMBER 10)921-6 ORDER DATE vENDoR LITTLE a·•towN a. to 1-14-72 P.o. NO. l01J7S PARKLAND COLLEGE LIBRARY CHAMPAIGN, ILLINOIS 61820 Second copy, used to send to vendor. Fig. 4. Copies one and two of the multiple-part order form . 0 0 0 126 Journal of Lib·rary Automation Vol. 5/2 June, 1972 It was important to determine forms requirements early, as it was anticipated that several months' time would elapse before they would be received. Naturally, it was desired that the forms be on hand by the time the programs would be ready for testing, which was planned for late June or early July. One of the most critical parts of the requirements specification phase was the determination of data elements to be included in the master records. Perhaps the most perplexing of those possibilities considered was subject headings. Since we wanted an open-ended system which would leave us some room for future development, without major modifications, a decision was made to include three 50-character subject headings in each record. Here we were limited because of the decision made (for purposes of sim- plicity of design and programming) to confine the system to fixed -length records. It was considered desirable for storage purposes to keep the master record length within 400 characters. While the decision on subject headings may prove to be adequate in the long run, it does give Parkland's library a good starting point for some projects using subject headings, such as developing bibliographies on demand. Despite possible future modifications to the data base, all items going into the History (Master) File included headings as defined above. Additional determinations made in the initial phase regarded files to be maintained. Here a crucial factor was the physical limitations of the college's computer system. As only two tape drives and two disk drives comprised the primary storage facilities, the capability for performing sorts was limited. In fact, one of the disk drives was reserved strictly for systems programs, and could not be utilized directly by the library. This contributed to the decision to maintain separate On-Order and In-Process Files, as well as a History File on tape. The college Vendor File and the Library Budget File are maintained on disk. A final area of effort in the initial phase was developing codes to be utilized throughout the system. Naturally, many conditions would be indi- cated in the computer records by the use of a one- or two-position code. One example is the Format Code, a one-position code, which indicates the types of items used such as: B=Book, R=Record, and S=Filmstrip. DESIGN PHASE-SYSTEM FLOW Three weeks were allotted to developing the overall systems flow chart. This time was spent working out each separate program that would be required, and flow-charting the entire series of programs. A flow chart of the system (without minor additions dating after September 1971) is shown in Figure 5. However, it does not necessarily indicate the sequence in which programs are run. In general, maintenance of each of the separate files is run prior to new data. This procedure has proved to work well. .-------~ : llfNOO• I : U'OAf( CA~O$ I ~ ----;--.! ... -- .. - -, I \WOAU I I VtlfOOII r· ~- :~~ - - ~ Automation of Acquisitions/ CARTER 127 o\UIOJHIUV ooooo c:~f6' Fig. 5. System flow chart. 128 Journal of Library Automation Vol. 5/ 2 June, 1972 In most cases, pre-sorting of card input is provided. This decision was not based on optimum efficiency but on the compatibility with routine pro- cedures and facilities in the Computer Center. DESIGN PHASE-PROGRAM SPECIFICATIONS One of the most significant parts of the development of Parkland's auto- mated library acquisitions system is the exhaustive documentation pro- vided by detailed written specifications for each program in the system. Each program, including utilities such as sorts, was assigned a job number and then described under each of the following topics: purpose, frequency, definitions (any unusual terms), input, output, and method. A format was provided for each input and output, whether it was a card, tape, disk, list, or other printed report or form. These accompanied each individual program specification. The Method Section is particularly important. Here the librarian-analyst stated the procedure used to arrive at the given output based on the given input. Any necessary constants were defined. Because the librarian-analyst has had programming training, these specifications are detailed to the point where the programmer does not have to do much more than code the prob- lem, making it possible for programming to proceed quickly. This thorough problem definition for each program by the librarian-analyst was one of the major factors (perhaps the primary key) in our success in acquisitions being accomplished rapidly and efficiently. It had the advantage of obviating the need for a senior programmer, or for having someone from the Computer Center become highly involved in the analysis of library details. Further- more, and perhaps most important is the fact that it provides the detailed documentation of the system. There should be no doubt as to the procedures within each program. An example of a specification for one of the programs in the Parkland College Library Acquisition Series is presented in the Appendix. It should be mentioned that most of the programs are written in COBOL. There are a few in Assembler, and some minimal use is made of RPG. TESTING OF THE PROGRAM The original plans called for testing with test data which would pro- ceed simultaneously with programming. However, as things developed, most coding was done prior to very much testing. As a result, the period originally devoted to live data testing of the whole system was instead devoted to testing the programs with test data. Thus, in early July, we were about two weeks behind the original time estimate, and that is where it ended up. The usual problems showed up in testing with test data. Moreover, during the first week of July, it was learned that the Business Office was changing the length of the Account Numbers from 9 to 11 positions. Fortunately, space had been planned for up to a 12-position field, so the lengthened number could be easily accommodated by the system. However, the chang- Automation of Acquisitions/CARTER 129 ing of numbers required modification of any program which edited data for valid account numbers. This was a minor problem and easily resolved. On July 15 the programmer completed the job for which he was hired- i.e., to complete a programming and systems test utilizing live data and to make appropriate changes as identified during testing. Since not even test- data testing was complete on July 15, he stayed until July 20 and finished that work. Meanwhile, the director of the Computer Center had already selected the individual to be the operator when the library's jobs were being run on a regular basis. This employee would also provide program maintenance. On July 21, this permanent staff member took over pro- gramming. For the next two weeks, while summer school classes were in session, most of the trial runs of the library series had to he done during evenings, nights, and on weekends. By the end of July, most of the major bugs appeared to be out of the programs. IMPACT ON TECHNICAL SERVICES Success on the first usable purchase order and order cards came on August 3. Within the next day or two, a workable budget statement was produced along with a WITS List (Work in Technical Services). By August 13, when the vacation time came, nearly one thousand books had been ordered via the automated system. While a few bugs remained to be dealt with in September, the system was accomplishing its basic mission essen- tially on time. It took less than eight months to identify requirements, and design, program, and test a system consisting of twenty-seven programs in its original design! During the remainder of 1971, various bugs were found, and, it is to be hoped, eliminated from the system. More bugs occurred in the budget series than in any other single segment of the system. Over a period of several months, these were worked out; as of March, 1972, the budget sequence of programs worked smoothly. IMPLEMENTATION Following the implementation of the automated technical services system, several effects were evident. An obvious effect was the saving of two to three days per month formerly spent on bookkeeping. On the other hand, one permanent staff member was added to Technical Services because of the keypunching workload. This addition had two causes: the keypunching load, and the fact that many more books were ordered directly from pub- lishers with a consequent major increase in processing in-house. Therefore, much of what was expended in salary for the extra clerk was saved by eliminating most prepaid processing costs. For several months after implementation, some duplication of effort was required, especially by acquisitions personnel. Thus, the total effect on changing the nature of work was not immediately obvious. By March 1972, duplication was essentially phased out, and more realistic assessments of the 130 Journal of Library Automation Vol. 5/2 June, 1972 impact of automation in changing the nature of the workload are now being made. One of the most obvious changes is the increased number of bills to be approved for payment. By utilizing the computer to batch purchase orders and order cards, almost all materials are now ordered directly from publishers, rather than pre-processed from a jobber. Although the speed by which items are received and processed has increased substantially, there has been a corresponding increase in paper work in this regard. ADDITIONAL SERVICES Besides the immediate effects of the automation of acquisitions within Technical Services, other parts of the library and the college felt the impact. This is especially true of reference, which now has a weekly updated listing of all items on order, in process, or cataloged within the last month, in both author /main entry and title sequence. Budget statements are now available to the Director of the Learning Resource Center and other personnel on a weekly rather than monthly basis. Not only are they received sooner, but they provide more information than is present in the statement originating from the Computer Center. A useful fringe benefit is the availability of overdue notices to vendors when items have heen on order more than 120 days. A computer-generated notice is sent each week to faculty members regarding items requested, cancelled, or cataloged. The response of the library staff and the rest of the faculty to the automated system has been very favorable. COST At this date (March 1972) , costs are difficult to assess, but certainly seem minimal. The only direct costs are the installation of a 129 keypunch, which rents for $170 per month, plus the salary of the extra staff member for keypunching. However, the extra salary is compensated for by no longer ordering items pre-processed at an average cost of $2.05 per item. Naturally, there is some local cost for processing materials such as pockets and labels, but it is minor on a per-volume basis. In addition, by being processed locally, materials are available to the users much more rapidly. Among other costs, the Learning Resource Center had to pay a three- month salary for a programmer. Other computer support, whether personnel or machine time, has not been directly billed to the library. Analyst time is absorbed, in part, in general library salaries as the librarian-analyst is also head ofTechnical Services and is responsible for original cataloging. About one-half of her time is devoted to automation activities. As an indirect cost of automation, it is reasonable to include the cost of a special summer project contract of about $1500 for the reference librarian to catalog A-V materials. This was necessary because the librarian-analyst was directly involved with automation, thus not able to keep up with all media of materials to be cataloged. Purchase-order forms previously covered by the Business Office budget cost the library $900. However, it was a two-year Automation of Acquisitions/CARTER 131 supply which was paid for by money the college, if not the library, would have expended anyway. The multiple-order forms for computer use exceed the cost of more standard forms by several hundred dollars per year. The library also expends about $400 per year to buy punch cards and magnetic tape. Some direct savings resulted from what are by-products of the automated system, but which were previously done manually. These include production of a monthly accession list and notices to faculty members of items they requested which were ordered, cancelled, or cataloged. The accession list was previously compiled by Xeroxing in ten copies the shelflist card for all items added to the collection during a month. This involved both Xerox charges and student assistant time. Notices to faculty were previously sent out by both the order and processing sections. Now these notices are consolidated, which produces savings in addressing time, as well as elim- inating manual production of each notice. Overall, in calculating costs and savings, direct and indirect, it appears at this point that Parkland has automated many library routines very inexpen- sively, although specific cost figures remain to be determined. With the availability of a similar computer, many other libraries should be able to undertake automation of certain basic functions without large expenditures of either money or personnel time. PROBLEMS As with all automated efforts, some problems were encountered at almost every stage of development. Taken as a whole, these were minor and, for the most part, few hitches were encountered. However, so that others may profit from the library automation experience at Parkland, those problems will be discussed. The major problem was the original programmer of the series. This person was not a regular employee of Parkland and was not concerned with being retained. Since he was not part of the staff, he worked erratically and frequently was hard to get hold of. We were working on a tight time schedule, and it was very important to maintain close supervision of the progress being made, although sometimes this was difficult. In addition, even though it was strongly desired that tests be conducted throughout the three-month period, the programmer waited until all coding and compiling was completed before beginning even test-data testing with most programs. Fortunately, it worked out satisfactorily, as the regular staff member of the Computer Center, who presently runs our jobs and does program mainten- ance, took over in mid-July and was available for live-data tests. All staff members directly involved with automation worked very hard the last two weeks of July and the first week of August to complete testing with live data. The programs were further refined during August and September, and most of the bugs were out by early fall . Naturally, changes in specifications continued to be made, and our acquisitions system is definitely not static. 132 journal of Library Automation Vol. 5/ 2 June, 1972 The lesson we learned from the experience with the initial programmer is that, if a regular staff member of the institution can be assigned to the development of programs for the library, avoiding other assignments during that time period, a more satisfactory response can be achieved from the programmer. Also, in such an operation it would be possible to monitor progress on a more regular basis. Another group of problems arose in connection with the new forms required for the automated system. Fortunately, these were not serious. The forms arrived later than they were promised, and, without exception, their cost was about 25 percent more than the original estimates. Because custom forms can take a long time to be completed, it is wise to identify output requirements ·early in the development of an automated system, so that the forms can be completed and delivered when the system is ready for final testing and implementation. A few minor problems revolved around decisions made in file design. For conserving space and holding down the size of the master record, it was decided to pack numerical fields. This would have been satisfactory if packing had been limited to such fields as the Julian date, such as 72001 rather than 01-01-72. (This form of the date was used to provide easy computation when calculating overdue orders. ) Unfortunately, fields such as the numerical part of the LC card number and the Parkland College account numbers were also packed. No problem existed except when the LC card was blank at order time; then the LC number printed as zeros. Of course, these could be suppressed once the problem was identified, although it was decided to make space to unpack the field. It was learned that packed fields always print zero when unpacked, unless this is specifically suppressed, and also that it is impossible to debug packed fields on routine file dumps that are requested with provisions for unpacking and reformat- ting the dump. This is because packed fields print blank when they are dumped. Other minor difficulties included: l. The print chain did not print colons or semi-colons, except as zero, therefore, the library's records all contain commas instead. 2. In the midst of programming the account numbers , all the college's funds were changed, thus requiring the change of constants and edit criteria in many programs. 3. As originally specified for input, the LC classification number did not sort in shelf list order, for instance, BF 8 sorted after BF 21. This was eventually remedied by left-justifying the letters and right-justifying the numbers within separate fixed fields. 4. Routine delays for machine repair and maintenance were a concern, since it is necessary to adhere to a tight schedule in systems develop- ment. Automation of Acquisitions/CARTER 133 FUTURE DEVELOPMENT As is so frequently the case, now that Parkland is committed to automated functions within the library, more and more applications are seen. Even the former skeptics on the staff are enthusiastic, and all the professionals have made suggestions for the future. Several additions to the acquisitions system were made in the first six months following implementation of the system. These included a list of purchase orders sequenced by vendor and enlarging the machine-generated notices to faculty requestors to cover items ordered and cancelled. Various additions have been made in several programs originally part of the system, which expand the services the system can provide for the library staff. Many more minor modifications and supplementary features in acquisitions have been identified for inclusion in the system, and will be added as time permits. The first additional area to benefit directly by the computer availability has been periodicals. Without involving complicated programming, the periodicals holdings have been converted to a card file which is then listed directly, card by card, without changes, except for suppression of a control and sequence number. Nothing more is planned for periodicals in the near future, because the new card file enables the master holdings list of 800 titles to be updated in Technical Services by the periodicals assistant, who also keypunches one-half time. The time-consuming retyping of the holdings list is now eliminated, and multiple copies of up-to-date holdings lists can be produced more frequently with less effort. Another new area for which programming specifications were released in December 1971 is reference. In this system it is hoped that subject bibli- ographies and holdings lists, based on Library of Congress classification, can be produced. This system will have a multitude of purposes, one of the primary ones being to give better service to our faculty members. We get many requests for copies of portions of our shelflist or other extracts of holdings. Rather than filling these requests by Xeroxing cards or tedious typing, a few extract specifications will permit computerized retrieval and printing. Also, search time in the catalog will be cut down considerably. In the subject bibliographies, the library plans to be able to extract on any heading, stem of a heading, or any part of a heading, thus getting much more flexibility than in manual use of the card catalog. Programming for this is currently under way, and after the system has been completed and is operational, some interesting results should be identified. By including three subject headings of fifty characters in our original file design, it was possible to design and program the reference series as a spin-off of the acquisitions- technical services system with a minimum of additional effort. Even if it is eventually decided to lengthen either the number or size of the subject headings contained in Parkland's file, useful services will have been provided under the original design, as well as simply having provided a base for further decisions and developments. 134 Journal of Library Automation Vol. 5/2 June, 1972 Other projects which are being considered for future action are serials holdings (in Parkland's case, mostly annuals and yearbooks which get cataloged), including an anticipation list, and management statistics con- sisting of holdings percentages by class letter versus collection additions and circulation figures by class letter. Circulation itself will undoubtedly not be designed prior to actual residence on the permanent campus ( anticipated for fall 1973), but all of the above are possibilities and some will receive attention in the immediate future. By building a data base which includes subject headings and call numbers, many future projects will be practical to consider as the file maintenance programs and the data base will already exist. These, of course, may be modified from time to time to meet changing conditions and requirements. Additionally, Parkland's library staff has been following cooperative library automation efforts involving other libraries, and would happily consider participation in appropriate cooperative ventures. CONCLUSION In the opinion of both the library and computer staff, the automation of acquisitions is a success. It was accomplished rapidly and essentially on time and economically-with few costs higher than originally anticipated. Now that the system is operating smoothly, with only an occasional bug cropping up, the extra workload caused by parallel operations has been phased out and the total efficiency of the system should continue to improve. The system to date has been running on a weekly basis, and this has proved satisfactory to both the Computer Center personnel and the library. The library is among the first parts of Parkland to be on a regular weekly schedule using the computer. Most other processing is on a monthly and quarterly cycle. In approaching any automated systems development, a general attitude of flexibility combined with thoroughness is very important and will prob- ably bring the best long-term results. By being flexible and open-ended, regardless of what portion of a library's functions were originally auto- mated, the way will be paved to provide a data nucleus for other applica- tions in areas of the library. Thoroughness in design and attention to initial detail are also important, as sometimes it is harder to find the time to make the changes than was expected. There is probably a tendency to get along with an operational system as it is, rather than making minor non-crucial modifications in it, although such changes do get worked in as time permits. Nonetheless, it is very important that in the initial stages a system be as comprehensively planned as feasible. The Parkland College Learning Re- source Center is fortunate in that original specifications (on the whole) were well thought out and provided a cohesive unit, which is also characterized by built-in flexibility, and as a result is adaptable to future growth. Automation of Acquisitions/CARTER 135 ACKNOWLEDGMENTS Numerous individuals have participated in and supported library auto- mation efforts at Parkland College. David L. Johnson, director of the Learning Resource Center provided the initial inspiration and determina- tion. Robert 0. Carr, director of the Computer Center, welcomed the library's commitment to automation and provided the technical advice where necessary. Sandra Lee Meyer, acquisitions librarian, gave full cooper- ation, including tireless aid in clarification of requirements and debugging test results. Since late July 1971, Bill Abraham has been the programmer- operator for the library system and has consistently given more than one hundred percent effort. Jim Whitehead from Western Illinois University contributed valuable advice based on his prior experience in acquisitions automation. Finally, Kathryn Luther Henderson, an inspirational teacher and friend, voluntarily spent many hours writing test data and offering the opportunity for many fruitful discussions. REFERENCES 1. Thomas K. Burgess, "Criteria for Design of an On-line Acquisitions System at Washington State University Library," In Proceedings of the 1969 Clinic on Library Applications of Data Processing, edited by Dewey E. Carroll (Urbana: University of Illinois, Graduate School of Library Science, 1970), p. 50-66. 2. Alvin C. Cage, "Data Processing Applications for Acquisitions at the Texas Southern University Library," In Proceedings, Texas Confe1·ence on Library Automation, 1969 (Houston: Texas Library Association, Acquisitions Round Table, 1969), p. 35-57. 3. John B. Corbin, "The District and Its Libraries-Tarrant County Junior College District, Fort Worth, Texas," In Proceedings of the 1969 Clinic on Library Applications of Data Processing, edited by Dewey E. Carroll (Urbana: University of Illinois, Graduate School of Library Science, 1970), p. 114-34. 4. T. C. Dobb, "Administration and Organization of Data Processing for the Library as Viewed from the Computing Centre," In Proceedings of the 1969 Clinic on Library Applications of Data Processing, edited by Dewey E. Carroll (Urbana: University of Illinois, Graduate School of Library Science, 1970), p. 75-80. 5. Connie Dunlap, "Automated Acquisitions Procedures at the University of Michigan Library," Library Resources & Technical Se rvices 11: 192- 202 (Spring 1967). 136 journal of Library Automation Vol. 5 / 2 Jun e , 1972 6. Robert M . Hayes and Joseph Becker, Handbook of Data Processing for Libraries (New York: Wiley-Becker and Hayes, 1970). 7. John F. Macpherson, "Automated Acquisition at the University of Western Ontario," In Automation in Libraries. Papers presented at the C.A.C.U.L. Workshop on Library Automation at the University of British Columbia, Vancouver, April 10-12, 1967 (Ottawa, Ontario: Canadian Library Association, 1967). 8. Ned C. Morris, "Computer-Based Acquisitions System at Texas A & T University," Journal of Library Automation 1 :1-12 (March 1968 ). 9. Louis Vagianos, "Acquisitions: Policies, Procedures, and Problems," In Automation in Libraries. Papers presented at the C.A.C.U.L. Workshop on Library Automation at the University of British Columbia, Van- couver, April 10-12, 1967 (Ottawa, Ontario: Canadian Library Associ a- tion , 1967 ), p. 1-9.