261 MARC II AND COBOL Henriette D. AVRAM and Julius R. DROZ: Information Systems Office, Library of Congress, Washington, D. C. A description of the machine processing of MARC II records using COBOL for an application on the Library of Congress System 360/ 30. Em- phasis is on the manipulation by COBOL of highly complex variable length MARC records containing variable length fields. Since the implementation of the MARC II format by the Library of Congress for the MARC Distribution Service, some potential users of ma- chine readable data have expressed doubts that MARC formatted records could be effectively manipulated by programs in the COBOL language. Griffin ( 1) expressed his concern by stating, "Users will r~quire program- mers skilled in languages other than FORTRAN or COBOL to take ad- vantage of MARC records." During the design phases of the MARC II format, the Information Systems Office staff concluded that the capability of COBOL should be accommodated. The relationship between the for- mat and COBOL could not be tested until a data base was established. The data base is now an accomplished fact. The purpose of this article is to report that COBOL can be and is being used with MARC II data. APPLICATION The Science and Technology Division of the Library of Congress had a requirement from the U.S. Army Terrestrial Science Center to produce three reports (by subject heading, by author, and by corporate author) for ultimate photo-reduction and reproduction of the periodical literature in the Library's collection dealing with cold region research. The biblio- graphic data was processed through the MARC system and the resultant tape was in the Library of Congress' MARC processing format. It is at this point in the MARC Distribution Service that the MARC processing format is converted to the MARC II communications format for distribu- tion to subscribers. Rather than create a completely simulated environ- 262 Journal of Library Automation Vol. 1/ 4 December, 1968 ment within which to test the use of COBOL, it was decided to integrate the analysis of the COBOL language with the task at hand, i.e, the pro- gramming effort required to produce the necessary reports from a mag- netic tape file of MARC records. Additional criteria for this investigation were established. Stress was placed on the development of COBOL programming techniques utilizing the smallest possible amount of computer core storage, thereby establish- ing the capability for potential users with a minimum hardware configu- ration. Furthermore, since COBOL compilers vary in the language power that they provide with the size and make of equipment, the subset of COBOL language used conformed with the basic level of COBOL that is being standardized for acceptance in the ADP world by the United States of America Standards Institute (US ASI) Subcommittee X3.4 (Com- mon Programming Languages) . MARC II COMMUNICATIONS FORMAT AND MARC PROCESSING FORMAT COMPARED Before a description of what was done and how, a comparison of the MARC II communications format and the MARC processing format, with a brief statement of their differences, is in order. The MARC II communications format ( 2) is schematically represented in Figure 1. Leader Record Control Variable Directory Fields Fields Fig. 1. MARC II Communications Format. The communications format may be recorded on either seven-level or nine-level tape and the term "byte" in the following discussion refers to either a six-bit or eight-bit character. The MARC processing format is schematically represented in Figure 2. Record Leader Communications Control Fixed Record Variable Field Field Field Directory Fields Fig. 2. Library of Congress MARC Processing Format. MARC records at the Library of Congress are contained on magnetic tape in the form of undefined records. For System 360 purposes, these are unblocked, variable length records without the two four-byte block length and record length fields. In the processing format, fields may be recorded in binary, or packed decimal, hexidecimal or EBCDIC charac- MARC II and COBOL/ AVRAM and DROZ 263 ters dependent on the characteristics of the field and the machine proc- essing and storage efficiency required. Therefore, in the processing format the term "byte" does not necessarily refer to a character but rather de- scribes a unit of eight bits. A brief description of the fields of both formats and a gross comparison of their differences is shown in Table 1. Table 1. Comparison of MARC II Communications Format and MARC Processing Format Communications Format Leader The leader is fixed in length for all records and contains 24 bytes ( characters ) . Logical Record Length Record Status Type of Record Bibliographic Level Blanks Indicator Count Subfield Code Count Base Address of Data Blanks 5 bytes 1 byte 1 byte 1 byte 2 bytes 1 byte 1 byte 5 bytes 7 bytes Processing Format Leader The leader is fixed in length for all records and contains 12 bytes. Logical Record Length Date and Status Blank Type of Record Bibliographic Level Blanks Communications Field 2 bytes 4 bytes 1 byte 1 byte 1 byte 3 bytes The communications field is fixed in length for all records and contains 12 bytes. Record Directory Location Directory Entry Count Record Source Record Destination In Process Type In Process Status Blanks Record Control Field 2 bytes 2 bytes 1 byte 1 byte 1 byte 1 byte 4 bytes The record control field is fixed in length and contains 14 bytes. In the format for monographs, the Library of Congress catalog card number is recorded in this field. Fixed Fields The fixed fields are fixed in length for all records and contain 54 bytes. 264 ]oumal of Library Automation Vol. 1/ 4 December, 1968 Record Directory The record directory is made up of a variable number of fixed length entries ( 12 bytes each) which contains the identification tag, the length and the starting character position in the record of each variable field. The rec- ord directory ends with a field terminator code. Tag Length Starting Character Position Control fields 3 bytes 4 bytes 5 bytes The control fields contain alpha- meric data elements and are re- corded like variable fields al- though many have a fixed length. These fields end with a field ter- minator code. Each control field is identified by a 3-byte numeric tag in the record directory and these tags are not repeated in the logical record. In the MARC format for monographs, the Library of Congress catalog card number and the fixed fields are recorded as control fields. Variable Fields The variable fields are made up of variable length alphameric data, and all fields end with a field terminator code except the last variable field in the logical record which ends with an end of record code. Each variable field is identified by a 3-byte nu- meric tag in the record direc- tory, and tags may be repeated as required in the logical record. Each variable field begins with a constant number of indicators which provide descriptive infor- Record Directory The record directory is made up of a variable number of fixed length entries ( 12 bytes each) . The record dircetory ends with a field terminator code. Tag Sequence Number Blanks Action Code Length Starting Character Position 3 bytes 1 byte 3 bytes 1 byte 2 bytes 2 bytes (Record control field and fixed fields) Variable fields The variable fields are made up of variable length alphameric data, and all fields end with a field terminator code except the last variable field in the logical record which ends with an end of record code. Each variable field is identified by a 3-byte nu- meric tag in the record directory and tags may be repeated as re- quired in the logical record. Each variable field begins with the number of indicators re- quired for that field and the MARC II and COBOL/ AVRAM and DROZ 265 mation about that field. The field contains data elements which may be separated by subfield codes to identify the data ele- ment. A subfield code is com- posed of a delimiter and a lower case alphabetic character. A variable field for monographs can be described as follows: ii$a data $b data FT where i = indicator $a and $b = subfield code Ff = field terminator $ = delimiter number of lower case alphabetic characters which are a part of the subfield code. The indicators and alphabetic characters are each followed by a delimiter. The data elements of the field are separated by de- limiters only. A variable field can be described as follows: h i2 .. . in$a1 a2 .. . an $ data $ data $ data FT where i = indicator a = alphabetic character FT = field terminator $ = delimiter It should be noted that in the communications format those fields that are fixed in length (Library of Congress catalog card number and the fixed fields) for a particular form of material, e.g., monographs, are re- corded as variable fields. This guarantees that the same format structure is able to be used to represent all forms of material, e.g., serials, maps, music, etc., where the contents of these fields may . vary in length and meaning. The MARC II communications format was designed for the ex- change of bibliographic information recorded on magnetic tape to be ma- nipulable by the recipient's computer regardless of its characteristics, i.e., word machines, character machines, third-generation and second-genera- tion computers ( 3). The MARC processing format was designed for the library of Congress System 360. DEVELOPMENT The use of the COBOL programming language provided straight- forward language approach to the task. The use of natural language pro- vided the program with its own documentation. In order to relate the program to its use on the specific computer lo- cated at the Library of Congress, only the following were required in COBOL: ENVIRONMENT DIVISION. CONFIGURATION SECTION. SOURCE-COMPUTER. IBM-360 E30. OBJECT-COMPUTER. IBM-360 E30. The MARC input file was treated as containing "undefined" records. In the MARC file, records actually vary in length up to 2048 characters. 266 Journal of Library Automation Vol. 1/ 4 December, 1968 In COBOL, the MARC file and records, along with the option card file and printed output file were described as: INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT MARC-FILE ASSIGN TO 'SYS012' UTILITY 2400 UNITS RESERVE NO ALTERNATE AREAS. SELECT OPTION-CARD ASSIGN TO 'SYS013' UNIT-RECORD 2540R RESERVE NO ALTERNATE AREAS. SELECT INDEX-REPORT ASSIGN TO 'SYS014' UNIT-RECORD 1403. DATA DIVISION. FILE SECTION. FD MARC-FILE 01 FD 01 FD 01 DATA RECORD IS MARC-RECORD LABEL RECORDS ARE STANDARD RECORDING MODE IS U. MARC-RECORD. 02 MARC-BYTE OPTION-CARD PICTURE X OCCURS 2048 TIMES. DATA RECORD IS OPTION-RECORD LABEL RECORDS ARE OMITTED RECORDING MODE IS F. OPTION-RECORD PICTURE X(80). INDEX-REPORT DATA RECORD IS INDEX-RECORD LABEL RECORDS ARE OMITTED RECORDING MODE IS F. INDEX-RECORD. 02 CARRIAGE-CONTROL 02 FILLER PICTURE X. PICTURE X(l30). The next step was to manipulate the fields of the MARC processing format which would provide access to the variable field information. These fields included: 1) the first 92 bytes of each record containing fixed-for- matted items (leader, communication field, record control field, fixed fields); 2) a 12-byte directory entry that had been established for each variable field in the record containing the identification tag, the tag se- quence number, the length of the field that this directory entry corre- sponded to, and the starting position of that field relative to the first po- sition of the MARC record; and 3) the number of directory entries con- tained in each record and carried in the fixed portion of the record. The specific programming approach taken was to move the fixed fields to a work area, calculate the locations of the directory entries and their corresponding fields, extract the desired field from the record and place MARC II and COBOL/ AVRAM and DROZ 267 it in a work area for the appropriate processing. This technique was used to overcome the word boundary alignment considerations in the System 360, i.e., the use of binary arithmetic for certain data fields in the proc- essing format. Since in some cases character-by-character scanning of the record data would be required, the programming routines were modu- larized to provide for economic core storage utilization and simple ac- cessing. The three COBOL modules (which could be used repetitively) were developed as follows, preceded by supporting work areas and subscripts: Work Areas and Subscripts WORKING-STORAGE SECTION. 01 FIXED-MARC. 01 01 01 01 01 01 02 LENGTH PICTURE 99 USAGE COMPUTATIONAL. 02 DIRECTORY-COUNT PICTURE 99 USAGE COMPUTATIONAL. MARC-FIXED REDEFINES FIXED-MARC. 02 FIXED PICTURE X OCCURS 92 TIMES. HOLD-DIRECTORY. 02 D-TAG 02 FILLER 02 D-LENGTH 02 D-ADDRESS PICTURE X(3). PICTURE X(5) .. PICTURE 99 USAGE COMPUTATIONAL. PICTURE 99 USAGE COMPUTATIONAL. DIRECTORY-HOLD REDEFINES HOLD-DIRECTORY. 02 D-HOLD PICTURE X OCCURS 12 TIMES. SUBSCRIPTS USAGE COMPUTATIONAL. 02 DSUB PICTURE 9(4) VALUE ZEROS. 02 TSUB PICTURE 9(4) VALUE ZEROS. HOLD-AREAS. 02 HOLD-TAG 02 HOLD-DATA. 03 DATA-HOLD 02 PERSW OPTIONS. PICTURE X(3) VALUE SPACES . PICTURE X OCCURS 1000 TIMES. PICTURE 9 VALUE ZERO. 02 OPTION-TAG! PICTURE X(3). 02 OPTION-TAG2 PICTURE X(3) . 02 OPTION-TAGS PICTURE X(3). 02 OTHER-OPTIONS PICTURE X(71) . Continued to end of work areas and subscripts. 268 Journal of Library Automation Vol. 1/ 4 December, 1968 Modules MOD-1. NOTE SUB-ROUTINE TO MOVE FIXED ITEMS FROM RECORD INTO WORK AREA. ENTER WITH DSUB AND TSUB SUBSCRIPTS SET TO ZERO. EXIT WITH FIXED ITEMS, ADDRESSABLE BY DATA-NAMES, IN WORK AREA LABELLED 'FIXED-MARC'. MOVE-FIXED. ADD 1 to DSUB. ADD 1 to TSUB. MOVE MARC-BYTE (DSUB) TO FIXED (TSUB) . MOD-2. NOTE SUB-ROUTINE TO FIND A DESIRED IDENTIFICATION TAG IN THE RECORD DIRECTORY. SEARCH MUST BE CON- TROLLED BY THE GIVEN NUMBER OF ENTRIES IN THE RECORD DIRECTORY. ENTER WITH DSUB SET TO 92 AND PERSW SET TO ZERO. SEARCH TAG MUST BE STORED IN 'HOLD-TAG'. EXIT WITH 12 CHARACTER DIRECTORY EN- TRY IN WORK AREA LABELLED 'HOLD-DIRECTORY'. SIFT-DIRECTORY. IF PERSW EQUALS 1 GO TO SIFT-EXIT. MOVE ZERO TO TSUB. PERFORM DIRECTORY-MOVE 12 TIMES. IF D-TAG EQUALS HOLD-TAG MOVE 1 TO PERSW. SIFT-EXIT. EXIT. DIRECTORY-MOVE. ADD 1 TO DSUB. ADD 1 TO TSUB. MOVE MARC-BYTE (DSUB) TO D-HOLD (TSUB) . MOD-3. NOTE SUB-ROUTINE TO FIND DESIRED RECORD FIELD AND MOVE IT TO A WORK AREA FOR PROCESSING. ENTER WITH DESIRED DIRECTORY ENTRY IN WORK AREA LABELLED 'HOLD-DIRECTORY'. EXIT WITH DESIRED FIELD IN WORK AREA LABELLED 'HOLD-DATA'. MOVE-DATA. MOVE ZEROS TO TSUB. MOVE SPACES TO HOLD-DATA. MOVE D-ADDRESS TO DSUB. PERFORM MOVE-AD-LENGTH TIMES. MOVE-A. ADD 1 TO DSUB. ADD 1 TO TSUB. MOVE MARC-BYTE (DSUB) TO DATA-HOLD (TSUB ) . Once access to any field in the record was accomplished by the use of sub-routine modules, what remained was to establish the "mainline cod- ing" and to apply the specifications and logic for the reports that were MARC II and COBOL/ AVRAM and DROZ 269 to be produced. With this objective, the following COBOL statements were written: PROCEDURES DIVISION. HOUSEKEEPING. A. B. OPEN INPUT MARC-FILE OPTION-CARD OUTPUT INDEX-REPORT. READ OPTION-CARD INTO OPTIONS TO END CO TO A. READ MARC-FILE RECORD AT END CO TO ENDJOB. MOVE ZEROS TO DSUB TSUB. PERFORM MOVE-FIXED 92 TIMES. MOVE OPTION-TAG! TO HOLD-TAG. PERFORM B. MOVE OPTION-TAC2 TO HOLD-TAG. PERFORM B. MOVE OPTION-TAGS TO HOLD-TAG. PERFORM B. CO TO A. MOVE ZEROS TO PERSW. MOVE 92 TO DSUB. PERFORM SIFT-DIRECTORY THRU SIFT-EXIT DIRECTORY-COUNT TIMES. PERFORM MOVE-DATA. (At this point, the field is formatted for output and printed.) END JOB. CLOSE MARC-FILE OPTION-CARD INDEX-REPORT. STOP RUN. RESULTS 00 00 Figure 3 is a sample of the output of the program. The character-by- character scan, implicit in the programming required of a variable length field, also gave rise to extremely flexible data report formatting. All the data printed is "floating" in nature, restricted only by the user's print format requirements which were introduced by option card in this case. Table 2 shows the amount of core occupied during processing, and Table 3 lists man weeks expended in producing the program. Table 2. Computer Core Usage Program Sections Software 1/0 Routines COBOL Compiler Sub-routines Program I/0 Buffers and Constants Object Instructions TOTAL Bytes Occupied 1,155 2,071 4,110 3,944 11,280 270 Journal of Library Automation Vol. 1/ 4 December, 1968 con~truc ti on 23-2660 Irtc:rc.ts inq fro s t res i~tance of road toppings in th~ Tiumen • regio23-31bij w~~ hing concrete ~ ggr~gates in freezing we athet CONTACT PHOTOGRAPHY 23-3161 cont~ct mf!l'no.1 of photographing ·snow and f irn samples 23-2799 CONTINUOUS LOADI~G EFFECTS snow creep unner continuous loading 23-270~ CONTRUCTION Building emhank=ents in freezing weather 23-31 50 COMVECTION calc ulating thawing dept h of fr ozen moi s t soil 21-2217 convective heat exch~n9e in radiant g~s 2 J-2q7J Convecti•e heat exch~nge in v~ter s~tu r ~ ted ground 23-2ij 83 Lolrain"at ·tt\er11r1l convec tion in a rotating . void between tvo discs 2)-2 U77 CONVECTIVE HEAT EXCHANGE convecti ve hea t e xcha ng e in radi~nt 9as 23-2ij73 COOLIIG SYST!IIS Optiu l para•eters opera ting o n •JaS hcd.t release COORDIII1TES of cooling systeas rege neration with 2 1-2qqs l eo ~ov~~ent determination from as trono mical obser vations 23-3070 CORES Analysis of ice core s f rom Byr d Statio n 23-3113 Deep- core d r illing prog ra• at 8 yrd Station 23-31 12 Ue s ults of Antarctic core hole to bedrock 23 - 3 126 COSIIIC DUST Analy sis of magentic particles fro• Greenland ice 23 - 32 13 COUnEBII EASUBI!!S Counteraedsu re s for icing 2 3-2 567 fro :;t he4ve c ou nte raeas ures in road 2 3-2 308 cons tructi o n Invest i gdt inq frost 2J-217 0 Investigating · fr os t railroad trac~s h~ave areas heave areas on Lar,rtslide counteraeasures "dss aoveaent and effec tive 2 J-2729 2 3-2602 counterme~sures 23-27 31 Pr eventing the oppearance of naled nea r 3aa ll bridges and pipes 23-2584 Pro t .c tin g ro~d5 fro • l~ndslides by building outlets for solifluction ~aterial 2 3-2595 Rock st reams 23-26oq CRITICAL SOOMD PRESSURE Critical valu e of sound th e p r ocesses of neat tran s fe'r t~~iog place influence of aco ustic l3-250b CR!OGEIIC PBOCESSES Peraafrost in Tien Shan Theroal regi~e of so ils regions CBYOCEIIC BELIEF pressure for and 1a ss Under the vibrations 23 -301 8 io' permafrost 23-2226 Locating oioo r struc~u res fro• cry?gen ic r el i e f and pe rmafrost ir. d icati ons 2 3-31 0.0 Sup<:r •J"" " distribution of radiu• and th o riua in the Transbaikal taiga 23-281>2 ~oi l~ of orals, Vest aa4 .. ~:ibe r i~ Tu ndra and forest-tundra CRY OCE MICS Cryogenic engineering CBYOTURBATI011 central 23-319) soils 23-3195 23-2276 cryogenic ·fossil c(p.vasses coun ty. ··: CRYSTAL GBOVTH in L'is let 23-2314 Patter ns on the ice surface of a lake ~3- 27 14 CRYSTAL LATTICES Growth of an ice cr ystal ' in anal og y wit h a n elec tro s tatic field 23-2624 CRYSTAL STRUCTOBE Crystal struc ture of water 23-22ij5 Gr o vt h o f s nowflakes 23-2874 Si lver 'iod ide nucleating sites 23-2269 Snow c ry s tals in Fusb iai District,' Kyoto 23-2878 CBYSTAL STUDY T!CHIIQO!S Complexities of the three-diaensional ' shape of indivi dual crystals in g l ac i er ice 23-2943 CRYSTALS Physi ca l properties of aolecular c ry s tals, liquids, and glasselJ-2231 COBIC ICE Hexagonal and cubic ice at lov temperature 23-2651 Ten s ile strength of c ubic crystals under pressure . 23-2928 CYCLO'E BLOKIIG SIOK ft!f!R "Cyclone~ blowing snow •eter and its u se a t llirnyy 23-3073 CJBSTAL STODY TECUIIQO!S Contac't • ethod of photographing snow ann firn sa•ples 23-2799 DIIIAC! Avalan ches on Rebun I s land, Japan 23-29.13 Daaage by snowstora of Jan. 1963 in Japan 2l-a67 Por e s t da mage caused by avalanches ' 23-2875 Snov and ice da•age o n electric communication lin es in Hokkaido 23-2~8 1 DARAG!690 fOREST TBE!S Co•parative studies · of avalanche injury and vind daaage to forests 23-2ij2~ DUS Building da a s of •oraine deposits 23-2556 Bui l ding e abank•ents in freezing weather 23-3150 Chang ing the hydrologica l regiae of a river by controlling its flow23-2429 The ycar-round constru c tion of t~~ Yilyuy power station da• in t•e Extreoe North 23-2982 DBPOIR1TIOI Build in g d efor•ati o os caused bJ frost h eave 2 l- 26 07 Concrete defor•ation due to shrinkage at minus te•pera ture s 23-2558 Deformation of brid ge abut•ents erected on penafrosf 23-2599 Roadbed deforaati o n due to ground thawing and fros t heave 23-2865 Stab ility o f foundations built oo fr os t heaving ground 23-2598 Strains in concrete due to negati•e t e aperatures 2l-28ij5 D!GfiEE DUS De vel o pment of ~bore ice in the Lazare v station region 23-303 7 Fig. 3. Output of COBOL Language Program Using MARC II Data. MARC II and COBOL/ AVRAM and DROZ 271 Table 8. Manpower Expenditure Activity Analysis and Programming Debugging and Checkout Man Weeks 1 2 TOTAL 3 Since the processing time of a print program is usually a function of the speed of the printer, no accurate internal processing times were re- corded . . However, there was no noticeable time difference between this program and other MARC print programs written at the Library of Con- gress in assembly language. COMMUNICATION FORMAT PROCESSING The aforementioned techniques are equally adaptable for use with the MARC II communications format ( 3) with the following changes in format conventions: 1) The communication format has a 24-character leader rather than 92 characters of fixed length items in the processing format. In the program, under the "WORKING-STORAGE SECTION", the group item labelled "FIXED-MARC" would have to be redefined to conform with the 24-character leader. The COBOL statements that are noted with " 0 0 " would require a change of their value from "92" to "24". 2) The communication format has no total count of entries in the record directory. A calculation would have to be made to arrive at the total count and that figure stored in a new hold area labelled "DIRECTORY-COUNT". The base address of the data in the communication format is not rela- tive to the first position of the record as defined in the processing format, but to the first position of the first variable field. This base address is carried in the record leader, and is available for the calculation required for the Directory Entry Count (Base address -24/ 12). In the program, after the record directory had been searched and the proper entry placed in the work area, the "MOVE-DATA" sub-routine would move the appropriate field to the work area for processing with the one alteration noted below with an asterisk. MOVE-DATA. MOVE ZEROS TO TSUB. MOVE SPACES TO HOLD-DATA. MOVE D-ADDRESS TO DSUB. ADD BASE-ADDRESS TO DSUB. o PERFORM MOVE-A D-LENGTH TIMES. MOVE-A. ADD 1 TO DSUB. ADD 1 TO TSUB. MOVE MARC-BYTE (DSUB) TO D-HOLD (TSUB). Programming techniques naturally are dependent on the processing re- quired and the format characteristics at the individual institution. If the MARC II communications format were to be manipulated in the form 272 Journal of Library Automation Vol. 1/ 4 December, 1968 in which it is received (each byte equal to a character with a 24-character leader followed by 12-character directory entries) an alternate approach to that suggested above could be to work in the record area and not move data to a work area. CONCLUSION The only MARC II data available to users up to the writing of this article (October 1968) has been the MARC II test tape released by the Library of Congress in August 1968. Therefore, it is probable that most people expressing doubts about the use of COBOL with MARC records have done so without the experience of actually using the language. We now have this experience at the Libary of Congress. COBOL was suc- cessfully used for the computer processing of MARC records. The com- plexity of the record did not detract from ease in programming. Although the programs written were for a report function, the data accessing modules of COBOL nevertheless can be used for many other functions. File maintenance and retrieval algorithms could be defined and programmed in COBOL with facility equal to that in programming the subject function. REFERENCES 1. Griffin, Hillis: "Automation of Technical Processes in Libraries," In Annual Review of Information Science and Technology, edited by Carlos A. Cuadra (Chicago: Encyclopaedia Britannica) 3 (1968), 241-262. 2. U. S. Library of Congress, Information Systems Office: Subscriber's Guide to the MARC Distribution Service (Washington, D. C.: Li- brary of Congress, 1968). 3. Avram, Henriette D.; Knapp, John F.; Rather, Lucia J.: The MARC II Format: A Communications Format for Bibliographic Data (Wash- ington, D . C.; Library of Congress, 1968 ), pp. 1, 2, 10.