Following are a number of convenience methods for commonly-retrieved data fields.
Please note that they each return strings,
not MARC::Field objects.
They return empty strings if the appropriate field or subfield is not found.
This is as opposed to the field()/subfield() methods which return undef if something's not found.
My assumption is that these methods are used for quick & dirty reports and you don't want to mess around with noting if something is undef.

Also note that no punctuation cleanup is done.
If the 245a is "Programming Perl / ",
then that's what you'll get back,
rather than "Programming Perl".

Inserts the field specified by $new_field before the field $before_field. Returns the number of fields inserted, or undef on failures. Both $before_field and all @new_fields need to be MARC::Field objects. If they are not an exception will be thrown.

For example, if a '650' field is inserted with insert_grouped_field() it will be inserted at the end of the 6XX group of tags. After discussion most people wanted the ability to add a new field to the end of the hundred group where it belonged. The reason is that according to the MARC format, fields within a record are supposed to be grouped by block (hundred groups). This means that fields may not necessarily be in tag order.

A method for getting/setting the encoding for a record. The encoding for a record is determined by position 09 in the leader, which is blank for MARC-8 encoding, and 'a' for UCS/Unicode. encoding() will return a string, either 'MARC-8' or 'UTF-8' appropriately.

If you want to set the encoding for a MARC::Record object you can use the string values:

$record->encoding( 'UTF-8' );

NOTE: MARC::Record objects created from scratch have an a default encoding of MARC-8, which has been the standard for years...but many online catlogs and record vendors are migrating to UTF-8.

WARNING: you should be sure your record really does contain valid UTF-8 data when you manually set the encoding.

add_fields() is now deprecated, and users are encouraged to use append_fields(), insert_fields_after(), and insert_fields_before() since they do what you want probably. It is still here though, for backwards compatability.

add_fields() adds MARC::Field objects to the end of the list. Returns the number of fields added, or undef if there was an error.

There are three ways of calling add_fields() to add data to the record.

One of the areas Perl excels is in allowing the programmer to create easy solutions quickly. MARC::Record is designed along those same lines. You want a program to dump all the 6XX tags in a file? MARC::Record is your friend.

It's built for extensibility

Currently, I'm using MARC::Record for analyzing bibliographic data, but who knows what might happen in the future? MARC::Record needs to be just as adept at authority data, too.

It's designed around accessor methods

I use method calls everywhere, and I expect calling programs to do the same, rather than accessing internal data directly. If you access an object's hash fields on your own, future releases may break your code.

It's not built for speed

One of the tradeoffs in using accessor methods is some overhead in the method calls. Is this slow? I don't know, I haven't measured. I would suggest that if you're a cycle junkie that you use Benchmark.pm to check to see where your bottlenecks are, and then decide if MARC::Record is for you.

Please feel free to email me at <mrylander@gmail.com>. I'm glad to help as best I can, and I'm always interested in bugs, suggestions and patches.

An excellent place to look for information, and get quick help, is from the perl4lib mailing list. See http://perl4lib.perl.org for more information about this list, and other helpful MARC information.

The MARC::Record development team uses the RT bug tracking system at http://rt.cpan.org. If your email is about a bug or suggestion, please report it through the RT system. This is a huge help for the team, and you'll be notified of progress as things get fixed or updated. If you prefer not to use the website, you can send your bug to <bug-MARC-Record@rt.cpan.org>