Change to HOL record not propagated to associated item; doing for *all* items

• Article Type: General
• Product: Aleph
• Product Version: 20, 21, 22, 23

Description:
After running p_manage_37 to apply a fix to HOL records (or other HOL batch updates), we find that the change has not been propagated to the item connected to each HOL record.

Is there are way that we could do this for *all* items (in case there are ones which we have missed).

Resolution:
Though online update of the HOL record does not require that the xxx60 ue_01 be running in order for the change to be propagated to the items, batch update (p_manage_18, p_manage_37, p_manage_21) does.

You need to start ue_01 in the xxx60 library (util e/1).

To do this for *all* items, do the following:

1. dlib xxx60
2. util g/2 -- note the last-doc-number

3. Connect to xxx60 with GUI Cataloging.
4. Submit the manage-40 Service, specifying 000000001 as the From-key and the <last-doc_number> recorded in step 2 as the To-key. Do *NOT* specify "999999999" as the To-key. (p_manage_40 will generate 999 million z07's.)
5. If the xxx60 ue_01 is not running, start it (to process the z07's generated by p_manage_40).

Note that the processing of the z07 by the xxx60 ue_01 also generates a z07 indexing request in the bib library. Since the call number in the xxx60 852 will already have been indexed via the LOC or PST expand, the bib records associated with these updated z30 records do *not* need to be reindexed. To avoid this unnecessary activity, you can run the xxx60 p_manage_40 and ue_01 at a time when there is no Cataloging activity in the system (and the bib library ue_01 has no backlog -- the xxx01 z07 count is zero) and do the following:

a. stop the xxx01 ue_01;
b. run the xxx60 p_manage_40;
c. start the xxx60 ue_01;
d. once the xxx60 z07 count is zero, do util a/17/1 for the z07 in xxx01 (to delete the unwanted z07s and recreate the table).