Re: [OPEN-ILS-GENERAL] Holds for ILLs on Template bib records
Hi Marlene, We are trying to place Title holds, and they are for the same org unit owning the item (we do have branches). We were aware that the targeter was on a 15 minute delay, but the delay in finding the item is much more than that, sometimes a day or two days The targeter program sometimes takes much longer than every 15 minutes. The script looks to see if the targeter is already running (by checking for the existence of the /tmp/hold_targeter-LOCK file), and if the lockfile is present, it checks again 15 minutes later. In PINES, depending on the volume of holds placed, this can take hours rather than the expected 15 minutes. My current test is a title hold placed 2009-08-17T13:16:30-0400, which didn't show up on the pull holds list until this morning 8-19-09. It currently has a previous check time of 2009-08-19T14:15:14-0400. I'm not sure what that means (if that's really when the targeter checked for it last) As far as I understand things, the previous check time (prev_check_time field in action.hold_request at the database level) IS in fact the last time the hold targeter searched for a candidate for that hold. but I don't know how to determine when the targeter FIRST found the item for the hold. Is there a field for that that's visible by the client? At the database level, this is capture_time within the action.hold_request table. It's visible from within a patron account as Capture Date with a timestamp option from the column picker. Also, when the targeter finds an item, that item stays targeted until it is captured or changed to a non-holdable status - only then does it start looking for another candidate for the hold. Hope this is helpful - if someone sees any errors in my understanding, please feel free to correct me. Thanks, Chris Chris Sharp PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, Georgia 30345 (404) 235-7147 csh...@georgialibraries.org http://www.georgialibraries.org/pines - Tara Robertson information.detect...@gmail.com wrote: Hmmm...I have no idea. Hopefully someone else can help. When I worked at SITKA we had log files for holds. I don't think this came out of the box, and I'm not sure how it was set up. I do know that they were useful in trying to puzzle through what happened with some holds. Perhaps someone from SITKA can explain or expand on this. I don't think there's anything in the client that shows when an item was first targeted. Cheers, Tara On Wed, Aug 19, 2009 at 12:13 PM, Coleman, Marlene mcole...@bcgov.net wrote: Hi Tara, We are trying to place Title holds, and they are for the same org unit owning the item (we do have branches). We were aware that the targeter was on a 15 minute delay, but the delay in finding the item is much more than that, sometimes a day or two days. My current test is a title hold placed 2009-08-17T13:16:30-0400, which didn't show up on the pull holds list until this morning 8-19-09. It currently has a previous check time of 2009-08-19T14:15:14-0400. I'm not sure what that means (if that's really when the targeter checked for it last)but I don't know how to determine when the targeter FIRST found the item for the hold. Is there a field for that that's visible by the client? Holds on template records just aren't responding as a normal bib record would for holds. Thanks for your response! Marlene Marlene F. Coleman, BA, MLS, CIM ILS Database Manager, Branch Manager Beaufort County Library, Beaufort Branch 311 Scott Street, Beaufort, SC 29902 843-470-6544 mcole...@bcgov.net www.beaufortcountylibrary.org For Learning ♦ For Leisure ♦ For Life I remember that for holds that are not opportunistic holds (i.e. holds captured on checkin) that it sometimes it takes the hold targeter 15 minutes to match up the hold with the item that can fill the hold. Have you checked a few times and the holds are still not targeting? I doubt that this is relevant, but I'm curious as to what type of hold are you placing on the brief records? Is it the same type of hold that you generally use for holds? Cheers, Tara On Mon, Aug 17, 2009 at 11:24 AM, Coleman, Marlene mcole...@bcgov.net wrote: Hi all, We're part of the newly developed SC LENDS consortium, up about 2.5 months. We've been trying to sort through this problem since early on. When we create a short record for an item with a template (similar to creating an order record), instead of using a precat record for ILL, the hold targeter doesn't seem to find the item, or the hold we've attached to the item. We suspect it is a template problem, but don't know why. I've downloaded OCLC records (as temp records) and placed holds on them for ILLs and they've captured instantaneously. Even copy holds don't always find the item immediately. Is there something about a temp/short record that the targeter
[OPEN-ILS-GENERAL] Testing and fixing My Evergreen
Hi guys
After running the settings-tester.pl, this is what I am getting. I have no idea
of what I should really do.
open...@eg-server2:~$ perl settings-tester.pl
LWP::UserAgent version 2.036
XML::LibXML version 1.69
XML::LibXML::XPathContext version 1.69
XML::LibXSLT version 1.62
Net::Server::PreFork version 0.90
Cache::Memcached version 1.20
Class::DBI version 0.96
Class::DBI::AbstractSearch version 0.07
Template version 2.19
DBD::Pg version 1.49
Please install one of the following modules: Net::Z3950 Net::Z3950::ZOOM
MARC::Record version 2.0.0
MARC::Charset version 1.1
MARC::File::XML version 0.92
Text::Aspell version 0.04
CGI version 3.15
DateTime::TimeZone version 0.70
DateTime version 0.41
DateTime::Format::ISO8601 version 0.06
DateTime::Format::Mail version 0.3001
Unix::Syslog version 1.0
GD::Graph3d version 0.63
JavaScript::SpiderMonkey version 0.19
Log::Log4perl version 1.15
Email::Send version 2.192
Text::CSV_XS version 0.32
Spreadsheet::WriteExcel::Big version 2.20
Tie::IxHash version 1.21
Checking Jabber connection
* Jabber successfully connected
Checking database connections
* WARNING: Deprecated password element used for the reporter entry. Please
use pw instead.
DBI connect('dbname=evergreen;host=localhost;port=5432','postgres',...) failed:
FATAL: password authentication failed for user postgres
at settings-tester.pl line 216
* /opensrf/default/reporter/setup :: Unable to connect to database
dbi:Pg:dbname=evergreen;host=localhost;port=5432, user=postgres,
password=postgres
* /opensrf/default/reporter/setup :: Unable to connect to database
dbi:Pg:dbname=evergreen;host=localhost;port=5432, user=postgres,
password=postgres
SCALAR(0x8738560)
Use of uninitialized value in pattern match (m//) at settings-tester.pl line
243, DATA line 29.
Use of uninitialized value in concatenation (.) or string at settings-tester.pl
line 244, DATA line 29.
Use of uninitialized value in concatenation (.) or string at settings-tester.pl
line 245, DATA line 29.
* ERROR: /opensrf/default/reporter/setup :: Database
dbi:Pg:dbname=evergreen;host=localhost;port=5432 has encoding instead of UTF8
or UNICODE.
* ERROR: Language 'plpgsql' is not enabled in the target database
* ERROR: Language 'plperlu' is not enabled in the target database
* ERROR: Language 'plperl' is not enabled in the target database
* /opensrf/default/apps/open-ils.storage/app_settings/databases :: Successfully
connected to database dbi:Pg:dbname=evergreen;host=localhost;port=5432
* Database has the expected server encoding UTF8.
DBI connect('dbname=evergreen;host=localhost;port=5432','postgres',...) failed:
FATAL: password authentication failed for user postgres
at settings-tester.pl line 216
* /opensrf/default/apps/open-ils.cstore/app_settings :: Unable to connect to
database dbi:Pg:dbname=evergreen;host=localhost;port=5432, user=postgres,
password=postgres
* /opensrf/default/apps/open-ils.cstore/app_settings :: Unable to connect to
database dbi:Pg:dbname=evergreen;host=localhost;port=5432, user=postgres,
password=postgres
SCALAR(0x8738560)
Use of uninitialized value in pattern match (m//) at settings-tester.pl line
243, DATA line 29.
Use of uninitialized value in concatenation (.) or string at settings-tester.pl
line 244, DATA line 29.
Use of uninitialized value in concatenation (.) or string at settings-tester.pl
line 245, DATA line 29.
* ERROR: /opensrf/default/apps/open-ils.cstore/app_settings :: Database
dbi:Pg:dbname=evergreen;host=localhost;port=5432 has encoding instead of UTF8
or UNICODE.
* ERROR: Language 'plpgsql' is not enabled in the target database
* ERROR: Language 'plperlu' is not enabled in the target database
* ERROR: Language 'plperl' is not enabled in the target database
DBI connect('dbname=evergreen;host=localhost;port=5432','postgres',...) failed:
FATAL: password authentication failed for user postgres
at settings-tester.pl line 216
* /opensrf/default/apps/open-ils.reporter-store/app_settings :: Unable to
connect to database dbi:Pg:dbname=evergreen;host=localhost;port=5432,
user=postgres, password=postgres
* /opensrf/default/apps/open-ils.reporter-store/app_settings :: Unable to
connect to database dbi:Pg:dbname=evergreen;host=localhost;port=5432,
user=postgres, password=postgres
SCALAR(0x8738560)
Use of uninitialized value in pattern match (m//) at settings-tester.pl line
243, DATA line 29.
Use of uninitialized value in concatenation (.) or string at settings-tester.pl
line 244, DATA line 29.
Use of uninitialized value in concatenation (.) or string at settings-tester.pl
line 245, DATA line 29.
* ERROR: /opensrf/default/apps/open-ils.reporter-store/app_settings :: Database
dbi:Pg:dbname=evergreen;host=localhost;port=5432 has encoding instead of UTF8
or UNICODE.
* ERROR: Language 'plpgsql' is not enabled in the target database
* ERROR: Language 'plperlu' is not enabled in the target database
* ERROR: Language 'plperl' is not enabled in the target database
Checking database drivers to ensure driver
Re: [OPEN-ILS-GENERAL] Holds for ILLs on Template bib records
On Thu, Aug 20, 2009 at 6:36 AM, Sharp, Chriscsh...@georgialibraries.org wrote: Hi Marlene, We are trying to place Title holds, and they are for the same org unit owning the item (we do have branches). We were aware that the targeter was on a 15 minute delay, but the delay in finding the item is much more than that, sometimes a day or two days The targeter program sometimes takes much longer than every 15 minutes. The script looks to see if the targeter is already running (by checking for the existence of the /tmp/hold_targeter-LOCK file), and if the lockfile is present, it checks again 15 minutes later. In PINES, depending on the volume of holds placed, this can take hours rather than the expected 15 minutes. The 15 minute time (well, strictly speaking, the configured re-targeting run time) is just for re-targeting after the targeting interval has expired. Initial targeting occurs when the hold is placed, so something else is going on here. I suspect that this is another side-effect of the intermittent ingest issue that has shown up recently. If the record fails to ingest properly then some required data (extracted from the fixed fields, and used to determine the record type) won't be there and can cause the targeting to exit early. There is a more aggressive workaround than the hourly cleanup (Marlene, this has been proposed to your consortium, in fact) that we believe will address this until we have completely pinned down the root cause of this intermittent issue. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com
Re: [OPEN-ILS-GENERAL] Holds for ILLs on Template bib records
Hi all, Mike's injest theory may explain my recent experience. I merged two bib records, one with wait-for-copy holds but no available copy, the other with available copy. In my first case, in 10 min a target copy had been assigned. In my second case, it took 2 days. I have heard of that after a hold is initially targetted with no success, it will be retargetted once only everyday in the following days. I am not sure whether this is Sitka particular. But it helps explain why it takes longer time. Tina Ji Trainer/Help Desk Specialist BC SITKA Evergreen Implementation Quoting Mike Rylander mrylan...@gmail.com: On Thu, Aug 20, 2009 at 6:36 AM, Sharp, Chriscsh...@georgialibraries.org wrote: Hi Marlene, We are trying to place Title holds, and they are for the same org unit owning the item (we do have branches). We were aware that the targeter was on a 15 minute delay, but the delay in finding the item is much more than that, sometimes a day or two days The targeter program sometimes takes much longer than every 15 minutes. The script looks to see if the targeter is already running (by checking for the existence of the /tmp/hold_targeter-LOCK file), and if the lockfile is present, it checks again 15 minutes later. In PINES, depending on the volume of holds placed, this can take hours rather than the expected 15 minutes. The 15 minute time (well, strictly speaking, the configured re-targeting run time) is just for re-targeting after the targeting interval has expired. Initial targeting occurs when the hold is placed, so something else is going on here. I suspect that this is another side-effect of the intermittent ingest issue that has shown up recently. If the record fails to ingest properly then some required data (extracted from the fixed fields, and used to determine the record type) won't be there and can cause the targeting to exit early. There is a more aggressive workaround than the hourly cleanup (Marlene, this has been proposed to your consortium, in fact) that we believe will address this until we have completely pinned down the root cause of this intermittent issue. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com
[OPEN-ILS-GENERAL] ILL templaterecords with Holds not targeting
Hi Mike, Thanks for the update. I too suspected indexing/ingest problems awhile back, when talking/emailing with Don re this. Then I believed that that problem had been resolved or a fix had happened. I thought I would put the issue out to the list to see if others were having the same problem (with v1.4 or whichever). The most recent example that I sent in to Equinox for investigation, didn't show up on the 'pull holds list' for two days (placed 8/17, appeared 8/19). Does the Previous check time change or is it a good indication of when the item was first found for a hold? Also what is the targeting interval expiration? Thanks for your response! Marlene Marlene F. Coleman ILS Database Manager Branch Manager, Beaufort Branch Beaufort County Library 311 Scott Street Beaufort, SC 29902 mcole...@bcgov.net 843-470-6544 www.beaufortcountylibrary.org For Learning ~ For Leisure ~ For Life -- Message: 4 Date: Thu, 20 Aug 2009 10:10:43 -0400 From: Mike Rylander mrylan...@gmail.com Subject: Re: [OPEN-ILS-GENERAL] Holds for ILLs on Template bib records To: Evergreen Discussion Group open-ils-general@list.georgialibraries.org Message-ID: b918cf3d0908200710x75625066w1aa98f6f4529e...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 20, 2009 at 6:36 AM, Sharp, Chriscsh...@georgialibraries.org wrote: Hi Marlene, We are trying to place Title holds, and they are for the same org unit owning the item (we do have branches). We were aware that the targeter was on a 15 minute delay, but the delay in finding the item is much more than that, sometimes a day or two days The targeter program sometimes takes much longer than every 15 minutes. ?The script looks to see if the targeter is already running (by checking for the existence of the /tmp/hold_targeter-LOCK file), and if the lockfile is present, it checks again 15 minutes later. ?In PINES, depending on the volume of holds placed, this can take hours rather than the expected 15 minutes. The 15 minute time (well, strictly speaking, the configured re-targeting run time) is just for re-targeting after the targeting interval has expired. Initial targeting occurs when the hold is placed, so something else is going on here. I suspect that this is another side-effect of the intermittent ingest issue that has shown up recently. If the record fails to ingest properly then some required data (extracted from the fixed fields, and used to determine the record type) won't be there and can cause the targeting to exit early. There is a more aggressive workaround than the hourly cleanup (Marlene, this has been proposed to your consortium, in fact) that we believe will address this until we have completely pinned down the root cause of this intermittent issue. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com http://www.esilibrary.com/ End of Open-ils-general Digest, Vol 38, Issue 23 winmail.dat
Re: [OPEN-ILS-GENERAL] ILL templaterecords with Holds not targeting
On Thu, Aug 20, 2009 at 4:21 PM, Coleman, Marlenemcole...@bcgov.net wrote: Hi Mike, Thanks for the update. I too suspected indexing/ingest problems awhile back, when talking/emailing with Don re this. Then I believed that that problem had been resolved or a fix had happened. I thought I would put the issue out to the list to see if others were having the same problem (with v1.4 or whichever). The most recent example that I sent in to Equinox for investigation, didn't show up on the 'pull holds list' for two days (placed 8/17, appeared 8/19). The specific workflow you are using, creating a full bib record for incoming ILLs and attaching items to that, is unique as far as I know, but there's no harm in asking, of course. Does the Previous check time change or is it a good indication of when the item was first found for a hold? Also what is the targeting interval expiration? That is undetermined at this point. It depends on the specific ingest failure mode, so it may be updated in some cases and may not in others. By targeting interval expiration I was referring to the automatic retargeting interval (normally 24 or 48 hours). The hold is not retargeted at previous + 24 hours on the dot, but within 15 minutes (or the configured interval) after that time has passed. --miker Thanks for your response! Marlene Marlene F. Coleman ILS Database Manager Branch Manager, Beaufort Branch Beaufort County Library 311 Scott Street Beaufort, SC 29902 mcole...@bcgov.net 843-470-6544 www.beaufortcountylibrary.org For Learning ~ For Leisure ~ For Life -- Message: 4 Date: Thu, 20 Aug 2009 10:10:43 -0400 From: Mike Rylander mrylan...@gmail.com Subject: Re: [OPEN-ILS-GENERAL] Holds for ILLs on Template bib records To: Evergreen Discussion Group open-ils-general@list.georgialibraries.org Message-ID: b918cf3d0908200710x75625066w1aa98f6f4529e...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 20, 2009 at 6:36 AM, Sharp, Chriscsh...@georgialibraries.org wrote: Hi Marlene, We are trying to place Title holds, and they are for the same org unit owning the item (we do have branches). We were aware that the targeter was on a 15 minute delay, but the delay in finding the item is much more than that, sometimes a day or two days The targeter program sometimes takes much longer than every 15 minutes. ?The script looks to see if the targeter is already running (by checking for the existence of the /tmp/hold_targeter-LOCK file), and if the lockfile is present, it checks again 15 minutes later. ?In PINES, depending on the volume of holds placed, this can take hours rather than the expected 15 minutes. The 15 minute time (well, strictly speaking, the configured re-targeting run time) is just for re-targeting after the targeting interval has expired. Initial targeting occurs when the hold is placed, so something else is going on here. I suspect that this is another side-effect of the intermittent ingest issue that has shown up recently. If the record fails to ingest properly then some required data (extracted from the fixed fields, and used to determine the record type) won't be there and can cause the targeting to exit early. There is a more aggressive workaround than the hourly cleanup (Marlene, this has been proposed to your consortium, in fact) that we believe will address this until we have completely pinned down the root cause of this intermittent issue. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com http://www.esilibrary.com/ End of Open-ils-general Digest, Vol 38, Issue 23 -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com
