Incorrect record displays in Union catalog when searching OCLC number
- Article Type: General
- Product: Aleph
- Product Version: 16.02
Description:
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.}
Resolution:
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:
z120_rec_key
doc_number ............006058902
z120_rec_key_1
preferred_doc_number ..002143912
z120_update_flag ........C
z120_same_no_lines ......002
z120_same[01]
same_doc_number ........002143912
z120_same[02]
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:
006058902
--------------------------------------------------------------
Load: /exlibris/aleph/u16_3/alephe/tab/tab100
--------------------------------------------------------------
Load: /exlibris/aleph/u16_3/odn01/tab/tab100
Enter doc number 2:
002143912
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
compare-lccn
S-TMP-WEIGHT: +000000000
COMPARE-RATIO: +000000000
compare-issn
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-title
COMPARE-RATIO: +000000600
compare 035
COMPARE-RATIO: +000000400
IN ratio-check
COMPARE-RATIO: +000000400
compare-date and country of publication
COMPARE-RATIO: +000000440
compare-260a
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
faq
- Article last edited: 10/8/2013