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

Description:
ue_01 stops with the following error:

I/O error : file '/ABC50000280944000010'
error code: 3/7 (ANS85), pc=0, call=1, seg=0
37 File access denied

If we delete the z07 record for the bib record which item 000280944-000010 is connected to, ue_01 will run for several hours (or days) successfully, but eventually stops again with the same error (on this or another record).

Resolution:
Performing the following grep in the abc01 $data_scratch:

>>grep -i 'I/O error' *e_01.*

and sorting the results by doc number, I see that the same 7 item records are repeatedly causing ue_01 to fail.

I find that there are:

2 abc50 items with the item processing status "OE": 000118328 and 000198735;
4 abc50 items with the item processing status "PE": 000000060, 000000600, 000001000, 000280944;

SQL-abc50> select z30_item_process_status, count(*) from z30 group by z30_item_process_status;
**** Hit return to continue ****

Z3 COUNT(*)
-- ----------
BD 3
BI 58
BP 92
CA 1
CT 4
DI 18
DP 6
IP 12
MF 20
MI 87
MN 1
NA 30
OE 2
OI 1
OP 7
PE 4
RM 34
SB 15
TE 1
UA 13
UP 132
347623

It is certainly *way* too much of a coincidence that 6 of the 7 problem items have the OE and PE item processing statuses -- and that these are the *only* items in the system with these two item processing statuses.

The only exception is item 000000800-10, which has a blank item processing status. But, looking at the z30h table, I find that this item *did* have an item processing status of "PE" as recently as 2009-04-16!

Though the site was not able to determine what was problematic about these items with the z30_item_process_status'es OE and PE, they found that changing the item process status to other values permitted ue_01 to index them without error.