Re: Problems with SBN

bargioni writes:
 > Marc, maybe you only need to specify
 > format sutrs
 > before retrieve records:
 > 
 > $ yaz-client opac.sbn.it:2100/nopac
 > Connecting...OK.
 > Sent initrequest.
 > Connection accepted by v3 target.
 > ID     : 81
 > Name   : metavista-acs [a0a0b0a] [ BXZv7UyBfNE
]/GFS/YAZ
 > Version: 1.2.0/1.43/2.0.32
 > Options: search present triggerResourceCtrl scan sort
namedResultSets
 > Elapsed: 0.091031
 > Z> format sutrs
 > Z> f attr 1=4 fish
 > Sent searchRequest.
 > Received SearchResponse.
 > Search was a success.
 > Number of hits: 1222, setno 1
 > records returned: 0
 > Elapsed: 0.364839
 > Z> s
 > Sent presentRequest (1+1).
 > Records: 1
 > [nopac]Record type: SUTRS
 > Livello bibliografico: Monografia
 > Autore:                Hinton, Susan Eloise
 > Titolo:                *Rusty il selvaggio / S.E.
Hinton
 > Luogo di pubblicazione: Milano
 > Data di pubblicazione: stampa 1984
 > Codice identificativo: ITICCUANA070785
 > nextResultSetPosition = 2
 > Elapsed: 0.051814
 > Z> q

There's something very screwy about this target.  It seems
that any
attempt to fetch a record in something other than SUTRS
format causes
it to enter a state where no retrieval works:

	$ yaz-client opac.sbn.it:2100/nopac
	Connecting...OK.
	Sent initrequest.
	Connection accepted by v3 target.
	ID     : 81
	Name   : metavista-acs [a0a0b0a] [ BXZv7UyBfNE ]/GFS/YAZ
	Version: 1.2.0/1.43/2.0.32
	Options: search present triggerResourceCtrl scan sort
namedResultSets
	Elapsed: 1.020646
	Z> f attr 1=4 fish
	Sent searchRequest.
	Received SearchResponse.
	Search was a success.
	Number of hits: 1222, setno 1
	records returned: 0
	Elapsed: 0.167773
	Z> format sutrs
	Z> show 1
	Sent presentRequest (1+1).
	Records: 1
	[nopac]Record type: SUTRS
	Livello bibliografico: Monografia
	Autore:                Hinton, Susan Eloise
	Titolo:                *Rusty il selvaggio / S.E. Hinton
	Luogo di pubblicazione: Milano
	Data di pubblicazione: stampa 1984
	Codice identificativo: ITICCUANA070785
	nextResultSetPosition = 2
	Elapsed: 0.106428
	Z> format marc
	Z> show 1
	Sent presentRequest (1+1).
	Diagnostic message(s) from database:
	    [2] Temporary system error -- v2 addinfo 'Present
error'
	nextResultSetPosition = 0
	Elapsed: 0.068547
	Z> format sutrs
	Z> show 1
	Sent presentRequest (1+1).
	Diagnostic message(s) from database:
	    [2] Temporary system error -- v2 addinfo ' Wrong target
state'
	nextResultSetPosition = 0
	Elapsed: 0.113426
	Z>

That makes me nervous for a start.

Oh well.  Let's see what we can find anyway.  If you build
and
installed Net::Z3950, you should have the
"simple.pl" script, which
comes in the "samples" direction.  Run it against
this server:

	$ perl simple.pl opac.sbn.it 2100 nopac 'attr 1=4
fish'
	FATAL (yazwrap): illegal/unsupported `which' (1) in
Z_OtherInformationUnit
	$ 

Good.  We can reproduce the error.  Looking at the source
code for
Net::Z3950, this error message occurs only in the function
translateOtherInformationUnit(), when it is fed a stream
that contains
something other than an EXTERNAL.  That's never happened
before to my
knowledge, so what is the server doing?  To find out, run
yaz-client
with APDU logging turned on (the "-a -" option):

	$ yaz-client -a - opac.sbn.it:2100/nopac
	[...]
	Z> find attr 1=4 fish
	[...]
	Sent searchRequest.
	searchResponse {
	    resultCount 1222
	    numberOfRecordsReturned 0
	    nextResultSetPosition 1
	    searchStatus TRUE
	    additionalSearchInfo {
		{
		    characterInfo 'nopac(1222) '
		}
	    }
	}
	Received SearchResponse.
	Search was a success.
	Number of hits: 1222, setno 1
	records returned: 0
	Elapsed: 0.111332
	Z> 

OK, there's the culprit: that little hunk of
additionalSearchInfo.
I've not seen any other server return this, and that's why
only this
server is giving your Net::Z3950 application problems.

So now what?  First of all, did you see the warning when you
did the
initial "perl Makefile.PL" step of building
Net::Z3950?  It says:

	$ perl Makefile.PL

		WARNING.  You should not be using this module unless you
need
		this precise API for compatibility reasons.  New
applications
		should use the ZOOM-Perl module (Net::Z3950::ZOOM)
instead.
			http://s
earch.cpan.org/~mirk/Net-Z3950-ZOOM/

	MakeMaker (v6.17)
	Writing Makefile for Net::Z3950::yazwrap
	Writing Makefile for Net::Z3950
	$ 

So if you have a choice, you should be using ZOOM-Perl
instead of
Net::Z3950.  This is a better choice in many, many ways, but
the most
relevant one for you is that it is built on top of ZOOM-C,
so it uses
all the same decoder technology as ZOOM-C.  It's easy to
check that
this can handle the screwy server:

	$ zoomsh
	ZOOM>open opac.sbn.it:2100/nopac
	ZOOM>find attr 1=4 fish
	opac.sbn.it:2100/nopac: 1222 hits
	ZOOM>set preferredRecordSyntax sutrs
	ZOOM>show 0 1
	0 nopac SUTRS (1.2.840.10003.5.101)
	Livello bibliografico: Monografia
	Autore:                Hinton, Susan Eloise
	Titolo:                *Rusty il selvaggio / S.E. Hinton
	Luogo di pubblicazione: Milano
	Data di pubblicazione: stampa 1984
	Codice identificativo: ITICCUANA070785

	ZOOM>

If for some reason you truly can't upgrade from Net::Z3950
to
ZOOM-Perl, then you could either persuade the server
operator to stop
serving up this Z_OtherInfo_characterInfo-type
additionalSearchInfo,
or persuade us to upgrade Net::Z3950 so it supports this.

Hope one of these approaches works for you,

 _/|_	
____________________________________________________________
_______
/o ) /  Mike Taylor    <mikeindexdata.com>    http://www.miketaylor.or
g.uk
)_v__/  "Beak in beak, vestigal wing in vestigal wing,
with a moonful
	 of spiracles, he's the Guaranteed Eternal Sanctuary
Chicken" --
	 Nemesis, "Rupper's Steady"

_______________________________________________
Yazlist mailing list
Yazlistlists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list

Re: Problems with SBN

Thread: Re: Problems with SBN