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

Description:
SI 16384-265331 describes how, following a run of p_manage_01 ($alephe_scratch/fcl01_p_manage_01.02939, beginning May 27 18:00, ending May 28 09:23), the FCL01UMA base wasn't working.

util h/1/10 showed that the FCL01UMA base (with "wow=um" in tab_base, column 9) had only 145,000 records -- whereas it should have 2.5 million. (The WOW index is built on the bib record OWN field.) A ccl search of the wsl index for the UMA50 sublibraries {wsl=(UMDUB or UMFAC or UMMDA or UMSCA or UMSCI or UMFCD or UMIMA or NOCOD or UMA)} was getting a similar (too low) result.

The wow and wsl indexes for the other ADMs (AMH50, HAM50, SMT50, and MHC50) had correct numbers of records, and the catalogs for their logical bases in the OPAC were giving correct results.

I noticed that p_arc_01 for uma50 had been running on May 28 00:30 - 03:00 (uma50_p_arc_01.07910) -- during the fcl01 p_manage_01. We run one ARC extract each morning; the uma50_p_arc_01 was the only one which ran on Saturday morning. This p_arc_01 was run with p_lock_library "N".

Though I didn't know of any reason that running p_arc_01 for uma50 should interfere with the bib keyword indexing, this was the only thing I could see that was different for uma50.

Resolution:
I told them to cancel the p_arc_01 run for this morning and try re-running the fcl01 p_manage_01. The log of this job is fcl01_p_manage_01.02958. We find that the wow and wsl indexes which it has built are correct. util h/1/10 now shows 2,531,083 records for the FCL01UMA base.

Ex Libris staff examined this. Their testing did not show any interference with p_manage_01 by p_arc_01.

They saw that you also ran p_manage_01 in UMA30 during that time:

28-05-2011 05:17:02 p_manage_01 Library UMA30 locked in param
28-05-2011 05:22:15 p_manage_01 Library UMA30 unlocked
28-05-2011 05:22:49 p_manage_01 end

So it seems there were other processes (not just p_arc_01) that could interfere with the p_manage_01 in FCL01.
We looked at $data_scratch of FCL01 and couldn’t find the logs for the p_manage_01 that ran on May 27-28.
We can only see the log in $alephe_scratch but that is not enough in order to investigate on why the problem happened

• Article last edited: 10/8/2013