Our little state (hint: starts with "V") has implemented an interlibrary loan system that seems to be unable to use Z39.50 correctly to query Koha in order to determine an item's availability. I'll try to describe the problem and then ask if there's a workaround in Koha. The state ILL system, called CLOVER, is able to use Z39.50 to query our library's Koha installation to determine whether an item is in our catalog. We told the state to use the MARC 952$r field returned by Koha (actually Zebra, if I understand correctly) to determine whether the item is available. This field contains the item's due date. If it is present and contains a date, the item is NOT available. If it is not present, the item IS available. But apparently, CLOVER is not able to handle a MARC field that is present sometimes and not at other times. It requires that the field be present ALL the time. That is the explanation given to us by the state when we asked why CLOVER wasn't working correctly (it keeps issuing requests for books that it had already requested). This seems like a serious bug, because there are at least 80 other Koha installations in our state. Unfortunately, CLOVER is closed-source and proprietary, so there seems to be no way for the state to fix the problem. Is there some workaround that I can implement in Koha and/or Zebra to force the 952$r field to be present in all records returned in response a Z39.50 query? I think CLOVER might work if 952$r were present but blank for items that are available. Thanks in advance!
I made a silly mistake in my previous message: I meant 952$q (onloan), not 952$r (datelastseen).
We have a similar situation with a different proprietary ILL software in Kansas. We also use the 952$q. When an item is checked out, the 952$q has a date and the ILL software registers that as unavailable. When it's not checked out, the field is empty and the ILL software registers it as available. That means the only status we can report to the ILL software is 'Checked out'. If an item is lost, withdrawn, etc., requests can still be made. Along with the other systems that use Koha in Kansas, we have worked with ByWater on this. You can see the details here: https://bugs.koha- community.org/bugzilla3/show_bug.cgi?id=13937. The basic idea is that whenever a z39.50 request is made, Koha will populate a status into a singular subfield that can be mapped and read by the external ILL software. Jason Robb SEKnFind Coordinator Southeast Kansas Library System jrobb@sekls.org On Thu, Sep 21, 2017 at 4:34 PM, Mark Alexander <marka@pobox.com> wrote:
I made a silly mistake in my previous message: I meant 952$q (onloan), not 952$r (datelastseen). _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Excerpts from Jason Robb's message of 2017-09-21 16:53:16 -0500:
Along with the other systems that use Koha in Kansas, we have worked with ByWater on this. You can see the details here: https://bugs.koha- community.org/bugzilla3/show_bug.cgi?id=13937. The basic idea is that whenever a z39.50 request is made, Koha will populate a status into a singular subfield that can be mapped and read by the external ILL software.
Thanks! I ran across that bug a few minutes before I saw your reply. The proposed solution looks good. Is there a plan to incorporate it eventually into the official Debian package?
Wow. I hadn't noticed that new feature! On jue., 21 de sep. de 2017 7:41 p. m. Mark Alexander <marka@pobox.com> wrote:
Excerpts from Jason Robb's message of 2017-09-21 16:53:16 -0500:
Along with the other systems that use Koha in Kansas, we have worked with ByWater on this. You can see the details here: https://bugs.koha- community.org/bugzilla3/show_bug.cgi?id=13937. The basic idea is that whenever a z39.50 request is made, Koha will populate a status into a singular subfield that can be mapped and read by the external ILL software.
Thanks! I ran across that bug a few minutes before I saw your reply. The proposed solution looks good. Is there a plan to incorporate it eventually into the official Debian package? _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F
Excerpts from Tomas Cohen Arazi's message of 2017-09-21 23:44:56 +0000:
Wow. I hadn't noticed that new feature!
I applied the patches to our Koha installation and it does seem to work when I invoke the server as follows: koha-shell <INSTANCE> cd /usr/share/koha perl bin/z3950_responder.pl --add-item-status=k tcp:@:9999 I realize that patching an installation made from a Debian package is not recommended, but I'm comfortable with this sort of thing, and I was in a bit of a hurry to fix the ILL problem.
participants (3)
-
Jason Robb -
Mark Alexander -
Tomas Cohen Arazi