Please excuse the cross-posting (perl4lib Net-z3950).
I am working with a Perl script designed to query our catalog via Net::Z3950
and retrieve a journal record. The OPAC record syntax is specified because
the ultimate point of the script [1] is to parse the journal holdings to
determine if a particular year is owned by our library. Our holdings (MFHD)
records often contain multiple 866 fields (which contain the actual holdings
info); however, Net::Z3950 only returns the *last* 866 from a MFHD record,
thereby giving an incomplete list of holdings.
Below is the relevant code:
use Net::Z3950;
$issn = '0028-0836'
$query = '@attr 1=8 ' . $issn;
$target = 'pulse.uta.edu';
$port = 7099;
$database = 'pulse';
$recordSyntax = 'OPAC';
$conn = new Net::Z3950::Connection($target, $port, databaseName =
$database);
$rs = $conn-search(-prefix = $query);
$rs-option(preferredRecordSyntax = $recordSyntax);
for ( $i = 1; $i = $rs-size(); $i++ ) {
$rec = $rs-record($i);
$marc = $rec-render();
print $marc;
}
If I search for the journal Nature (ISSN 0028-0836) which in our catalog has
these multiple 866s in the first holdings record:
866 0 _av.253(1975)-v.344(1990:Apr.),
866 0 _av.345(1990)-v.426(2003:Nov.20),
866 0 _av.426(2003:Dec.)-v.429(2004:May)
866 0 _aINDEXES
v.277(1979)-v.348(1990),v.403-408(2000),v.415(2002)-v.426(2003)
...I get this MARC data returned by Net::Z3950. Note the enumAndChron
line which contains the 866 info.
* Bibliographic record:
snip
245 00 $aNature.
260 $a[London, etc.,$bMacmillan Journals ltd.]
snip
* Holdings record 1 of 4:
typeOfRecord: y
encodingLevel: 4
receiptAcqStatus: 4
generalRetention: 8
completeness: 4
dateOfReport: 00
nucCode: sel,per
localLocation: Science Engineering Library: Periodicals
callNumber: Q 1
enumAndChron: ^_aINDEXES
v.277(1979)-v.348(1990),v.403-408(2000),v.415(2002)-v.426(2003)
snip
As you can see, Net::Z3950 only returns the last 866 field.
So my questions are:
1) Has anyone else noticed/experienced this behavior (i.e. only getting the
last 866)? I'm trying to determine if this behavior is unique to how I am
implementing/configuring Net::Z3950 and/or if it is ILMS specific. This is
my first time using Net::Z3950, so if I'm doing something wrong, please
correct me.
2) Is this behavior by design or is it a bug? According to the MARC
standard, the MFHD 866 is repeatable [2]. Please disregard the fact that we
have Index holdings in the 866 rather than the 868 ...or why we are using
multiple 866 even for regular holdings. Those issues are not under my
control.
3) If it is a bug, is it in Net::Z3950 or is it in the Z39.50 protocol or in
the Voyager Z39.50 implementation/API. (I have limited experience with
Z39.50 and the only other client I have, BookWhere, does not appear to offer
the OPAC record syntax.) If it is in the Net::Z3950 module can it be
fixed? :-)
I have browsed the Net-z3950 listserv archive back to September 2003 (when
version 0.36, which added support for the OPAC record syntax, was released)
and didn't see any mention of this behavior.
Our software and versions:
Net::Z3950 version 0.39 (on Solaris)
Our ILMS is Endeavor's Voyager, version 2001.2
Thanks!
-- Michael
[1] The script is designed as an SFX plug-in and was written by David Walker
of Cal State San Marcos
http://library.csusm.edu/csu/sfx/local_holding_chameleon.asp
[2] MARC 21 Concise Holdings: Textual Holdings Statement Fields (866-868)
http://www.loc.gov/marc/holdings/echdtext.html
# Michael Doran, Systems Librarian
# University of Texas at Arlington
# 817-272-5326 office
# 817-688-1926 cell
# [EMAIL PROTECTED]
# http://rocky.uta.edu/doran/
