[480] in ad-lib
Re: PLEASE READ - Advance Loader Specifications
daemon@ATHENA.MIT.EDU (Sarah Mitchell)
Mon May 1 11:35:50 1995
To: Eric Celeste <efc@MIT.EDU>
Cc: ad-cat@MIT.EDU
In-Reply-To: Your message of "Fri, 28 Apr 1995 01:54:52 EDT."
<9504280554.AA17924@lauren.MIT.EDU>
Date: Mon, 01 May 1995 11:35:24 EDT
From: Sarah Mitchell <smitchel@MIT.EDU>
In I.A.2 change the Cf. should be change to Attachment A NOT B.
>ADVANCE LOADER SPECIFICATIONS
>
>I. Matching.
>
>I.A. The loader should look for matches in each of the following
>fields:
>
>I.A.1. Field 001: The OCLC control number in field 001 is fixed in
>length, carries the prefix "ocm" and has leading zeros. Match the
>001 against the CN index. Map the 001 including its "ocm" prefix
>to the first occurrence of field 035 $a in the record.
>
>I.A.2. Field 019: Field 019 will be present on some incoming
>records. Each $a in the 019 contains an OCLC control number that
>has been superseded by the record containing the 019. Unlike the
>001, the 019 tag may contain multiple numbers in separate $a
>subfields of variable length without leading zeros or the prefix
>"ocm". (Cf. Attachment A) For each $a in the 019, add the prefix
>"ocm" and add leading zeros to create a fixed length 019 field
>with 8 numeric characters. Match each occurrence of 019 $a against
>the CN index. Map each occurrence of 019 $a to $a in separate 035
>fields. Strip the 019 field from the incoming record. (Cf.
>Attachment B)
>
>I.A.3. Field 599 both indicators blank (599bb): Field 599bb will
>be present on some incoming records. Retain and match all 599bb
>fields against the LCN index. If both indicators are not blank, do
>not use the 599 tag for database matches.
>
>I.B. Use the following rules to create new records, overwrite
>existing records, or generate error conditions.
>
>I.B.1. If there is no match and no 599bb on the incoming record:
>create a new record and item holdings.
>
>I.B.2. If there is no match, but the incoming record does have a
>599bb: load the incoming record to the workfile and report an
>error type "UNMATCHED 599" to the standard Advance load report.
>
>I.B.3. If there is 1 match and the existing record contains at
>least one 035 with the prefix "ocm", then perform the following
>test:
>
>I.B.3.a. If the existing 035 with prefix "ocm" matches any of the
>incoming 001 or 019 OCLC numbers, or if the incoming record has no
>001 or 019 tags: the incoming record should overwrite the pre-
>existent bibliographic record and merge item holdings.
>
>I.B.3.b. If the existing 035 with prefix "ocm" does not match any
>of the incoming 001 or 019 numbers: load the incoming record to
>the workfile and report an error type "LCN/OCLC MISMATCH" to the
>standard Advance load report. (This error condition is intended to
>capture those records where a mistyped LCN is keyed into field
>599bb.)
>
>I.B.4. If there is 1 match and the existing record contains no 035
>with the prefix "ocm": the incoming record should overwrite the
>pre-existent bibliographic record and merge item holdings.
>
>I.B.5. If there is more than 1 match: load the incoming record
>into the workfile and report an error type "MULTIPLE MATCHES" to
>the standard Advance load report.
>
>II. OCLC transaction code handling.
>
>II.A. "Replace" command records: The Geac system should not update
>a local record with a "Replace" command record. "Replace" command
>records are incomplete and lack local data fields. "Replace"
>command (x11) records in offset 22 in the leader, should be
>skipped and not loaded into Geac Advance (Cf. Attachment B)
>
>II.B. "Cancel" command records: The cancel holdings transaction is
>utilized when all copies of a title are withdrawn from the MIT
>LIbraries collections. Therefore, when the record has (x03) in
>offset 22 of the leader, the cancelled record should check for
>matches on the 001 and 035 fields and delete the matched
>bibliographic record(s) and item holdings and copy sets. in Geac
>Advance. Cancelled records should not, however, become a permanent
>part of Advance; index pointers should be deleted for these
>records. (Cf. Attachment B)
>
>III. Call numbers
>
>III.A. OCLC call number suppression. A single upper or lower case
>"x" indicates that an item is unclassed. Therefore, bibliographic
>records with "x" alone in field 090 $a are valid and should be
>converted to 'No Call #' in field 852 $h.
>
>III.B. 050, 090, 086 call number fields with multiple $a
>subfields. Map only the first subfield $a and subfield $b to the
>Advance 852 $h when there are multiple $a subfields in the
>selected 050, 090, or 086 call number field.
>
>III.C. OCLC call number formats and Geac call number text strings.
>050/090 LC call numbers should be formatted in Advance field 852
>$h so that a decimal appears before each cutter in the call number
>string. Incoming call numbers with three cutter numbers will,
>however, appear on OCLC records with decimals before the first and
>third cutters in accordance with OCLC's call number input
>requirements. OCLC also requires that some non-standard 050/090
>call numbers be input with double spacing or a comma before
>specified call number elements. Advance call number processing
>should reduce double spaces to a single space and remove commas
>from the call number text string. The whole call number will go
>into 852 $h, MIT does not want the cutter stored in 852 $i. (Note:
>Attachment C provides a representative list of 050/090, 086, and
>099 call numbers in the form that they will appear on our OCLC
>records with our requirements for the Geac call number display
>following each example.)
>
>IV. MIT Holdings Expansion Table. Use the MIT Expansion Table
>specification to map all incoming occurrences of 949 tags to new
>item records in Advance.
