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

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

Description:
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?

Resolution:
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);

SUBST COUNT(*)
----- ----------
ABC01 7566
ABC50 1
ABC60 559

Any HOL update results in a bib Z07 being written.