Can't retrieve records from the LOC

Hi,

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:

/*********************/
int main( void )
{
     ZOOM_connection z;
     ZOOM_resultset r;
     int error;
     const char *errmsg, *addinfo;

  	z = ZOOM_connection_new
("z3950.loc.gov:7090/voyager", 0);

     if ((error = ZOOM_connection_error(z, &errmsg,
&addinfo)))
     {
         fprintf (stderr, "Error: %s (%d) %sn",
errmsg, error, addinfo);
         exit (2);
     }

     r = ZOOM_connection_search_pqf (z, "knuth");
     if ((error = ZOOM_connection_error(z, &errmsg,
&addinfo)))
         fprintf (stderr, "Error: %s (%d) %sn",
errmsg, error, addinfo);
     else
         printf ("Result count: %ldn", (long)
ZOOM_resultset_size(r));

	int len;

	ZOOM_record rec = 	ZOOM_resultset_record( r, 0 );
	const char * recText = ZOOM_record_get( rec,
"render", &len );

	/* if rec is non-null, we got a record for display */
	if (recText)
	{
		fwrite (recText, 1, len, stdout); printf
("n");
	}

	ZOOM_resultset_destroy (r);
     ZOOM_connection_destroy (z);

	return 0;
}
/*********************/

Outut:
Result count: 203
Failed to retrieve record #1

ZoomTest2 has exited with status 0.

Any ideas?

Thanks,

Jon

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

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"



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