Every item update generates CAT field in bib record
- Product: Aleph
- Product Version: 20, 21, 22, 23
- Relevant for Installation Type: Dedicated-Direct, Direct, Local, Total Care
Description
When the bib library tab_fix has a "UE_01 fix_doc_ref_1 Y" entry each item
update generates a CAT L $$aBATCH-UPD …” field. This is a problem with
serial ISSUE items where a whole group of items can be updated at once,
flooding the bib record with redundant CAT fields.
Resolution
For each item update, if the field updated is one indexed in an xxx01 index,
each update creates an xxx01 z07 indexing request. (Note: the Cataloging
programs do *not* allow multiple z07's for the same bib record at the same
time, but if ue_01 processes the z07 generated by the first item update, that
z07 will be removed and the update of the second item *will* generate another
z07, etc.)
If a
UE_01 fix_doc_ref_1 Y
line in present in tab_fix, each processing of a z07 will cause an update of
the headings fields in the record. Each of these appears as a “CAT L $
$aBATCH-UPD …” field.
Conduct the following test:
* stop the xxx01 ue_01
* update the item records
* restart the xxx01 ue_01
You *should* now find that just a single xxx01 z07 was created and the
processing of that z07 has resulted in a single “CAT L $$aBATCH-UPD …” field
being added to the record.
Assuming so, and if it's possible to cluster these serial item updates, then
turning ue_01 off at the times they are occurring could be a permanent
solution to this problem.
If, however, they occur randomly throughout the day, a more complicated
solution, such as the following, will need to be used:
* Comment out the UE_01 fix_doc_ref_1 line in tab_fix (while leaving INS
fix_doc_ref_1 Y line alone).
* Create a local script to do the following:
1. On a daily basis, mine the ue_08 log file for any doc numbers that have
appeared since the last time the script was run
2. Use that list of doc numbers as the input for print-03, giving an
unaltered Aleph sequential snapshot
3. Use that Aleph sequential file as the input/input type with manage-37
applying the INS fix routine (which still includes fix_doc_ref_1 Y)
4. Compare the original print-03 output with the manage-37 output to find
only the doc numbers that have been changed by fix_doc_ref_1 Y, e.g.:
-004207948 7001 L $$aGallo, Stefano
+004207948 7001 L $$aGallo, S.$$q(Stefano)
5. Feed that list of "changed" doc numbers back to manage-37, this time
applying the INS fix routine to the database directly
- Article last edited: 28-Feb-2016