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

    Incorrect record displays in Union catalog when searching OCLC number

    • Article Type: General
    • Product: Aleph
    • Product Version: 16.02

    When we search on OCLC number 60768717, the record retrieved in the Union View is 002143912.

    The record which *should* be retrieved (which actually contains OCLC number 60768717) is 006058902.

    {These records have the same title ("Honors Day"), but are *not* the same book.}

    As described in KB 4887, the union programs look for matching bib records and point the z120 of a
    matching, non-preferred record to the z120 of the preferred record.

    Do util f/4 in the union library (xxx90 for a union catalog; xxx01 for union view) for the z120,
    specifying the bib record retrieved in the Web as the key.
    In this case, we see the following:

    doc_number ............006058902
    preferred_doc_number ..002143912
    z120_update_flag ........C
    z120_same_no_lines ......002
    same_doc_number ........002143912
    same_doc_number ........006058902

    That is, 002143912 is the preferred record and 006058902 is a non-preferred record pointing to it.
    Once you have confirmed that the z120 is the cause of the problem, you can do util f/1/21 for the two
    records to determine just why they are being considered a match when they should not be.
    In this particular case, we see the following:

    Enter doc number 1:
    Load: /exlibris/aleph/u16_3/alephe/tab/tab100
    Load: /exlibris/aleph/u16_3/odn01/tab/tab100
    Enter doc number 2:
    Load: /exlibris/aleph/u16_3/odn01/tab/tab_expand
    Load: /tmp/utf_files/exlibris/aleph/u16_3/odn01/tab/tab_type_config.eng
    Load: /exlibris/aleph/u16_3/odn01/tab/tab_sdln_se_weights
    S-TMP-WEIGHT: +000000000
    COMPARE-RATIO: +000000000
    L-TMP-WEIGHT: +000000000
    COMPARE-RATIO: +000000000
    Load: /exlibris/aleph/u16_3/odn01/tab/tab_filing
    Load: /exlibris/aleph/u16_3/alephe/unicode/unicode_case
    Load: /exlibris/aleph/u16_3/alephe/unicode/tab_character_conversion_line
    Load: /exlibris/aleph/u16_3/alephe/unicode/unicode_to_filing_01
    Load: /exlibris/aleph/u16_3/odn01/tab/tab_com_tit_sdln
    COMPARE-RATIO: +000000600
    compare 035
    COMPARE-RATIO: +000000400
    IN ratio-check
    COMPARE-RATIO: +000000400
    compare-date and country of publication
    COMPARE-RATIO: +000000440
    COMPARE-RATIO: +000000290
    compare-main entry
    COMPARE-RATIO: +000000040
    IN ratio-check
    COMPARE-RATIO: +000000040
    MATCH: N

    The last line ("MATCH: N:) indicates that these records are *not* considered to be a match.

    In this case, you should check the z127 to see if *it* shows that the records are a match. (The z127 *should* have the same matched/preferred records as the z120 but if create_z127 and load_z127_to_mem were not run following p_union_02, they may not. In that case, the solution is to run create_z127 and load_z127_to_mem. They take just a few minutes each.)

    If the z127 isn't the problem, it means that either the $data_tab "weights" files or the $alephe_tab/union_global_param have changed since the time that p_union_02 was last run to create the z120.

    To confirm this, resend the two bib records in question to the server (using GUI Cataloging or util
    f/1/13). This *should* result in an independent z120 (a z120 which points only to the record itself)
    being created for each record.

    The same should be done with other problem cases to confirm that the current settings are correct.

    If util f/1/21 has "MATCH Y" rather than "MATCH N" for records which should not match, that means that
    the current settings need to be adjusted. As described in KB 4887, this may involve a change to
    $alephe_tab/union_global_param or it may involve changes to the $data_tab "weights" files. This should
    be done on a Test server first.

    Which weights table is used is determined by column 5 in union_global_param. If column 5 is blank,
    then the (default) $data_tab/tab_weights file will be used.

    To test a change, you need to restart the doc library ue_01.

    Once the settings are correct, you need to decide how many records are affected. If it seems there are
    many, then p_union_01 and p_union_02 will need to be re-run to correct the problem.
    This issue is still open and was escalated to Second line support for further analysis <2007-05-20 01:00:06>.

    Additional Information


    • Article last edited: 10/8/2013