p_arc_01 stuck at cycle 1 in p_arc_01.cycles

Description

The p_arc_01 full ETL job is stuck in the first cycle of p_arc_01.cycles.  The log shows "creating table mrr_bib_info with loop 000000001-000030000". 

Resolution

This can happen when there are ADM records whose ADM doc number is greater than 299,970,000.  (Since the p_arc_01 cycle size is 30,000 and the greatest cycle number allowed is 9999, the highest key for which cycles can be generated is 299970000.)

Such high numbers could be the result of the xxx50 util-g-2 last-doc-number parameter being manually changed to a high number or a bib load (manage-18) containing incorrect doc numbers for the bibs and generating these high ADM numbers.  (See the article  Bib records loaded with incorrect doc numbers; p_manage_18 *HOW TO FIX*  in regard to bib records having too-high doc numbers.)  

There are two solutions in regard to too-high ADM numbers:

1) use the manage-33 Service to do a total delete of the bib records these ADM records are connected to {Note that the manage-33 Service should not and *cannot* be run in an ADM library itself (see the article Delete Bibliographic Records Including Related ADM/HOL Records (manage-33)": running in ADM or HOL library  }; or

2) use SQL to change all records containing the ADM#.

#1 requires that you save the docs to file, using the print-03 Service, and list the ADM info like orders, loans, cash transactions, etc... Then modify the last-doc-number value, reload (p_manage_18 with "Add new records"), and manually reinput the orders, loans, cash transactions, etc.  This may be feasible in the case where relatively few ADM records are affected.

#2 is complicated.  The internal comment of this article discusses this option in detail.  Please consult with your Aleph Support team in regard to this option.

• Article last edited: 25-Mar-2018