[Net-z3950] First-time use problems

Oleg Kolobov oleg at lib.tpu.ru
Mon May 20 12:06:59 CEST 2002


Hi,

I'm loocked a some depend. For example, yaz client used default
syntax - usmarc, but when I had change default syntax, I got

Z> open tcp:star.tsl.state.tx.us:2200        
Connecting...Ok.
Sent initrequest.
Connection accepted by target.
ID     : Unicorn 2001 Bath Lvl 1
Name   : SIRSI Corporation
Version: 3.0
Options: search present delSet scan sort namedResultSets
Elapsed: 2.527831
Z> base unicorn
Z> format sutrs
Z> find @attr 1=4 alamo
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 218, setno 1
records returned: 0
Elapsed: 1.735007
Z> show 
Sent presentRequest (1+1).
Records: 1
[UNICORN]Record type: SUTRS
Decoding constructed record.: Required data element missing
[Near 0]
Packet dump:
---------
    0: [UNIV 14] len=76       tl=1, ll=1
    2:     [1:4] len=82       tl=1, ll=1
Unexpected end of buffer
Dump of content element failed.
---------


On Mon, May 20, 2002 at 10:15:45AM +0100, Mike Taylor wrote:
> > Date: Tue, 14 May 2002 17:22:32 -0500 (CDT)
> > From: Chuck Bearden <cbearden at rice.edu>
> > 
> > In order to debug a problem with my institution's Z39.50 server, I'm
> > trying to write a simple client that works.  I'm running Debian
> > Potato, using the yaz .debs I got from the Index Data site, using
> > the latest Net::Z3950 from CPAN, and using MARC.pm 1.15 (though I
> > don't think I'm getting far enough for that to matter).  I can't
> > write a client that works, and I've tried it across several servers.
> 
> Interesting one.  I have to admit up front that I am rather stumped:
> your program works (at least to the pount of the search) against Index
> Data's server, but not against your own, which suggests that your
> server is at fault; yet the Yaz command-line client works (at least to
> the point of the search) against your server.
> 
> Let's strip your program down to the opening a connection and
> searching part, which is where it starts to go wrong.  I've added an
> "or die" line to the search so we find out what went wrong, if that
> information is available:
> 
> 	#!/usr/bin/perl -w
> 	$|=1;
> 
> 	use Net::Z3950;
> 	$conn = new Net::Z3950::Connection('star.tsl.state.tx.us', 2200,
> 					   databaseName => 'unicorn');
> 
> 	$rs = $conn->search('Alamo')
> 	    or die "failed: " . $conn->errmsg() . ", " . $conn->addinfo();
> 	print "found ", $rs->size(), " records\n";
> 
> Now for me, this prints:
> 
> 	$ perl x.pl
> 	failed: Unspecified error, Expected CONSTRUCTED PDU not found (pdu error: 3002) at x.pl line 11.
> 
> In other words, the search() is failing, and the server is returning
> the rather unhelpful diagnostic code 100 ("Unspecified error").  Can
> you check your server code to see under what circumstances it does
> that?  Your server provides the rest of the string as "additional
> information" (this is the same string you found with the debugger) so
> again, you need to check your server's source to see what provokes it
> into that error.
> 
> If you change the Connection parameters to:
> 
> 	$conn = new Net::Z3950::Connection('bagel.indexdata.dk', 210,
> 					   databaseName => 'gils');
> 
> You'll see that the program works:
> 
> 	$ perl x.pl
> 	found 0 records
> 
> 
> However, I can connect to your server using the Yaz client:
> 
> 	Z> home/mike$ yaz-client star.tsl.state.tx.us:2200/unicorn
> 	Connecting...Ok.
> 	Sent initrequest.
> 	Connection accepted by target.
> 	ID     : Unicorn 2001 Bath Lvl 1
> 	Name   : SIRSI Corporation
> 	Version: 3.0
> 	Options: search present delSet scan sort namedResultSets
> 	Elapsed: 0.534371
> 	Z> find Alamo
> 	Sent searchRequest.
> 	Received SearchResponse.
> 	Search was a success.
> 	Number of hits: 403, setno 1
> 	records returned: 0
> 	Elapsed: 0.150686
> 	Z> show 1
> 	Sent presentRequest (1+1).
> 	Records: 1
> 	[UNICORN]Record type: USmarc
> 	001 ocm49597513
> 	003 OCoLC
> 	005 20020416135349.0
> 	008 020416s2001    txu          s000 0 eng d
> 	040    $a IKM $c IKM
> 	086    $a Z A025.3 F49AU 2000/1 $2 txdocs
> 	099  9 $a Z A025.3 $a F49AU, 2000/1
> 	049    $a IKMD
> 	245 00 $a Alamo Community College District, San Antonio, Texas, annual financial report for the year ended August 31, 2001.
> 	246 30 $a Annual financial report for the year ended August 31, 2001
> 	260    $a San Antonio, Tex. : $b Garza/Gonzalez & Associates, $c [2001]
> 	300    $a 89 p. : $b ill. ; $c 28 cm.
> 	610 20 $a Alamo Community College District $x Appropriations and expenditures.
> 	710 2  $a Garza/Gonzalez & Associates.
> 	710 2  $a Alamo Community College District.
> 	949    $a Z A025.3 F49AU 2000/1 $w ASIS $c 1 $h TXD $i 36237002485791 $r N
> 	949    $a Z A025.3 F49AU 2000/1 $w ASIS $c 2 $h TXD $i 36237002485809
> 	994    $a E0 $b IKM
> 	596    $a 1
> 	926    $a TSLAC $b TXDOCUMENT $c Z A025.3 F49AU 2000/1 $d BOOK $f 1
> 	926    $a TSLAC $b TXDOCUMENT $c Z A025.3 F49AU 2000/1 $d BOOK $f 2
> 	nextResultSetPosition = 2
> 	Elapsed: 0.855752
> 	Z> 
> 
> It's not at all obvious to me why Net:Z3950 would send a different
> APDU from the Yaz client, since they both use the same underlying
> Z39.50 encoding utilities (those of the Yaz toolkit).
> 
> Sebastian?  Adam?
> 
> I guess the way forward with this would be for me to figure out how to
> provoke Net::Z3950 to produce an APDU trace, as the "-a -" options ask
> the Yaz client to do.  Then we could compare the network traffic
> generated in the two cases.  I'm not going to have time to do this any
> time soon, though -- sorry.
> 
>  _/|_	 _______________________________________________________________
> /o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
> )_v__/\  "How can a thing of permanence so swiftly disappear?" --
> 	 The Waterboys, "Something that is Gone"
> 
> 
> _______________________________________________
> Net-z3950 mailing list
> Net-z3950 at indexdata.dk
> http://www.indexdata.dk/mailman/listinfo/net-z3950

-- 
Oleg Kolobov
Scientific Technical Library of Tomsk Polytechnic University
oleg at lib.tpu.ru





More information about the Net-z3950 mailing list