Re: MARC::Field::new_from_usmarc problems
It shouldn't really be necessary to have different flavors of MARC for this. Unlikes other leader positions, Base address of data is NOT defined to be implementation-specific or implementation-defined. Bytes 12/16 are supposed to contain base address of data, and in this case, simply appear to be incorrect. Anne L. Highsmith Consortia Systems Coordinator 5000 TAMU Evans Library Texas A&M University College Station, TX 77843-5000 [EMAIL PROTECTED] 979-862-4234 979-845-6238 (fax) >>> Ed Summers <[EMAIL PROTECTED]> 01/13/04 11:28AM >>> On Tue, Jan 13, 2004 at 06:17:25PM +0100, Leif Andersson wrote: > If it is in accordance with a special MARC flavour, then maybe MARC::Record > should do something to meet this need? But, we do not know that yet. Yeah, we could have new_from_xxx() for a different MARC flavors I suppose. It might also be nice to be able to: $MARC::RECORD::STRICT = undef; $MARC::RECORD::WARNINGS = undef; Which would have the same effects as: $batch->strict_off(); $batch->warnings_off(); Which would allow for calls to new_from_usmarc() without bailing when something looks fishy...for advanced users only :) But it would be even nicer to know exactly what's going on here first. //Ed -- Ed Summers aim: inkdroid web: http://www.inkdroid.org The deeper I go the darker it gets. [Peter Gabriel]
Re: MARC::Field::new_from_usmarc problems
It shouldn't really be necessary to have different flavors of MARC for this. Unlikes other leader positions, Base address of data is NOT defined to be implementation-specific or implementation-defined. Bytes 12/16 are supposed to contain base address of data, and in this case, simply appear to be incorrect. Anne L. Highsmith Consortia Systems Coordinator 5000 TAMU Evans Library Texas A&M University College Station, TX 77843-5000 [EMAIL PROTECTED] 979-862-4234 979-845-6238 (fax) >>> Ed Summers <[EMAIL PROTECTED]> 01/13/04 11:28AM >>> On Tue, Jan 13, 2004 at 06:17:25PM +0100, Leif Andersson wrote: > If it is in accordance with a special MARC flavour, then maybe MARC::Record > should do something to meet this need? But, we do not know that yet. Yeah, we could have new_from_xxx() for a different MARC flavors I suppose. It might also be nice to be able to: $MARC::RECORD::STRICT = undef; $MARC::RECORD::WARNINGS = undef; Which would have the same effects as: $batch->strict_off(); $batch->warnings_off(); Which would allow for calls to new_from_usmarc() without bailing when something looks fishy...for advanced users only :) But it would be even nicer to know exactly what's going on here first. //Ed -- Ed Summers aim: inkdroid web: http://www.inkdroid.org The deeper I go the darker it gets. [Peter Gabriel]
Re: MARC::Field::new_from_usmarc problems
On Tue, Jan 13, 2004 at 06:17:25PM +0100, Leif Andersson wrote: > If it is in accordance with a special MARC flavour, then maybe MARC::Record > should do something to meet this need? But, we do not know that yet. Yeah, we could have new_from_xxx() for a different MARC flavors I suppose. It might also be nice to be able to: $MARC::RECORD::STRICT = undef; $MARC::RECORD::WARNINGS = undef; Which would have the same effects as: $batch->strict_off(); $batch->warnings_off(); Which would allow for calls to new_from_usmarc() without bailing when something looks fishy...for advanced users only :) But it would be even nicer to know exactly what's going on here first. //Ed -- Ed Summers aim: inkdroid web: http://www.inkdroid.org The deeper I go the darker it gets. [Peter Gabriel]
Re: MARC::Field::new_from_usmarc problems
It appears to be deceptive values in leader pos 12-16, which is supposed to point to the beginning of data. MARC::Record relies on this value. I do not know, though, if this is a sign of a different MARC flavour, or if something bad has happened to the record. If it is in accordance with a special MARC flavour, then maybe MARC::Record should do something to meet this need? But, we do not know that yet. Leif
Re: MARC::Field::new_from_usmarc problems
On Tue, Jan 13, 2004 at 10:48:57AM +0200, Christoffer Landtman wrote: > Any help on the matter is deeply appreciated as I really cannot make > anything of this, as it was working on my setup, but not on various > other peoples setups. Could you send the program as an attachment to me Chistoffer? I'm not confident that the MARC will have survived translation into the body of your email message. Thanks! //Ed -- Ed Summers aim: inkdroid web: http://www.inkdroid.org The imagination of nature is far, far greater than the imagination of man. [Richard Feynman]
MARC::Field::new_from_usmarc problems
Dear all,
I was wondering if there is anyone from the MARC::Record team on this
list who possibly could give some insight in the following matter.
We are using MARC::Record to manipulate MARC records in Emilda [1] and
we have been running into some unexpected problems. The actual
manipulation code has not been altered lately, but people were reporting
that MARC manipulation was behaving weird when testing Emilda. As such
we had to look into the matter, and found out that there indeed was
something weird going on, at least with some certain setups.
I managed to reproduce the error (I'm not quite sure if it is because of
MARC::Record, but since it is MARC::Record that reports the error, I'm
assuming it is) and added some debugging information to the code to see
what is happening.
Here is a snipplet from the code, that displays the debugging information:
print "RAW: ".$self->{'MARC_blob'}."\n";
$record = MARC::Record::new_from_usmarc($self->{'MARC_blob'}) or die $!;
print "RES: ".$record->as_formatted()."\n";
print "WARN: ".join("\n", $record->warnings())."\n";
and what this outputs is:
RAW: 02599nam 2200025 a
45040010011000300111005001700021008003900038020002300077035001500100035001900115035003300134047001670420012001740840021001860840018002071270022524500380025226000530029034100343599001000384653001600394653003200410653002000442653001600462653001900478653002000497841004800517841004800565841004800613841004800661841004800709841004700757841004900804841004700853841004900900841004700949841004700996841004801043841004901091841004701140841004901187841004901236841004801285841004701333841004901380852001101429852002501440852001701465852001301482852001301495852001701508852001101525852002901536852002201565852001101587852001701598852002801615852002601643852002401669852002501693852002101718852003801739852001101777852001801788976002301806 000286 ESBO_STAD 20031030130634.0 990309s1999
sw j 001 0 swe a9129646103 c183:00 99129646103
5Bo a(Bo)368396 5Lahv a(MMLahv)1999025970
aNB 9NB 9SEE 5SEE aUgg 2kssb/6 aUgg,u 2kssb/6 1
aJansson, Hasse, d1949- 00 aTitta på fåglar! / cHasse Jansson
aStockholm : bRabén & Sjögren, c1999 ; e(Danmark) a61, [2] s.
: bfärgill. ; c18 x 22 cm aLi: S 5Sbi aFåglar
5Lahv aFåglar aArtbestämning 5La aFaktaböcker 5Jon aFåglar
5La aBarnböcker 5Jon aBarnböcker 5Gp axa b0201080u0
4000uu |00 e1 5Li axa b0201080u0 4000uu
|00 e1 5La axa b0201080u0 4000uu |00 e1
5Um axa b0201080u0 4000uu |00 e1 5Kd axa b0201080u0
4000uu |00 e1
5Mo au b030828|||001||00 e1 5Jon axa b0201080u0
4000uu |00 e1 5L axa b0201080u0 4000uu
|00 e1 5Hsd axa b0201080u0 4000uu |00 e1
5O axa b0201080u0 4000uu |00 e1 5Q axa b0201080u0
4000uu |00 e1 5Sk axa b0201080u0 4000uu
|00 e1 5Sbi axa b0201080u0 4000uu |00 e1
5Bo ax b0201070u0 4000uu021001 e1 5SEE axa b0201080u0
4000uu |00 e1 5Hls axa b0201080u0 4000uu
|00 e1 5NB axa b0201080u0 4000uu |00 e1
5S axa b0201080u0 4000uu |00 e1
5Lahv au b030616|||001||00 e1 5Mo bMo
5Lahv bLahv hUgg xSus 5La bLa huUgg 5SEE bSEE
5Hsd bHsd 5Gp bGp huUgg 5Sk bSk
5Hls bHls hUgg,u jJansson 5Li bLi cCNB hug,u 5Um bUm
5Kd bKd hUg,u 5Jon bJon hUg BARN jJANS
5L bL c0200 h299/ j102 5O bO huUgg jJansson
5Q bQ clära hUg,u Jan 5S bS hSv99 j2878
5NB bNB cNB99:12 hgåva jKU, 990602 5Bo bBo 5Sbi bSbi jRef
2 aUgg,u bFåglar Aves
RES: LDR 02599nam 2200025 a 4504
WARN: No directory found in record 1
"RAW" is the original MARC record to be manipulated and thus imported
using new_from_usmarc(), but this seems to fail for some reason that is
not apparent, at least to me.
Any help on the matter is deeply appreciated as I really cannot make
anything of this, as it was working on my setup, but not on various
other peoples setups.
Regards,
--
[1] http://emilda.org
--
Christoffer Landtman
Oy Realnode Ab
Partner, Sales
+358 (0)41 510 1073
[EMAIL PROTECTED]
www.realnode.fi
