Thank you for the response Jason. I knew that stalling only impacted opportunistic holds captures, but the fact that it stalls one process and not the other confuses me about what the ultimate intent of the setting is. If the intent is to try to keep holds in-house when you can and to reduce the load on delivery, you would think it would stall both processes, not just opportunistic captures. As I was thinking through stalling, it seems like it would only stall a hold in a limited number of cases.
Let's say you have a consortium that has implemented two-day holds stalling. The libraries in this consortium are in the habit of running their holds pull list on a daily basis and are good about filling holds through the targeting process. If a patron places a hold that is unavailable at the pickup library but available at other locations, there will be a stall on the opportunistic capture. However, a library that has a copy of the title will see it on its pull list and send it to the pickup library. If the hold is placed on a title that is unavailable at all locations and has a long holds queue, the stalling will never really come into play because the two days will have passed by the time the patron reaches the top of the holds queue. So the stalling would only have an impact in cases where there are no available copies at the time the hold is placed and where the patron is likely to reach the top of the holds queue within the two days for which the hold is stalled. In that scenario, if a copy of the title is checked in at a location other than the pickup library within the two-day stalling period, the system would send this copy to the shelf instead of filling the hold. However, wouldn't the system just target that copy the next time the holds targeter runs? I just had an "aha" moment as I was writing this e-mail. Is holds stalling really a way to give the circulation library an opportunity to put a title on its shelf for a brief period before sending it off to another library again? Thanks! Kathy ------------------------------------------------------------- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 756-0172 (508) 755-3721 (fax) [email protected] IM: kmlussier (AOL & Yahoo) Twitter: http://www.twitter.com/kmlussier > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > On Behalf Of Jason Etheridge > Sent: Monday, January 10, 2011 4:52 PM > To: Evergreen Discussion Group > Subject: Re: [OPEN-ILS-GENERAL] Holds settings in Evergreen > > > I'm also interested in hearing how other systems are using holds > > settings. I was looking closely at stalling last week. I > can see the > > appeal of using stalling as a way to reduce delivery. > However, I also > > would be concerned about the delay that arises from > stalling a hold, > > particularly in situations where the pickup library does not own a > > title and is unlikely to check in a copy of that title over > the next > > few days. Are there many systems using stalling? > > A word on stalling. The setting may be better named stalling > of opportunistic hold capture outside the pickup lib. A hold > request will still look beyond the pickup lib (if no settings > otherwise disallow it) for an available item if needed. > Let's call that library the pull lib. One limitation with > stalling is that the very specific barcoded item targeted at > the pull lib must be pulled for capturing, at least during > the stall period. Also, if your retarget period is less than > your stall period, the hold may very well move on to a > different pull lib at some point during the stall. > Opportunistic capture works as normal at the pickup lib even > during the stall period. > > -- > Jason Etheridge > | VP, Tactical Development > | Equinox Software, Inc. / Your Library's Guide to Open Source > | phone: 1-877-OPEN-ILS (673-6457) > | email: [email protected] > | web: http://www.esilibrary.com >
