• Article Type: General
• Product: Aleph
• Product Version: 20, 21, 22, 23

Description:

  
We have set up tab44 to indicate that all items will be held for 10 days regardless of sublibrary, item status, or borrower status. Although certain borrower statuses are not eligible to check out items with an item status of "Bound Journal" we will place these items on hold for these borrowers if they are requested from our off-site storage facility.

When hold-request-letter is printed for these borrowers the z37-end-hold-date is the date that the hold request has been filled, not 10 days hence, so the letter indicates that the item that was requested today will be held until today.

Resolution:
The execute_hold_request program, which populates the Z37-END-HOLD-DATE reads tab44 to calculate a   Z37-END-HOLD-DATE, then calls the due_date_with_offset program to calculate a "MAX-HOLD-DATE".  If the MAX-HOLD-DATE is less than the Z37-END-HOLD-DATE calculated from tab44, then it will move the MAX-HOLD-DATE to the Z37-END-HOLD-DATE instead of the tab44 date.

Case 1:

Though columns 4 and 5 (for "Item is put on hold using the 'Return' functionality") were populated properly, columns 6 and 7 (for "Item is put on hold using the 'Print letter-Hold Request filled' ") were blank and the end-hold-date calculated by the cir-06 service was today's date.  Repeating the values from columns 4 and 5 in columns 6 and 7 corrected the problem.

Case 2:
The due_date_with_offset finds a due date of today (or no due date) and populates MAX-HOLD-DATE with today's date.
-- which means, in this case, moving today's date to Z37-END-HOLD-DATE.
The only solution I can think of is an SQL script which would set the z37_end_hold_date = z37_hold_date + 10 days. This would require converting the character-format z37_hold_date into SQL datetime format. (Otherwise, 20100825 + 10 would = 20100835.)
[Site decided to just cross out the date on the notices.]

• Article last edited: 15-Oct-2016