Jon,
Sorry for the problem that was caused by the non-standard
behavior of our Voyager Z39.50 server. This has been a
known
problem. Whenever I have been questioned by users of
clients
who were having difficulties interworking with our server,
this
problem was always high on my list of suggestions -- i.e.,
record syntax object ID must be present in PresentRequest.
I hadn't been clever enough to realize that the version of
the YAZ-Proxy that we installed last April is capable of
working around this problem.
Thanks to Sebastian Hammer's off-list guidance, we have
made
a configuration change to our YAZ Proxy that generates a
backend request for MARC21 whenever a PresentRequest is
received that does not include a record syntax OID.
For the benefit of others with Voyager servers, the Proxy
config file change follows:
Locate the following lines in config.xml:
<!-- list allowed record syntaxes and possible schemas
(if any);
reject all others at the end -->
<syntax type="opac"/>
<syntax type="usmarc"/>
<syntax type="none"/>
Change the last line above to the following:
<syntax type="none"
backendtype="usmarc"/>
We made this change yesterday afternoon. We now default to
MARC21 when no OID is received.
----------------------------------------------------
Before change (replicating the problem)
----------------------------------------------------
Z> open z3950.loc.gov:7090/voyager
Connecting...OK.
Sent initrequest.
Connection accepted by v3 target.
ID : 34
Name : Voyager LMS - Z39.50 Server (YAZ Proxy)
Version: 2003.1.1/1.2.1.1
Options: search present
Z> format none
Z> f  attr 1=4 "cat in the hat comes back"
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 2
records returned: 0
Z> s 1
Sent presentRequest (1+1).
Records: 1
[voyager]Record type: SUTRS [Diagnostic wrapped as SUTRS
record]
Failed to retrieve record #1
-------------------------------------------------------
After configuration change to YAZ Proxy
-------------------------------------------------------
Z> open z3950.loc.gov:7090/voyager
Connecting...OK.
Sent initrequest.
Connection accepted by v3 target.
ID : 34
Name : Voyager LMS - Z39.50 Server (YAZ Proxy)
Version: 2003.1.1/1.2.1.1
Options: search present
Z> f attr 1=4 "cat in the hat comes back"
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 2
records returned: 0
Z> format none
Z> s 1
Sent presentRequest (1+1).
Records: 1
[VOYAGER]Record type: USmarc [MARC21 record now default
syntax]
00531cam 2200181u 4500
001 8412353
005 20030530101509.0
008 810904s1958 nyua j 000 0 eng
035 $9 (DLC) 58009017
906 $a 0 $b cbc $c premunv $d u $e ncip $f 19 $g
y-gencatlg
010 $a 58009017
040 $a DLC $c CarP $d DLC
050 00 $a PZ8.3.G276 $b Cav
100 1 $a Seuss, $c Dr.
245 14 $a The cat in the hat comes back!
260 $a New York] $b Beginner Books; $c [1958]
300 $a 61 p. $b illus. $c 24 cm.
991 $b c-GenColl $h PZ8.3.G276 $i Cav $t Copy 1 $w PREM
Thanks to all for your patience and assistance.
Larry
On Wed, 31 Jan 2007, Mike Taylor wrote:
> jda writes:
> > I'm using ZOOM to access the Library of Congress.
I can connect and
> > get hits, but when I try to retrieve the first
record I get the
> > error "Failed to retrieve record #1"
(can't get any other record,
> > either).
> >
> > Here's an example of some trial code:
>
> Thanks for sending this. I had to add some #includes
to get this to
> compile, but once I'd done that it compiled and ran OK
and gave the
> same mysterious result that you're seeing. Running
under GDB shows
> that everything is in fact working correctly, and that
the LC server
> is indeed returning a record consisting of the string
"Failed to
> retrieve record #1".
>
> This is very strange since a yaz-client session to the
same server and
> using the same query yields proper records.
>
> So I got some APDU logs using
> yaz-client -a x z3950.loc.gov:7090/voyager
> for the YAZ client session, and running YAZ Proxy to
get logs for your
> ZOOM-C program:
> yazproxy -a yazproxy.log -t z3950.loc.gov:7090/voyager
:9992
> and changing your program to connect to the proxy on
localhost:9992
> rather than directly to the LC catalogue.
>
> The result was that the only significant difference in
the requests is
> YAZ Client's inclusion of preferredRecordSyntax in the
Present Request
> APDU -- requesting record syntax 1.2.840.10003.5.10,
which is USMARC.
> Alright, then -- let's add a line to your program that
sets an option
> on your connection object, saying that you want USMARC
records:
>
> z = ZOOM_connection_new
("localhost:9992/voyager", 0);
> ZOOM_connection_option_set (z,
"preferredRecordSyntax", "usmarc");
>
> And bingo, everything works:
>
> $ gcc -g -O0 lcfetch.c -o lcfetch -lyaz
> $ ./lcfetch
> Result count: 203
> rec=0x805305c
> 00598nam 22002055a 4500
> 001 57860
> 005 00000000000000.0
> 008 940907s1994 cou 000 0 eng
> 035 $9 (DLC) 94078035
> 906 $a 0 $b ibc $c orignew $d 2 $e opcn $f 19 $g
y-gencatlg
> 955 $a pn09 09-07-94
> 010 $a 94078035
> 040 $a DLC $c DLC
> 050 00 $a 9409 BOOK NOT YET IN LC
> 100 1 $a Knuth, Bruce G.
> 245 10 $a Jeweler's resource / $c Bruce G. Knuth.
> 260 $a Thornton, CO : $b Jewelers Press, $c 1994.
> 300 $a p. $c cm.
> 922 $a ad
> 963 $a John Finkelmann (no phone #) 13440 Jackson
Pl, 80241-1401
>
> What's the conclusion here? Your program sent a fetch
request that
> didn't specify a preferred record syntax, which is
perfectly good and
> legitimate Z39.50 -- see section 3.2.2.1.5 of the
standard at:
> http://www.loc.gov/z3950/agency/markup/04.
html#Preferred-record-syntax
>
> But the LC server doesn't like to just give you the
record in a
> sensible default syntax, instead packaging an
distinctly uninformative
> error-message as a SUTRS record. This is a truly
horrible thing to
> do, not least because there is a perfectly good way for
a fetch
> request to report an error.
>
> The Right Thing would be for LC's vendor to fix their
server not to do
> this -- but such fixes usually take a very long time if
they get done
> at all. One alternative is just to always request a
specific record
> syntax in your Z39.50 client applications, and I guess
that's what
> people mostly do. A third approach would be to have
ZOOM-C or another
> of the lower software layers take a heuristic approach
to SUTRS
> records, recognising strings of the form /^Failed to
retrieve record
> #d+$/ and transforming them into non-surrogate
diagnostics -- but it
> really shouldn't be a client-side toolkit's
responsibility to kludge
> over the implementation errors of a server.
>
> The simple, but distasteful moral: always, always,
always specify a
> preferredRecordSyntax.
>
> _/|_
____________________________________________________________
_______
> /o ) / Mike Taylor <mikeindexdata.com> http://www.miketaylor.or
g.uk
> )_v__/ "I defiled a timeless piece of art!"
-- Jim Carrey, in his cover
> of the Beatles' "I Am the Walrus"
------------------------------------------------------------
Larry E. Dixson Internet: ldixloc.gov
Network Development and MARC
Standards Office, LA327
Library of Congress Telephone: (202)
707-5807
Washington, D.C. 20540-4402 Fax: (202)
707-0115
_______________________________________________
Yazlist mailing list
Yazlistlists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list
|