Thousands of bib library Z07's suddenly coming from xxx50 library

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

Description:
The queue of ABC01 Z07 records suddenly grew this morning from around 100 to more than 200,000. What might have caused this?

Resolution:
See SKB 4093 for a general discussion of the possible sources for creation of bib Z07 records.

The paragraphs below describe the handling of the case where the xxx50 ADM library is the source of the bib Z07s -- as shown by the following SQL:

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

The cause of bib library Z07's with xxx50 as their source is -- either directly or indirectly -- updates to item records. (See SKB 4140 for a list of fields whose update triggers bib Z07 creation.)

When an item record with one of these Z07-triggering fields is updated, two Z07's are written: one to the BIB library and one to the ADM library. And the processing of the Z07 by ue_01 in the ADM library can trigger a *second* Z07 to be written to the bib library.

The following is a sequence for diagnosing this problem:

1. Do the following SQL 3 or 4 times in a row in the bib library to confirm that Z07's are still being created:

SQL> select count(*) from z07;

If you don't see the count increasing, then the problem is no longer occurring.

2. Check (with the xxx50 util c/1) to see if ue_01 is running in the ADM library. If it is, then stop it (with util e/2) -- at least temporarily. (Do util c/1 again to verify that it is stopped.)

3. Do the SQL in step 1 again to see if the bib library z07 count is still increasing. If the count has stopped increasing, then that means that the ADM ue_01 is the current source of the problem. If so, do the "SQL> select count(*) from z07; " in the *ADM* library to see how many you have there. If you are not building indexes in the xxx50 library, you can delete these z07's and you don't need to have ue_01 running there. See SKB 4107 in this regard.

In one recent case, a site which had never had ue_01 running in the xxx50 library started it. There were several hundred thousand z07's waiting to be processed and each processing wrote a z07 to the bib library.

The following SQL can be used to determine when the z07's in a bib or ADM library were written and how many were written on each date. (Note that online updates are *backdated* to 199x, in order to make them be processed first, since ue_01 does first-in, first-out processing.)

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

To see what the oldest ones are for a particular day, such as today:

abc01@ALEPH0> select z07_sequence, z07_rec_key, substr (z07_history, 1,14) from z07 where z07_sequence like '20070129%' order by z07_sequence;

Z07_SEQUENCE Z07_REC_K SUBSTR(Z07_HISTORY,1,14)
--------------- --------- ------------------------------------------
200701290813156 002238522 ABC50000000124
200701290813156 002238523 ABC50000000125
200701290813157 002238524 ABC50000000126
200701290813157 002238525 ABC50000000127
<Etc.>

(This shows that the Z07 for bib record 00228522 has been triggered by an update to ABC50 record 000000124.)

4. Though it's possible, as in the recent case described in #3 above, that ADM z07's could accumulate over time from regular online updates, it's more common for the writing of xxx50 z07's to be the result of a specific batch process creating/updating large numbers of item records. Some such processes are p_manage_62, p_manage_50, p_manage_40, and p_item_06. Check the xxx50 $data_scratch directory and the $alephe_scratch for these or other xxx50 jobs which might be the source of the problem. SKB 8192-2810 describes a case where p_manage_62 was the problem.