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

    Z07's generated by ue_08 and by item and HOL record updates

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

    We're seeing very large numbers of records in the production bib z07 table (tens of thousands) with current date/timestamp sequences, and no logs of batch processes that would explain how the records got there.

    We have three questions:

    1. What is the priority of processing of records submitted to Z07 from authority updates "messaged" to the bib library via ue_11? It seems that ue_08-generated entries would get a z07_sequence starting with "1990". Is that true for ue_11-generated entries? We're not seeing the "1990" sequence in bib Z07 table.

    2. Is there any way to determine which Aleph process submitted a record into Z07? Are records submitted by batch processes always given a sequence number with the current date/timestamp, or is there a hierarchy of batch process modified bibs that's reflected in the z07_sequence key?

    3. Which HOL and z30 changes cause Z07 records to be generated in the 01 library?

    1. z07 records are processed in date order; oldest date first. See Article 000040333 (Z07 records: order of processing; controlling indexing priority") for general information.

    ue_08 updates are not back-dated -- thus giving them the lowest priority (which is what they should have).

    The following SQL shows that all of the current Z07's have "2007" as the year:

    SQL-ABC01> select substr (z07_sequence,1,4), count(*) from z07 group by substr (z07_sequence,1,4);

    The order of priority is: New (regardless of source), then Updated (PC, oclc_server, RLIN), then batch/UE_08.

    The fact that all of the current z07s have a z07_sequence of "2007" indicates that they are the lowest priority and their origin is batch or ue_08.

    (You will find that an online update generates a z07 with a 199x sequence which is processed immediately -- in preference to these "2007" z07s. This back-dating makes the z07's for current online updates be processed in preference to the z07's produced by batch processes, and a large backlog of z07's will *not* prevent the current Cataloging updates from being indexed)

    This command in the abc01 $data_scratch:

    grep -c 'Update doc' *run_e_08*

    shows ue_08 to have been the origin of about 500,000 z07's in the past three days -- so that is certainly the answer.

    Why did ue_08 have this activity? ue_08 activity comes from authority record updates.

    This command shows the specific authority records, conveyed to abc01 via z105 records processed by ue_11:

    grep -c Update *run_e_11*

    As to what made the authority changes, you should check with Cataloging staff about that.

    2. All batch-process-generated- and ue_08-generated-z07's have the same sequence year. (They are not back-dated and have the current year.) There is no way to tell them apart. ue_08, p_manage_21, p_manage_18, p_manage_40, p_file_9x, and p_manage_62 are processes which can generate large numbers of Z07s.

    3. This SQL shows you what library is the source of each z07:

    SQL-ABC01> select substr (z07_history,1,5), count(*) from z07 group by substr (z07_history,1,5);

    ----- ----------
    ABC01 7566
    ABC50 1
    ABC60 559

    Any HOL update results in a bib Z07 being written.

    Additional Information

    Article link:  Z07 records: order of processing; controlling indexing priority

    See also:   Which z30 Field Updates Trigger BIB Index Update?   and 000045123 (Why are Thousands of Z07s Being Generated? *COMPREHENSIVE RECORD*)  for more on Z07 creation and processing.  

    • Article last edited: 2/9/2015