Request Failures: Non-Failure and Non-Failure Follow-ons

Non-failures first appeared in mid-July 2009.  They represent successful requests for books in the ReCAP REFILE queue.  The refile queue is the area where books returned to ReCAP are held before reshelving in the modules.  The appellation "non-failure" denotes that a failure notice was received despite the item correctly retrieved and delivered.

Retrieval from the refile queue creates an opportunity for genuine failure.  It relates to how barcodes are removed from CUL "Big File," the manner in which CUL and ReCAP databases keep in sync.  This type of failure is provisionally called "Non-failure follow-on" and occurs rarely.

Non-Failures

To interpret non-failures, it is important to have a good understanding of how to access the LAS system and interpret item status.

Chronology helps determine what happened with this type of failure notice.

failure_notice_1
  • On 11/09/10 a failure notice arrives for barcode CU52810356.  It indicates that the item is OUT as of 09/15/10.
failure_log
  • Record of the request appears in the daily failure log.  It is missing the note "AVAILABLE FOR RETRIEVAL - BEING REFILED"
  • The text of this note prevents a failure notice from being sent for successful REFILE queue retrievals.
las_status_1
  • The failure notice claims it is OUT as of 09/15/10. 
  • The current status in LAS is OUT as of 11/09/10, indicating that it was retrieved correctly.
las_history
  • The item history in LAS indicates that the first request was submitted on 09/15/10 and shipped to CUL on 09/16/10
  • It returned to ReCAP and entered the REFILE queue on 11/02/10.  The second request was submitted on 11/09/10 and shipped on 11/10/10.
  • Because there is no CLOSE DATE for the first request it means the book never left the REFILE queue.
  • No action is necessary to resolve this non-failure.

The cause of non-failures is unknown.  It applies to physical delivery and EDD requests alike, to both patrons and staff.  They persist and represent the vast majority of all failure notices received by CUL.

LITO has attempted to problem-solve locally.  Duplicate request submissions have been ruled out.  Debugging logs have ruled out requests bypassing the standard request mechanisms.  The request form is generating correctly ("OUT" not displayed for unavailable items).

Non-Failure Follow-ons

follow_on_1
  • Non-failure follow-ons may result when a CLOSE DATE is generated for the first request.
  • When ReCAP closes the order and generates a CLOSE DATE, the barcode is removed from CUL's "Big File."  The CLOSE DATE typically indicates that the book has been reshelved in the modules and has status In and At Rest. The Big File is used to keep the two databases synchronous. For more information see Barcode Tracking : Model of how CUL and ReCAP databases remain in sync
follow_on_2
  • To diagnosis this type of failure, first check for a discrepancy in the dates on the initial failure notice.  If the OUT ON date preceeds the request date, check the item history in LAS.  If the request date for the current order falls between the OPEN DATE and CLOSE DATE of the previous, consider the request a non-failure follow-on.
  • Contact the patron to explain that the book is currently unavailable.
recap5

ReCAP User Inquiry Alias: recap@library.columbia.edu

Supervisor, ReCAP Access Services: Jennifer Loubriel

Phone: (212) 854-3542

E-mail: jll2223@columbia.edu