Hold Request Slips for some items not being generated by ue_06 request daemon

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

Description:
We've had a few instances where hold request slips are not being generated for some requests by the ue-06 request daemon. The request is being processed by the ue-06 daemon (output is in the log file), but no output file ever shows up on ABC50/print. This seems to occur for certain items attached to bib records which have a very large number of items, but not for all items on such records (examples below). I've found the same behavior in both production and test databases, using the same tab39 configuration table for the request daemon. Also, when viewing these requests in the client, they show up as "Waiting in position 1 in queue", even though the item was not checked out (we normally see "in process" for such requests).

Examples. I've found this behavior on our Chemical Abstracts (ADM 001617348). I placed requests for a number of different items (volumes) and slips were generated for the following item sequence numbers:
<snip>
(After confirming the slip was generated, I deleted the file from the server so it would not actually be printed in production.)

While no slip was generated for requests on the following items:
<snip>
(Two of these were placed by another staff member and is how I became aware of the problem.)

Most of these requests are still active (production) on my record (Aleph ID 191). None of the items were checked out when the requests were placed.

I was able to replicate this behavior with a different title:

Title: Nature
ADM: 1625784

item seq: 10310 Request Slip generated (file removed from production server after confirming it was generated)
item seq: 13290 Request Slip NOT generated

Resolution:
The following SQL shows that there are 14,000 items from before 20060101 which have Z30_ARRIVAL_DATE = '00000000' with a non-zero Z30_EXPECTED_ARRIVAL_DATE. If it seems that these items *have* actually arrived, then you could use SQL to copy the Z30_EXPECTED_ARRIVAL_DATE to the Z30_ARRIVAL_DATE .

If there are some cases which do actually represent non-arrivals, then the SQL would need to be refined to update only the ones which have arrived.

abc50@TEST18> select count(*) from z30 where Z30_EXPECTED_ARRIVAL_DATE ^= '00000000' and Z30_EXPECTED_ARRIVAL_DATE < '20060101' and Z30_ARRIVAL_DATE = '00000000';
**** Hit return to continue ****

COUNT(*)
----------
14117

From site: I think this can be closed now. We now understand the problem, though we've not yet made a decision on how to best fix it.