 |
 |
You get the "invalid indicator" message with the FMT tag because ALEPH uses it as a control field, with no subfields or indicators and MARC::Record is treating it as a variable field (it's making the assumption that unless a tag is a control tag, ie < 010, a field should have indicators and subfields). You can avoid the issue of alpha tags by setting an option in the program that exports MARC records from ALEPH (p_print_03), telling it to exclude alpha tags. Tim Prettyman LIT/University of Michigan Library On 6/25/08 4:55 PM, "Eric Lease Morgan" <[log in to unmask]> wrote: > On Jun 25, 2008, at 4:37 PM, Steve Oberg wrote: > >> Ok. What's allowable/possible vs. what is actually defined as part of >> variable MARC data fields in say MARC21. I'm amused by the >> hairsplitting. The bottom line is these particular fields are ALEPH >> specific and are not part of MARC21. I agree with others that >> accounting for these in whatever parsing program you use should not be >> a big deal. > > > Yep, I'm getting ALEPH output, and the issue is not so much whether or > not alpha-named fields exist but whether or not my parsing tools > (MARC::Batch and friends or Marc4J) handle them correctly. For > example, MARC::Batch warns of invalid indicators with values such as > " BE". Who ever heard of an indicator being longer than two > characters long?