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

    p_manage_18 produced 6,000+ z07's with z07_sequence "1990 ..."

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

    Quick question about the current status of our z07 table:

    SQL-abc01> select substr(z07_sequence,1,8), count(*) from z07 group by substr(z07_sequence,1,8) order by substr(z07_sequence,1,8);
    **** Hit return to continue ****

    ------------------------ ----------
    19900905 6113
    19900907 100
    19980903 663
    19980904 91
    19980905 23
    19980906 32
    19980907 625
    20100903 1175
    20100904 414
    20100905 3298
    20100906 40
    20100907 1

    In an earlier message in this thread, records that are introduced from either the GUI Cataloging Client or OCLC export are timestamped with either a 1990 or 1998 in the queue in order to give them priority in the indexing processing. It is odd that so many records have a timestamp of 19900905 (over 6100) currently. 09/05 was a Sunday when all the libraries were closed so it strange that so many entries bear a GUI Cataloging timestamp from that day.
    There were a number of p_manage_18 and p_manage_33 jobs run on that date, however I would have thought those batch jobs would have created items with 2010 datestamps. The only jobs listed in KB 4093 that introduce items into z07 that were run on that date.

    This is like KB 16384-16545. Following that, I suggest, for the current situation, that you do this SQL:

    SQL> update z07 set z07_sequence = '1999' || substr(z07_sequence,5,11) where z07_sequence like '1990090506%';
    SQL> commit;

    Following KB's 16384-9745 and 8192-7463, I suggest that you add the following line to aleph_start.private:

    setenv z07_p_manage_18 1999

    to prevent p_manage_18 - loaded records from having priority over updates in GUI Cataloging and the oclc_server.

    • Article last edited: 10/8/2013