p_manage_18 produced 6,000+ z07's with z07_sequence "1990 ..."
- Article Type: General
- Product: Aleph
- Product Version: 18.01
Description:
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 ****
SUBSTR(Z07_SEQUENCE,1,8) COUNT(*)
------------------------ ----------
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.
Resolution:
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