---- Reported by jwagner@ptfs.com 2009-11-11 13:36:57 ---- New York Public Library and New York University Libraries have changed their z39.50 connection information, so the delivered sample z39.50 targets are now incorrect. I'm submitting a patch to change them to the correct information: NY Public Library, catalog.nypl.org, port 210, database INNOPAC NY University Libraries, hopkins1.bobst.nyu.edu, port 9991, database NYU01PUB ---- Additional Comments From jwagner@ptfs.com 2009-11-11 13:42:12 ---- Created an attachment patch file Sent patch file November 11, 2009. ---- Additional Comments From gmcharlt@gmail.com 2010-04-30 02:12:56 ---- Patch pushed. Please test and close. ---- Additional Comments From nengard@gmail.com 2010-05-02 19:11:38 ---- I tried searching on both after an upgrade and both said connection error - will this only be changed for those with new installs? ---- Additional Comments From camins@numismatics.org 2010-05-06 15:45:48 ---- The settings for NYU are incorrect in this patch. The correct settings are: Host: aleph.library.nyu.edu Database: NYU01 See http://library.nyu.edu/bobcat/z3950.html ---- Additional Comments From jwagner@ptfs.com 2010-05-06 18:03:34 ---- The connection info was correct and working when I did the patch, sigh, but that was six months ago. Looks like they've changed again. I no longer have this set up as a branch, and don't have time right now to revisit. If someone else would like to update it, go ahead. Otherwise, I'll get to it when I can. Nicole, I just did the mods in the installer files, so you would only see it with a new install. --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:14 UTC --- This bug was previously known as _bug_ 3782 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3782 Imported an attachment (id=1570) Unknown operating system Windows 2000. Setting to default OS "All". Actual time not defined. Setting to 0.0 The original reporter of this bug does not have an account here. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. Previous reporter was jwagner@ptfs.com. The original assignee of this bug does not have an account here. Reassigning to the default assignee for the component, gmcharlt@gmail.com. Previous assignee was jwagner@ptfs.com. Bug reassigned, setting status to "NEW". Previous status was "ASSIGNED". The original submitter of attachment 1570 [details] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
Trying to get back to this one. I tried changing the z39.50 setup for NYU as jcamins had it in the bug report, but when I send a search, it produces an error: Wide character in null operation at /usr/share/perl5/MARC/Charset/Table.pm line 96. Other z39.50 searches are working fine. Any ideas?
(In reply to comment #1) I have NYU working with the following settings: Z39.50 server: NEW YORK UNIVERSITY LIBRARIES Hostname: aleph.library.nyu.edu Port: 9991 Database: NYU01 Syntax: MARC21/USMARC Encoding: MARC-8 I'm running Koha 3.01.0.111 on Debian with Perl 5.01000.
We did some discussion and testing on the IRC today on this problem. It seems to be a non-Roman encoding problem with records on the NYU end. The system is connecting and retrieving results; the error comes when Koha tries to parse the results. If the Koha z39.50 connection is set to UTF-8 instead of MARC8, it will retrieve results but that may not be a good long-term solution. NYU seems to have a mixture of MARC8 and UTF-8 records.
This bug appears to still be valid. I was able to get results by changing the setup as suggested in Comment 2. Is there still some question about whether MARC-8 or UTF-8 is correct?
I suggest removing the NYU default server entirely, as their configuration keeps on changing.
I am getting error messages for both NY targets on current master: Connection failed to hopkins1.bobst.nyu.edu Connection failed to catalog.nypl.org Can we agree on removing them? I am willing to write a patch. Should we put in another sample z39.50 server as replacement?
I vote for removing them.
+1 for removing
NYPL is working fine as far as I can tell. Can someone else confirm? NYU's Z39.50 server changes every few weeks, so +1 on removing that.
NYPL times out for me. Even if it works some of the time, it doesn't make sense to include by default a resource which works inconsistently. Anyone have a recommended replacement?
(In reply to comment #10) > NYPL times out for me. Even if it works some of the time, it doesn't make > sense to include by default a resource which works inconsistently. Anyone > have a recommended replacement? It would be nice to include some non-US targets. Perhaps BSZ-BW or DNB?
Created attachment 11756 [details] [review] Bug 3782: Remove broken z39.50 targets from sample files Removes NYPL and NYU from the list of sample z39.50 servers, because they don't work or only work inconsistently.
Created attachment 11757 [details] [review] Bug 3782: Remove broken z39.50 targets from sample files Removes NYPL and NYU from the list of sample z39.50 servers, because they don't work or only work inconsistently.
Created attachment 11758 [details] [review] Bug 3782: Remove broken z39.50 targets from sample files Removes NYPL and NYU from the list of sample z39.50 servers, because they don't work or only work inconsistently. Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
(In reply to comment #14) > Created attachment 11758 [details] [review] > Bug 3782: Remove broken z39.50 targets from sample files > > Removes NYPL and NYU from the list of sample z39.50 servers, because > they don't work or only work inconsistently. > > Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> nice patch!, passing QA… $ koha-qa.pl testing 1 commit(s) (applied to commit 3f31617) * 73857bf Bug 3782: Remove broken z39.50 targets from sample files installer/data/mysql/de-DE/optional/sample_z3950_servers.sql installer/data/mysql/en/optional/sample_z3950_servers.sql installer/data/mysql/es-ES/optional/sample_z3950_servers.sql installer/data/mysql/pl-PL/optional/sample_z3950_servers.sql
Patch pushed to master (haven checked visually only that all SQL files are still valid)
Pushed to 3.8.x will be in 3.8.5
I know this has already been resolved, but I figure this might be useful for people who still want to use NYPL but have problems: "NYPL database is not available to libraries outside New York State. New York libraries and museums must contact NYPL, jeffreybayer@nypl.org, to be whitelisted so that they can search the database." http://www.webclarity.info/registry/display?fileID=751
Most recent information I have that works for the New York City Public Library is: host: ilsstaff.nypl.org port: 210 db name: innopac
(In reply to gale@rabbat.net from comment #19) > Most recent information I have that works for the New York City Public > Library is: > > host: ilsstaff.nypl.org > port: 210 > db name: innopac I take it that you're from New York state?