Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Recall overdue block not removed after recall is cleared

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

    We are having an issue with recall overdue blocks. When a patron is blocked because of a recall overdue and then the recall is cleared for some reason - expired, deleted, canceled or status of item changes to something like "Patron Claims Returned"--, the recall overdue block is *not* removed. Any idea why this is happening and is there any way to change it so the recall block is removed when the recall is cleared for whatever reason?

    Are you waiting until p_cir_13 has been run to check the due date? You need to.

    Looking at the p_cir_13 job log in $alephe_scratch, I see that you are setting p_reset_loan ("Reset Due Date of Cancelled Requests") to "Y". The effect of this *should* be to change the z36_due_date back to what it was before the recall -- and to change the z36_recall_due_date to 00000000 -- when p_cir_13 is run.

    Please check some z36 records for cases where the recall has been eliminated to see if you see these changes.

    Note: I'm assuming that no *explicit* block (Z303-DELINQ-n or Z305-DELINQ-n) is being created in these cases. If it were, it would, of course, need to be removed manually.

    Note: If the status of the z36 loan record is L (Lost) or C (Claims returned), then the elimination of the recall will *not* cause p_cir_13 to reset the due date. p_cir_13 resets the due only for loans with status "A" (Active). It seems we're in a Catch-22: the only process which can change the due date from the current (recall) due date back to the original due date is p_cir_51,... but it doesn't work with Claims Returned items.

    The following SQL could be used to locate the cases (which I think should be few) of z36's with status "C" where the z37 hold request no longer exists:

    SQL> select z36_rec_key from z36 where z36_status = 'C' and z36_recall_due_date ^= '00000000' minus select substr (z37_rec_key,1,15) from z37;

    and then you would do SQL to change the z36_recall_due_date back to 0 and (since you have tab100 RECALL-METHOD = 1) to move the z36_original_due_date to the z36_due_date. (With RECALL-METHOD's 2 or 3, you would *not* want or need to do this update of the z36_due_date.)

    • Article last edited: 10/8/2013