[OPEN-ILS-GENERAL] Hold Stalling at Cataloging/Delivery

Josh Stompro stomproj at exchange.larl.org
Fri Mar 18 14:18:10 EDT 2016


In the best hold selection sort order query there is a where clause that uses both the checkin lib to pickup lib, and circ lib to pickup lib to determine if a hold that is newer than the stalling period should still be included in the sort.
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Publisher/action.pm#l574
AND (AGE(NOW(),h.request_time) >= CAST(? AS INTERVAL) OR hm.proximity = 0 OR p.prox = 0)

Maybe there is more stalling logic in a different place though, that excludes the holds that match the circ lib of the copy?  Or maybe I'm not reading that correctly?

So we were seeing a few holds that had been retargeted after the time that the copy circ lib was changed from our Cataloging OU to one of our branch OU's being picked up and selected for capture because the hold map proximity was updated to  0, which bypassed the stalling time check.  It was strange because it wasn't the oldest hold at that location, just the one that happened to have been retargeted at the right time.

Josh Stompro - LARL IT Director


-----Original Message-----
From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Thomas Berezansky
Sent: Friday, March 18, 2016 10:45 AM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Hold Stalling at Cataloging/Delivery

I thought stalling only compared pickup library and checkin library, not item owning/circ library at either end (though the latter could apply for hold ordering reasons otherwise).

When the copy goes back to the circ lib and is checked in post-transit it will then do a stalling-free check of local holds there as well, so perhaps that is what you are seeing? "It didn't capture, send it home, then when it gets home it captures for something at home"?

Quoting Josh Stompro <stomproj at exchange.larl.org>:

> Hello All, I just figured out that a bunch of our strange holds 
> behavior can be blamed on having hold stalling enabled for our 
> Cataloging/Delivery org unit.  We just enabled the stalling at the 
> consortium level to start with, didn't realize the issues it would 
> cause for certain locations.
>
> The hold stalling was preventing newly cataloged items from filling 
> holds at checkin that were less than 3 days old(Our stalling 
> interval), with a twist of allowing the hold if the copy circ lib = 
> hold pickup lib  if the hold happened to have been retargeted between 
> the time the copy circ lib was changed, because the 
> action.hold_copy_map is consulted.  This doesn't make sense for us 
> since we don't use a Best Hold Selection Sort Order that uses 
> action.hold_copy_map.priority.  I should just mention that we do the 
> initial check in of in-process items in cataloging so we get a routing 
> slip to send the item where it needs to go.  Our items don't have any 
> location specific info on them since we float everything.
>
> So a bunch of new holds in our system would be skipped, and the holds 
> for another system were targeted first because they were older than 
> our stalling interval.  And then occasionally a hold would be picked 
> up if it was retargeted between the time the copy circ lib was changed 
> and it was checked in.  This didn't happen all that often, but when it 
> did it was very confusing.
>
> We only use p.prox (copy checkin library to hold pickup library) in 
> our opportunistic hold sort.  We don't want the hold copy map 
> proximity consulted because we use proximity adjustments to modify it 
> for hold targeting, so certain locations always get targeted first.  
> But we don't want certain locations prioritized in the same way for 
> opportunistic capture.
>
> The fact that both the proximity between the checking location and 
> hold pickup location, and the proximity between the copy circ lib and 
> pickup location is looked at for determining which holds are effected 
> by stalling was unknown to me.  I still haven't wrapped my mind around 
> that yet.  It seems like it might cause odd results when
> items are being checked in at locations other that their circ lib.   
> If the point of stalling is to reduce transits, then why not only 
> consult the checkin lib to pickup lib proximity?  Maybe it is because 
> the copy will be sent back to the circ lib if it isn't captured, so 
> might as well target holds there also to save a step?
>
> I believe that setting the stalling to zero for our cataloging 
> location will bypass the retarget time dependent issues.
>
> Lake Agassiz Regional Library - Moorhead MN larl.org
> Josh Stompro     | Office 218.233.3757 EXT-139
> LARL IT Director | Cell 218.790.2110


--
Thomas Berezansky
Assistant Network Administrator
Merrimack Valley Library Consortium
4 High ST, Suite 175
North Andover, MA 01845
Phone: 978-557-8161



More information about the Open-ils-general mailing list