- Article Type: General
- Product: Aleph
- Product Version: 20, 21, 22, 23
Though the xxx50 cir-78 job ("Circulation Logger Clean Up") is still appearing in util c/1, it last wrote to the xxx50 $data_scratch xxx50_p_cir_78.nnnnn file several hours ago. It seems to be stalled.
1. if the cir-78 has been running for multiple days, do util c/7 to see what jobs are queued up behind cir-78, and use util c/8 to delete jobs which are duplicates and don't need to run multiple times
2. do: ps -ef |grep cir_78 to see what cir_78 processes are running for xxx50
3. kill the processes found in the preceding grep
4. do the following SQL to see the distribution of the remaining z309's:
SQL-xxx50> select substr (Z309_DATE_X,1,4), count(*) from z309 group by substr (Z309_DATE_X,1,4);
5. submit an initial run of cir-78 with yyyy1231 as the To-Date (where "yyyy" is the oldest year); then do a run with the next-to-oldest year in the To-Date, etc.
NOTE: v22 rep_change 2001 (which will be included in Minor Release 22.1, due out in Dec. 2014) is intended to improve cir-78 performance.
If cir-78 still stalls, despite the steps in the above Resolution, then SQL would need to be used to delete the z309s.
In the case of z309 records whose patron ID has been scrubbed (those beginning with a key of "SCR") all of them can be deleted. In the case of pseudopatrons (dummy patrons) perhaps the most recent year should be saved.
In the case of other patrons, the past several years of z309s should be saved.
Also, there was a bug in the v21 upgrade script which prevents cir-78 from deleting certain z309 records which it should. See article "v21/v22 cir-78 runs longer than previously, not removing z309 records it should".
Also, cir-78 doesn't remove certain z309_action types. The following SQL can be used to diagnose this:
SQL-xxx50> select substr (Z309_DATE_X,1,4), z309_action, count(*) from z309 group by substr (Z309_DATE_X,1,4), z309_action;
Category: Batch (500)
- Article last edited: 1/28/2016