sanity check: php/yaz inconsistent results

this is mainly a sanity check, to have someone make sure i'm
not
missing something obvious...

i'm using the php/yaz bindings to query various targets; it
seems that
when a search retrieves a single result, i get more detailed
results
(i.e., more marc fields) than when i retrieve
one-or-more...

here's the php script and the captured output:

     http://dog.l
ib.muohio.edu/yaz/z3950.phps
     http://
dog.lib.muohio.edu/yaz/php_results.txt

you'll see that the first search (single result) has a 903,
945, etc,
while the two results from the second search don't....

so i compared this with the same searches done with
yaz-client...typescript here:

     
http://dog.lib.muohio.edu/yaz/yaz-client_results.txt

looks like the same results get returned for each search.

thanks for taking the time to look, and pointing out
something obvious
that i'm doing wrong ....was
troubleshooting some missing fields,
and this is all i could track down....

debian php5.2, yaz 2.1.48, php/yaz 1.0.8...thanks again,
rc

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

Rob Casson writes:
 > this is mainly a sanity check, to have someone make
sure i'm not
 > missing something obvious...
 > 
 > i'm using the php/yaz bindings to query various
targets; it seems
 > that when a search retrieves a single result, i get
more detailed
 > results (i.e., more marc fields) than when i retrieve
 > one-or-more...
 > 
 > here's the php script and the captured output:
 > 
 >      http://dog.l
ib.muohio.edu/yaz/z3950.phps
 >      http://
dog.lib.muohio.edu/yaz/php_results.txt
 > 
 > you'll see that the first search (single result) has a
903, 945,
 > etc, while the two results from the second search
don't....
 > 
 > so i compared this with the same searches done with
 > yaz-client...typescript here:

Interesting.  Looks like you're inadvertently using one of
Z39.50's
more sophisticated (in the sense of "confusing")
facilities, the
ability to specify in a search what size result-set
constitutes a
"small" vs. "large" set, and what
element-sets to use in each case.
This stuff is described in the standard, sections 3.2.2.1.4
(Small-set-element-set-names and
Medium-set-element-set-names)
onwards, at:
http://www.loc.gov/z3950/agency/markup
/04.html#Small-set-element-set-names

But there is nothing in your program that immediately
suggests to me
that this is what you're doing.  (I realise that this is not
as
helpful as you'd probably hoped it would be.)

All I can suggest is that you get an APDU trace of your
reqeusts and
responses.  I think the simplest way to do this is to run
YAZ Proxy in
APDU-dumping mode (yazproxy -a adpu.log) and route your
connection
through that.  If you can send us the result, we'll see what
we can
discover from that.

 _/|_	
____________________________________________________________
_______
/o ) /  Mike Taylor    <mikeindexdata.com>    http://www.miketaylor.or
g.uk
)_v__/  "That's right, Pete.  It's actually pronounced
Mi'li-wau-KAY, and
	 it's Algonquin for The Good Land" -- Alice Cooper,
"Wayne's World"


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

Mike Taylor wrote:
> Rob Casson writes:
>  > this is mainly a sanity check, to have someone
make sure i'm not
>  > missing something obvious...
>  > 
>  > i'm using the php/yaz bindings to query various
targets; it seems
>  > that when a search retrieves a single result, i
get more detailed
>  > results (i.e., more marc fields) than when i
retrieve
>  > one-or-more...
>  > 
>  > here's the php script and the captured output:
>  > 
>  >      http://dog.l
ib.muohio.edu/yaz/z3950.phps
>  >      http://
dog.lib.muohio.edu/yaz/php_results.txt
>  > 
>  > you'll see that the first search (single result)
has a 903, 945,
>  > etc, while the two results from the second search
don't....
>  > 
>  > so i compared this with the same searches done
with
>  > yaz-client...typescript here:
> 
> Interesting.  Looks like you're inadvertently using one
of Z39.50's
> more sophisticated (in the sense of
"confusing") facilities, the
> ability to specify in a search what size result-set
constitutes a
> "small" vs. "large" set, and what
element-sets to use in each case.
> This stuff is described in the standard, sections
3.2.2.1.4
> (Small-set-element-set-names and
Medium-set-element-set-names)
> onwards, at:
> http://www.loc.gov/z3950/agency/markup
/04.html#Small-set-element-set-names
> 
> But there is nothing in your program that immediately
suggests to me
> that this is what you're doing.  (I realise that this
is not as
> helpful as you'd probably hoped it would be.)
> 
> All I can suggest is that you get an APDU trace of your
reqeusts and
> responses.  I think the simplest way to do this is to
run YAZ Proxy in
> APDU-dumping mode (yazproxy -a adpu.log) and route your
connection
> through that.  If you can send us the result, we'll see
what we can
> discover from that.
> 

Or you use the nice 'ziffy' program distributed along with
Yaz
(thaks to  Rocco Carbone)

man zpiffy gives:


ZIFFY(1)                  The Z39.50 Network Sniffer



NAME
        ziffy - capture and display Z39.50 APDUs on a live
network

SYNOPSYS
        ziffy [ -alloptionshere ]
              [ -i interface ] [ -r file ] [ -s snaplen ]
                [ -T type ] [ -w file ] [ expression ]





>  _/|_	
____________________________________________________________
_______
> /o ) /  Mike Taylor    <mikeindexdata.com>    http://www.miketaylor.or
g.uk
> )_v__/  "That's right, Pete.  It's actually
pronounced Mi'li-wau-KAY, and
> 	 it's Algonquin for The Good Land" -- Alice
Cooper, "Wayne's World"
> 
> 
> _______________________________________________
> Yazlist mailing list
> Yazlistlists.indexdata.dk
> http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list
> 


-- 

Marc Cromme
M.Sc and Ph.D in Mathematical Modelling and Computation
Senior Developer, Project Manager

Index Data Aps
Købmagergade 43, 2
1150 Copenhagen K.
Denmark

tel: +45 3341 0100
fax: +45 3341 0101

http://www.indexdata.com


INDEX DATA Means Business
for Open Source and Open Standards





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

Rob,

I may have missed it in my quick skim, but I didn't see you
explicitly 
set an element set name before launching the search. When
nothing is 
provided, it is entirely possible that the server defaults
to 'B' when 
you retrieve multiple results, 'F' when not.

The reason for the difference may also be that php/yaz may
attempt to 
optimize communication by using piggy-backed present
operations -- 
asking the server to return records along with the search
results to 
expedite traffic.

I'd try first to explicitly set the element set name to 'F'.
If that 
doesn't work, you can disable piggybacking.. look at 
http://us2.php.net/manual/en/function.yaz-connect.php
.

--Seb

Rob Casson wrote:
> this is mainly a sanity check, to have someone make
sure i'm not
> missing something obvious...
> 
> i'm using the php/yaz bindings to query various
targets; it seems that
> when a search retrieves a single result, i get more
detailed results
> (i.e., more marc fields) than when i retrieve
one-or-more...
> 
> here's the php script and the captured output:
> 
>     http://dog.l
ib.muohio.edu/yaz/z3950.phps
>     http://
dog.lib.muohio.edu/yaz/php_results.txt
> 
> you'll see that the first search (single result) has a
903, 945, etc,
> while the two results from the second search don't....
> 
> so i compared this with the same searches done with
> yaz-client...typescript here:
> 
>     
http://dog.lib.muohio.edu/yaz/yaz-client_results.txt
> 
> looks like the same results get returned for each
search.
> 
> thanks for taking the time to look, and pointing out
something obvious
> that i'm doing wrong ....was
troubleshooting some missing fields,
> and this is all i could track down....
> 
> debian php5.2, yaz 2.1.48, php/yaz 1.0.8...thanks
again,
> rc
> 
> _______________________________________________
> Yazlist mailing list
> Yazlistlists.indexdata.dk
> http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list
> 
> 

-- 
Sebastian Hammer, Index Data
quinnindexdata.com   www.indexdata.com
Ph: (603) 209-6853 Fax: (866) 383-4485

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

thanks everybody for the time/tips...you've all helped check
my sanity ;)

sebastian was indeed correct, and explicitly setting the
element set
to 'F' does the trick.

thanks again for all the work/help,
rc

On 2/21/07, Sebastian Hammer <quinnindexdata.dk> wrote:
>
> Rob,
>
> I may have missed it in my quick skim, but I didn't see
you explicitly
> set an element set name before launching the search.
When nothing is
> provided, it is entirely possible that the server
defaults to 'B' when
> you retrieve multiple results, 'F' when not.
>
> The reason for the difference may also be that php/yaz
may attempt to
> optimize communication by using piggy-backed present
operations --
> asking the server to return records along with the
search results to
> expedite traffic.
>
> I'd try first to explicitly set the element set name to
'F'. If that
> doesn't work, you can disable piggybacking.. look at
> http://us2.php.net/manual/en/function.yaz-connect.php
.
>
> --Seb
>
> Rob Casson wrote:
> > this is mainly a sanity check, to have someone
make sure i'm not
> > missing something obvious...
> >
> > i'm using the php/yaz bindings to query various
targets; it seems that
> > when a search retrieves a single result, i get
more detailed results
> > (i.e., more marc fields) than when i retrieve
one-or-more...
> >
> > here's the php script and the captured output:
> >
> >     http://dog.l
ib.muohio.edu/yaz/z3950.phps
> >     http://
dog.lib.muohio.edu/yaz/php_results.txt
> >
> > you'll see that the first search (single result)
has a 903, 945, etc,
> > while the two results from the second search
don't....
> >
> > so i compared this with the same searches done
with
> > yaz-client...typescript here:
> >
> >     
http://dog.lib.muohio.edu/yaz/yaz-client_results.txt
> >
> > looks like the same results get returned for each
search.
> >
> > thanks for taking the time to look, and pointing
out something obvious
> > that i'm doing wrong ....was
troubleshooting some missing fields,
> > and this is all i could track down....
> >
> > debian php5.2, yaz 2.1.48, php/yaz 1.0.8...thanks
again,
> > rc
> >
> > _______________________________________________
> > Yazlist mailing list
> > Yazlistlists.indexdata.dk
> > http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list
> >
> >
>
> --
> Sebastian Hammer, Index Data
> quinnindexdata.com   www.indexdata.com
> Ph: (603) 209-6853 Fax: (866) 383-4485
>
> _______________________________________________
> Yazlist mailing list
> Yazlistlists.indexdata.dk
> http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list
>

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