lib-MOCS-KMC364-20131012113301 202 Journal of Library Automation Vol. 14/3 September 1981 RLIN system scheduled to be operational this summer. The proposed test will involve eight members of the reference staff- four from each department- who will be trained to search on OCLC and RLIN. Those selected will include both librarians and library assistants who regularly pro- vide reference assistance. The results ob- tained from such a representative group will better enable us to assess the impact on the whole reference staff should we later decide to fully implement the service. They will be the only ones involved in sampling questions and conducting comparative searches. The test will have two components, the first of which will be a twenty-week period to collect at least 400 sample questions. During their regularly scheduled reference hours, the eight specially trained librarians 'will collect samples of reference requests for materials that, based on the information initially given by the patron, cannot be identified in the card catalog. After check- ing the catalog, the librarian will then com- plete the top portion of a two-page self- carbon form with all of the information that is known about the requested item. Then, at regular intervals during the semes- ter, the pages of each form will be separated and distributed to other members of the test staff for batch-mode searching. The man- ual OCLC and RLIN searching for each query will be done by different staff mem- bers to eliminate crossover effects. Each re- quest will be searched on both OCLC and RLIN with the following information being recorded: 1. Date of the material requested (if known). 2. Type of material (e.g. , conference proceeding) . 3. Amount of time required to do the search. 4. Success or failure of the search. This information will then be cumulated in a statistical table, and the results of each search will be keypunched for computer- ized analysis using the BMDP (BioMedical Computer Programs) statistical package to determine whether or not effectiveness and efficiency have been improved signifi- cantly. In addition , on twenty-four randomly se- lected days during the semester the trained searchers will count the total number of questions received by them on that day that would have been appropriate to search on RLIN or OCLC. By using these data it will be possible to extrapolate the potential use- fulness of the systems for the entire semes- ter. The second component of the test will be a two-week real-life test during which all questions requiring further verification would be searched immediately on RLIN, OCLC, and in the appropriate printed sources to compare time required, success rate, and type of material requested. This sort of test would permit the searcher to continue to negotiate with the patron as the search progressed, which is the usual situa- tion. Also, this would provide the only op- portunity to have the patron judge the value of subject searches done on RLIN. If funding is received, preliminary results should be available in early 1982. Anyone conducting similar or otherwise relevant studies is asked to contact the author. Replicating the Washington Library Network Computer System Software Thomas P. BROWN: Manager of Computer Services, and Raymond DeB USE: Manager of Development and Library Services, Wash- ington Library Network, Olympia. The Washington Library Network (WLN) Computer System supports shared cataloging and catalog maintenance, retro- spective conversion, reference, COM cata- log production, acquisitions, and account- ing functions for libraries operating within a network. The system offers both full MARC and brief catalog records as well as linked authority control for all traced head- ings. It contains more than 250,000 lines of PLI 1 and IBM BAL code in more than 1,100 program modules and runs on IBM or IBM-compatible hardware with IBM oper- ating systems (MVS ,OS/VSl). All database management functions are provided by ADA:BAS, a product of Software A.G. of North America. The online system runs un- der CICS/VS 1.5. A set of assembler codes called the TP Monitor Interface defines a standard service interface between the ap- plications programs and the TP monitor. This allows easy upgrade to different TP monitors and convenient points for collect- ing performance statistics. The majority of the Bibliographic Sub- system updating is done in batch mode to conserve online resources. A new version of the system with interactive updating is cur- rently being planned, for use in special en- vironments. The applications software was designed and implemented with a number of impor- tant conventions: 1. Top-down design. 2. Standard use of IBM environments. 3. Structured coding techniques. 4. Interfaces to a database management system (ADABAS) and teleprocessing monitor (currently CICS). 5. Stand;ud naming and formatting. 6. Use of a standard set of data structures and assembler subroutines to manipu- late data. 7. Identification of maintenance changes in source programs. In addition, programming for the online functions meets other conditions: 1. Load modules less than 20K bytes. 2. No PL/1 run-time subroutines. 3. Reentrant coding. 4. Standard services for the TP Monitor Interface. 5. Applications are kept as terminal in- dependent a~ possible, with the TP Monitor Interface performing input and output translations. REPLICATION A system with these characteristics, even though large, can easily be transported to a different site. While WLN was not designed with multiple replications in mind, a policy decision made by the network a few years ago made replication an attractive possibil- ity. Recognizing that it had a capability that would be highly competitive with other online shared bibliographic services, WLN expanded its service area beyond the state of Washington. It set limits to its ex- pansion, however, having determined that it would remain a small, responsive organi- Communications 203 zation providing what it hoped would be superior service to its participating li- braries. Having set such limits, however, created two impediments to its achieving superior service: WLN would have a smaller base of libraries from which its par- ticipants could obtain the benefits of shared cataloging, and there would not be the fis- cal resources necessary to support a large continuing development effort. Both would penalize libraries for joining WLN, the first with a lower hit rate against the database and the second with fewer added capabili- ties. Replication provided a possible answer to both of these problems, as well as a po- tential source of income. In its software li- cense agreements, WLN asks the licensee to agree to bibliographic data sharing. All cat- aloging done by a licensee or its participants would thus be available for loading on WLN's own database; likewise, all WLN participant cataloging will be made avail- able to the licensee. WLN, at least, would accept catalog records only from libraries that follow its bibliographic standards; that is, the standards of the Library of Congress. Currently this sharing is accomplished via magnetic tape, but in the future, online rec- ord interchange may be possible, given WLN's current work in this area. WLN also explicitly asks in its software license agreements that the replicating in- stitution carry out an organized program of development to meet the latter's particular needs. Such development is monitored by WLN in order that redundant work is not undertaken and to ensure that the various efforts relate coherently. There is a built-in constraint upon major modification andre- design: WLN is packaging enhancements and changes into periodic releases of the source code and requiring that the repli- cants install these releases within twelve months of the date issued. Because of the interest in shared develop- ment and because WLN itself is not in a position to provide first-level program maintenance, the system is distributed in source-code form. The initial installation, however, is of load modules (programs in a form efficiently read and executed by ma- chine), allowing immediate testing of the system's capabilities in its new environ- 204 Journal of Library Automation Vol. 14/3 September 1981 ment. WLN is currently negotiating a con- tract with a new firm, Biblio-Techniques, that will offer a more nearly turnkey ver- sion of WLN, packaged with ADABAS and Software A.G.'s TP monitor, COM- PLETE, and, if necessary, with the re- quired hardware. NATIONAL LffiRARY OF AUSTRALIA The first replication of the system was made at the National Library of Australia (NLA) in Cranberra in early 1979. NLA had its own IBM 370/148 and an established data processing staff. ADABAS had been installed prior to the arrival of WLN's in- stallation consultant. Minor changes are necessary in CICS to support dedicated WLN terminals, and these were quickly made and the system was up within days. Further work allowed searching on the sys- tem from the library's 3270 terminals. After a couple of weeks of shakedown, a WLN staff member spent about two weeks train- ing NLA staff in the use of the system. It has been in full production for in-house produc- tion cataloging for more than a year now, and this spring is being extended to other libraries around the country on a pilot basis, testing the concept of the newly de- fined Australian Bibliographic Network (ABN). NLA has replaced the 370/l48 with a larger machine. UNIVERSITY OF ILLINOIS The second installation occurred earlier this year at the University of Illinois, where the system was obtained to carry out a pilot project in which the Urbana campus and the River Bend Library System will use it as an online public-access catalog in conjunc- tion with the LCS circulation system. Again, load modules were installed and the system was up within a few days, running on the University's administrative com- puter at the Chicago Circle campus. Illinois staff have had some difficulties in recompil- ing all of the source code, but these prob- lems are being worked out. WLN will war- rant that the source code supplied corresponds to the load modules it installs. The system as presently distributed by WLN can in no way be considered turnkey. Local computer operations or JCL require- ments as well as differing levels of staff ex- pertise can create problems. Furthermore, WLN handles source management through WYLBUR, a text-editing system, and this is not included with the WLN software. The module descriptions, grogramming lan- guage, mode, link-edit information, etc., maintained through this facility are sup- plied, however. Either a test or, if con- tracted for, a full database is also supplied. WLN has had some difficulties in creating a valid test database for Illinois, but has now defined procedures to better control the process. WLN has distributed its second release to Australia as a full source update identical to what was installed at Illinois. In the future only the source changes in standard IBM IEBUPDTE form will be supplied to repli- cation sites. This will better enable these sites to integrate the new version into theirs. OTHER SITES The University of Missouri is likely to be the third replicant of the system, since it has just selected WLN as the basis for its online catalog system . Installation is planned be- fore the end of 1981. The National Library of New Zealand has also indicated that it intends to purchase the system. The South- eastern Library Network (SOLINET) has obtained the system in order to convert it to a Burroughs facility. While this is a soft- ware license, it is not a replication. There- sulting system, however, would be avail- able from WLN for installation on Burroughs equipment. WLN has not implemented data sharing with Australia, but is testing the loading of Illinois data into its bibliographic file. WLN libraries should see Illinois records on a regular basis by late summer of 1981. Sim- ilar arrangements will be made with Mis- souri and SOLINET. Shared development has gotten off to a start with the National Library of Australia having done the work necessary to add the IBM 3270 type of terminal to those that can support cataloging input and edit on WLN. Illinois will be undertaking the develop- ment of enhancements to make the system easier to use as a public online catalog, in addition to other possible areas of concern. WLN, of course, continues its in-house de- velopment, which has recently seen the im- plementation of a new batch retrospective- conversion subsystem, and added COM catalog options and online authority verifi- cation during input/edit. While not the only bibliographic system to be successfully replicated, the WLN Computer System is becoming the most sys- tematically replicated main-frame facility, with a broad range of future possibilities, including that of a truly turnkey system. WLN's experience indicates that, if a sys- tem is designed for ease of maintenance at perhaps some sacrifice of efficiency, it will be readily transportable and allow others to obtain the benefits of a highly sophisticated bibliographic capability without the ever- increasing cost of original development and, more importantly, without having to support the ongoing maintenance of a unique system. A General Planning Methodology for Automation Richard W. MEYER, Beth Ann REULAND, Francisco M. DIAZ, and Frances COL- BURN: Clemson University, Clemson, South Carolina. INTRODUCTION A workable planning methodology is the logical starting place for the successful im- plementation of automation in libraries. An automation plan may develop on the basis of an informal arrangement or from the ef- forts of one individual, but just as often, automation plans are developed by com- mittees. An automation planning commit- tee must determine and execute some kind of planning methodology and is more likely to be successful if it starts with clear guide- lines, good leadership, and a thoroughly proven approach. As a summary review of the literature will bear out, many libraries have devel- oped their own planning techniques in- house. Some of these, which are addressed to the issues of cataloging rule changes and public-access catalogs, have been very well thought out. 1 However, these techniques are generally not directed to planning for Communications 205 library-wide automation, and are usually designed to meet the specific needs of an individual library. Although the pattern for these studies is often similar, they do not seem to be based upon any general automa- tion design methodology. Neither, in addi- tion, does there seem to be a general meth- odology available through any external library agency. The Office of Library Man- agement Studies of the Association of Re- search Libraries has developed a number of programs designed to assist libraries with their planning efforts, some of which ap- pear to be useful in automation devel- opment. 2 But for many libraries, these pro- grams may be too broad, too time-consuming or too expensive. As an al- ternative, some libraries will need to look elsewhere for a general automation plan- ning methodology. This problem was ad- dressed by the administration of the Clem- son library, and was resolved in a unique way. BACKGROUND The Robert Muldrow Cooper Library of Clemson University has the responsibility of acquiring, preserving, and making avail- able for use the many materials needed by faculty and students in their research and instructional efforts. At a typical land- grant institution like Clemson, the amount of scholarly publishing and the pressure to develop research proposals has risen sharply in recent years. The increased needs of users working with an expanding and diversified collection have resulted in a doubling of cir- culation activity, and have required the growth of library staff by 70 percent over the last decade. Furthermore, acquisition, processing, and access problems are com- pounded by the high inflation rate of mate- rials, particularly serial publications, and manpower costs. Even though user demands heavily bur- dened the traditional manual systems, the extent of library automation at Clemson had been limited to a batch circulation sys- tem, a simple serials-listing capability, and the use of bibliographic utilities. Although it had been generally accepted for some time that the acquisitions and fund-control functions at Clemson were in need of auto- mation, no concrete approach to develop-