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?