lib-MOCS-KMC364-20140103101924 13 SHAWNEE MISSION'S ON-LINE CATALOGING SYSTEM Ellen Washy MILLER: Library Systems Analyst, and B. J. HODGES: Senior Systems Analyst, Shawnee Mission Public Schools, Shawnee Mission, Kansas An on-line cataloging pilot project for two elementary schools is discussed. The system components are 27 40 terminals, upper-lower-case input, IBM's FASTER generalized software packo.ge, and usual cards/labels output. Reasons for choosing FASTER, software and hardware features, operating procedures, system performance and costs are detailed. Future expansion to cataloging 100,000 annual K-12 acquisitions, on-line circulation, retro- spective conversion, and union book catalogs is set forth. INTRODUCTION The Shawnee Mission Public Schools, serving several affiuent suburbs of the Kansas City metropolitan area, began automated library operations in 1968. As the school districfs Computer Center was then equipped with a 1401 computer and tape/disk store, the first library system was designed for batch ordering and cataloging. Later, a batch circulation system for three of the school district's fourteen secondary libraries was started. Library automation in that period was similar to that described by Scott (1) and Auld (2). Two years saw a profound change in the Shawnee Mission School Dis- trict. By unification, it had added 50 elementary schools and a new high school, makin9 a total of 65 schools, all of which had libraries. At the school districts Computer Center, the configuration had passed through the 360/30 stage to a 360/40; 2314 disk packs were on order; and 2741 term~als, using IBM's Remote Access Computational System (RAX) had been ~stalled at all five high schools for computer science courses. Wlule the batch library system could handle the 28.000 items ordered 14 Journal of Library Automation Vol. 4/1 March, 1971 and cataloged annually up to that point, it was impossible to justify using it for an estimated 100,000 annual acquisitions needed by 65 libraries. Computer time to process AUTOCODER programs on a mod/40 would be excessive; the librarians desired many improvements (upper- and lower- case I/0; longer fields; shortened time to process items; and more accurate data on cards and labels) . The need for data processing and library improvements resulted in rethinking of the approach to ordering, cataloging, and circulation. Natur- ally, on-line processing came to mind. IBM 274fs for computer science courses had given management and data processing staff some experience with a dedicated on-line system; the 360/40 and 2314 disks would support large files, indexed sequential file organization, and multiprogramming (simultaneous use of the CPU for terminal and batch jobs). The experiences of Stanford and University of Chicago ( 3) and IBM ( 4) pointed out that on-line systems could be built for larger and more complex organizations than for Shawnee Mission, where the collections are 95% English language and the system covers only books and audio-visual items. Cataloging is based on title-page information; tools used are Children·s Catalog, Sears, N.U.C., A. A. Rules, and other standard works. Also very important was the fact that the Computer Center management wanted experience in multiprogramming prior to considering it for student scheduling, student records, payroll and business functions. A proposal was made to library and data processing management by the Library Systems Analyst in mid-December 1969 that on-line cataloging in multiprogramming mode be begun by mid-March 1970 for two elementary schools on a test basis. An improved batch order system using COBOL programs was also proposed. Finally, it was suggested that a carefully designed cataloging system could include fields to be used later for circulation control. The specific purposes of the on-line cataloging pilot project were 1) to test whether direct access to master disk files is an efficient, accurate, and economical method of creating and updating bibliographic and holdings data; and 2) to allow data processing management to ascertain if multi- programming is feasible and practical at this time locally. A search of library literature revealed no on-line systems for cataloging and circulation functions; rather, either circulation or order functions were real time. Moreover, truly on-line systems were rare; Columbia had de- signed a circulation system that could be used in that mode, but as of October 1968, was operating batch (5). Chicago's Book Processing System does input data on line, although ordering and cataloging functions are performed off-line (6) . BELLREL is an on-line circulation system (7). Comparing the circumstances of the above institutions with that of Shawnee Mission School District brought out one sterling difference: the latter had no yant money nor huge parent institution upon which to rely. Rather, it ha a modest hardware-software configuration, a need to be On-Line Cataloging System/ MILLER and HODGES 15 operational within three months if the two test librarians were to see any output by the end of the school year, and a small team of data processors and librarians devoted to redesign and implementation. METHODS AND MATERIALS Having earlier seen demonstrations of the Kansas City, Missouri, Police Department's FASTER system, with its on-line access to constantly updated alphanumeric files, the senior systems analysts turned to IBM for further information. The police department's system was based on a software package developed in Alameda, California, for law enforcement. It was also available in a general form called FASTER (Filing and Source Data Entry Techniques for Easier Retrieval). The proven ability of this system to accept on-line data via 2740 terminals and to display it on 2260 CRT's, its ease of adaptation to user requirements, the quickness with which analysts and programmers had learned to use it at the police department, and a local, positive experience decided the issue. In mid-January 1970, FASTER was chosen as the software framework for on-line cataloging. Software FASTER has been programmed in modular form, with each module performing a particular task ( 8). Modules supporting functions that vary because of hardware must be coded by the user. This coding is done in macro form (brief program statements in higher level language which generate many machine instructions) and therefore is not a tedious task. One of the hardest, most complicated portions of implementing a tele- processing system is programming the support from the CPU to the terminal; with FASTER, this took about a day. The macros use Basic Teleprocessing Access Method (BTAM) support. With line support taking little time, the user may spend more effort on his own processing needs. The user may have only a query or an update requirement; Shawnee Mission needed both. Because FASTER is a modular system, the user is permitted to describe each of his needs as a transaction. This transaction must be programmed as a TPD (Transaction Processing D~scription) using macros. Coding and listing time for a TPD will vary w1th the processing description. Those familiar with detailed programming will note that the programmer does not have to concern himself with 1/0. The TPD will prepare the data for output, and the FASTER interface module will handle 1/0. Some of the major functions supported by the macro language include: 1) Retrieval of records from indexed sequential ( ISAM ) files-files accessed only through hierarchic indexes; 2) modifications and additions to ISAM IDes; 3) data manipulation; 4) formatting of responses to selected terminals; 5) message switching and 6) recording audit data on a logging file. FASTER under DOS requires fixed-length records; this has been modified under the OS version. 16 Journal of Library Automation Vol. 4/1 March, 1971 Retrieval from the !SAM files required for processing a given transaction may be performed in one of three ways: 1) retrieval of a unique record, 2) sequential retrieval of a specified number of records from a logical grouping, or 3) retrieval of a specified number of records from a logical grouping, in which the retrieval records represent the best qualified from the group based upon the user's selection criteria. Hardware Hardware supported by the FASTER system is as follows: Machine configuration: IBM 360 mod/30, 40, or 50 Storage requirements: Minimum-DOS 65K; minimum-OS 128K Disks supported: 2311 or 2314 Logging file: Disk or tape Line control: BTAM witb 2701, 2702, or 2703 Terminals: 2740, 1050, 2260 CRT Systems at Shawnee Mission Computer Center: IBM 360/40 DOS 256 K Eight 2314 disks Three 2401 tape drives One 2702 line control 27 40 and 27 41 terminals The system operates in three partitions. Partition F1 houses APL (A Programming Language) for student use with 27 41 terminals. Partition F2 houses FASTER. Partition BG is used for batch jobs (both COBOL and AUTOCODER under CS monitor). File organization and access FASTER supports !SAM files only (as data sets) with the exception of the logging file; the logging device must be sequential. FASTER's support of disk files is accomplished by using the same software modules that AL and COBOL use in maintaining !SAM files. Therefore, standard pro- gramming languages may be used for creating files and data retrieval. Shawnee Mission chose COBOL as its main fanguage and found it to complement the FASTER system. Files The batch library system was based on a 400-character record, repeated in its entirety for every copy in each library. This space consumption for redundant information was undesirable in a system with 65 collections, and therefore two basic files were designed. The first is the disk title file, containing one record with bibliographic information for each unique title in the school district. Its fields include author, title, dates, subject headings, annotation, etc. (Table 1). Each record is 562 characters long. On-Line Cataloging System/MILLER and HODGES 17 Table 1. Main Fields Input by Operators Record Title Copy Field Form code Publication date Copyright date Author Title Annotation Publisher Edition Price Dewey number Cutter number Grade level Collation Series Language code LC card number Subject heading 1 Subject heading 2 Subject heading 3 Added entry Title number Number of copies Building code Funding code Volume number Print instructions Length 2 4 4 35 50 105 30 3 5 8 10 4 40 35 3 14 24 46 60 30 7 4 5 Comments Distinguishes physical format May be continued in Annotation Use MARC language codes Use Sears headings " , , , , For name or title 2 If other than general funds 3 For volume or other sequence number 16 Kept only until labels and cards printed In distinction, the disk copy file contains a 56-character record for each copy of a title, comprised of fixed-length fields for building number, special funding, volume information, and circulation control. Copy and title records are linked through the title number. The third file is the ISAM title index, comprised of records with a phon.etic code and key for each title record. This file is called up by a t~rnu~al transaction containing title; the incoming phonetic code for the htle ~~ matched with any equal ones on the index. For matches, biblio- ~rap~tc data is pulled from the title and typed on the terminal. The main unction of the title index is to determine duplicates. 18 Journal of Library Automation Vol. 4/1 March, 1971 Tests on 45,711 title records showed that a 16-character phonetic code resulted in a maximum of 36 different titles having the same phonetic code. The 16-character code chosen consists of the first character of title followed by numeric values for most consonants. The On-Line Cataloging System Input Recognizing that the pilot project might be expanded into a full-scale operation, librarians drew up procedures for entering data from either shelf list cards or new arrivals. Conversion from shelf lists required that cards be edited to eliminate confusing information and to add implicit data. For new acquisitions, most information needed by the terminal operator is annotated on the title page and its verso. A grid sheet to be slipped into the book contains subject headings, added entry, annotation and some other fields. All of these practices were set forth in a user's manual (9), along with instructions on how to enter transactions into the disk files. Limits on the input buffer permit a maximum of 120 characters to be transmitted by any transaction, which means that several transactions are required to add all cataloging and location data necessary to describe a new title. There are two sets of transactions. The LT series adds to and updates records in the title file; the LC series does the same for the copy file. For instance, entering a new title requires an LT01 transaction to start the record and assign a title number, one or more LT02's to complete catalog- ing data, and an LC01 for building assignment. Operators find transactions easy to key and understand. By category, LC and LT transactions set up new records, add on fields, update fields, delete or activate records, and query the contents of a specified record. These transactions are a simple, understandable, and powerful method of maintaining library files. Several transactions also add data to fields, thus saving the operator keying time. For instance, the Cutter number is automatically derived from the first three letters of the author's last name, unless specifically superseded by the operator. Also, "F" is assigned to Dewey for all items unless replaced by another classification. Finally, a standard set of output, consisting of 1) two author cards, overprinted cards, a copy card, and 2) one three-up label, is assumed when an LC01 transaction is input to show location. If other outputs are needed, the operator uses an LC05 transaction to specify them. There are also several instances of data being input in lower case (to save time and buffer space for a shift) and being edited on output to upper case. The result of all these program aids is that the operator knows she is keying only important data; highly invariable fields are input and edited by the FASTER programs, saving operator time. On-Line Cataloging System/ MILLER and HODGES 19 Output Two basic card formats were chosen. The unit card contains all catalog- ing information; the copy card shows a library's holdings of a given title (Figures 1 and 2) . A unit card and copy card (giving all cataloging and holdings information) go into the school's shell list; the usual set of main and added entry unit cards goes into the public catalog. Gunthf'r , J()lln hlr the Gr