Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Converting paired Hebrew/Roman fields back to 880 linked fields when $$6 linking subfields are not present

     

    • Product: Aleph
    • Product Version: 20, 21, 22, 23
    • Relevant for Installation Type: Dedicated-Direct, Direct, Local

     

    Description

    In the course of our migration to Voyager and planned participation in a union catalog, a question has arisen regarding the parallel fields we use to display Hebrew and other non-roman character sets. Rather than using the linked 880 fields, we have two 100 fields (one Hebrew), two 245 fields, etc. Though our test data load looks good in the Voyager client, there is some concern that records with these paired fields may not display correctly in the OPAC. 

    The " How Does the MARC 880 Field Display and Index? "  knowledge base article talks about this pairing of fields being created by fix_doc_880 and that it can be reversed by the fix_doc_redo_880. There is a further note that the order of the paired fields is important in this process.  In our records, the linking $$6 subfields generated by fix_doc_880 are missing. They need to be regenerated in order to run fix_doc_redo_880 .  

    We are wondering how (if) the paired fields might be translated back to 880 linked fields for the Voyager conversion. 

    Resolution

    Assuming you have a mechanism for identifying which of your records need to be modified to have  linked 880 fields, and assuming you only need to convert 1xx and 245 fields,  fix_doc_redo_880 can be used for this.  

    1.  You would use the ret-01 or ret-03 Services or GUI Search to create a file of record numbers (in the form: 000123456XXX01) of bib records which need to be changed.

    2.  Use the record numbers from step 1 as input to the print-03 Service, specifying Aleph Sequential Format  output and "ALL" in Field 1. DO NOT INVOKE ANY CHARACTER CONVERSION PROCEDURE.

    3.  Convert output of step 2 from UTF-8 to MARC8 using manage-22. Specify UTF_TO_MARC8.

    4.  Add linkage $$6 subfields to the output of step 3 using the file-08 Service with this script:

    1 1####                    REPLACE-STRING                 $$a,$$601$$a

    1 245##                    REPLACE-STRING                 $$a,$$602$$a

    5.  Run manage-37 on the output of step 4 to invoke the fix routing fix_doc_redo_880.

    6.  Convert the output of step 5 from MARC8 to UTF-8 using manage-22. Specify MARC8_TO_UTF.

    7.  Reload the records into the database using manage-18, specifying "Update current records in the database" and "Replace entire record".

    Additional Information

    A.  Since 1xx tags and 245 tag are not repeatable, we can assume that there will only be 2 of either in these records, and that they should be linked by matching $$6 tags, prior to generating the 880 tags. But it’s possible that other repeatable fields (5xx, 7xx, etc.) have been created from 880 fields, leading to more than just 2 occurrences of any specific fields. For example, there could be four 700 fields. If there are no $$6 linking subfields, it would be impossible to know how to pair them back up.  Since they are defined as repeatable in MARC21, Voyager, it may not be crucial to modify these fields in order to be compliant with the Voyager design. 

    B.  Step 6 seems to be mandatory if loading the records back into ALEPH. When we used manage-18 to load the MARC8 version of the file from step 5 and specifying the Character Conversion routine MARC8_TO_UTF, the resulting records were garbled. Several fields were omitted and the fields were in random order. But when we converted the records first using manage-22 (step 6 above) and then loaded them using no Character Conversion routine, the records loaded perfectly.

     


    • Article last edited: 22-Nov-2017
    • Was this article helpful?