Bib records lack system number in 001 despite "INS2 fix_doc_001"

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 19.01

Description:
We export records to OCLC with the Aleph system number in the 001 field. OCLC sends records back with the 001 field we have sent as the document number. We then use p_manage_18 to load/overlay these records.

The problem is that the 001 field in the record sent to OCLC sometimes does not have Aleph system number, but another number instead -- which, as described in KB 16384-22993, can result in a too-high last-doc-number in the abc01 util g/2 and, most seriously, incorrect keyword search results, requiring regen of the keyword index.

The cataloger can key the system number into the 001 field, but to make this more foolproof we have added the following line to our abc01 tab_fix table:

INS2 fix_doc_001

But even with this line present, the 001 field is not always created properly.

Resolution:
Starting with v16, the fix_doc_001 routine overwrites any existing 001 field with the system number (unless the "NO-OVERWRITE" parameter is specified for fix_doc_001 in tab_fix).

The "INS2 fix_doc_001" entry in tab_fix should result in the Aleph system number being written to the 001, but the fact that you have these cases where it is not indicates that it is not.

If you have the z00r built, the following SQL will locate cases where the 001 is not the Aleph system number:

abc01@ALEPH00> select Z00R_DOC_NUMBER, z00r_text from z00r where Z00R_FIELD_CODE like '001%' and Z00R_TEXT not like '0%';

(If you have not have the z00r, you could do the same using p_ret_01 to go through the doc records.)

Regardless, if you specify fix_doc_001 as a fix routine when you run p_print_03 to export the records to OCLC, the 001 should be correctly overwritten with the system number in the exported record.

Article last edited: 10/8/2013