Skip to main content
ExLibris

  • Subscribe by RSS
    • Aleph
    Ex Libris Knowledge Center

    New records are not going to the head of the z07 indexing queue

    1. Last updated
    2. Save as PDF
    • Article Type: General
    • Product: Aleph
    • Product Version: 20

    Description:
    We did a large LTI load on our production machine on Monday, October 20 and our indexing queue has been large since then. For the first time since going to v. 18 we seem to have authority control working again and the number of records in our z07 table is large (over 282,000 records). According to the documentation new records are supposed to take precedence over the updated records but we are not seeing this. For example, the following new records are still waiting in the queue and I have received many calls from the catalogers wondering why these records have not been indexed yet:

    2526952 (created 10/20, 2:26 pm)
    2526953 (created 10/20, 2:29 pm)
    2527493 (created 10/22, 11:56 am)
    2528963 (created 10/28, 2:38 pm)

    Why are the new records not taking precedence over the other records in our z07?

    Resolution:
    As described in Article 000040333 ("Z07 records: order of processing; controlling indexing priority") ( https://exlibrisgroup--c.na26.visual.force.com/apex/VF_ArticleView?id=kA3320000004LwC&srKp=ka3&srPos=1 ) , ue_01 processes the z07's with the lowest z07_sequence first.

    The z07 for bib record 002526952 has a value of "1990":

    SQL> select substr (Z07_SEQUENCE,1,4) from z07 where Z07_REC_KEY = '002526952';

    SUBSTR(Z07_S
    ------------
    1990


    But there are 274,857 Z07's with a sequence of '1902' which are ahead of it:

    SQL> select count(*) from z07 where z07_sequence like '1902%';

    COUNT(*)
    ----------
    274857


    This is because aleph_start.private has the following lines:

    setenv z07_oclc_server 1901
    setenv z07_ue_08 1902

    The effect of this is to give priority to records coming from the oclc_server or ue_08.

    These lines should be changed or deleted. See Article 000040333 for a full discussion of this issue.

    The following SQL will correct the current situation:

    SQL> update z07 set z07_sequence = '2006' || substr (z07_sequence,5,11) where z07_sequence like '1902%';

    • Article last edited: 2/13/2015