maintain_control_numbers() should be kinder to OCLC numbers in 001

[Dan Scott]

Currently, maintain_control_numbers() throws out a lone 001 if it has no 003 to pair up with it (as a strict implementation of http://www.loc.gov/marc/bibliographic/bd001.html).

As it turns out, generations of library systems have generated MARC records that contain only a 001 with no 003, due to the influence of OCLC. These 001 numbers are typically prefixed with "ocm" or "ocn" and padded out with 0's.

The current maintain_control_numbers() code throws them away, never to be heard from again. This does not make libraries happy who have a long-standing relationship with OCLC and who want to retain their OCLC numbers - at least in a nice, repeatable 035 field.

So the branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/oclcnumbers does exactly that - it detects OCLC numbers in the 001 and moves them into the 035 with a complementary OCoLC control number identifier.

In addition, the branch adds an index for 035 $a system control numbers to the identifier class.

Finally, the branch includes a commit by Dan Wells which addresses a corner case where MARC records with multiple 001 fields (yes, the horror - believe it!) that happened to have one of the values matching the record ID would propagate extra 001 fields every time the record was saved.

[Dan Scott (denials)]

This should be backported to rel_2_0 as the behaviour lead to data loss for some libraries with records that didn't comply with the MARC21 spec.

[Bill Erickson (berick)]

Merged to master: f88ac0f..ab28c7b and back-ported to rel_2_1 and rel_2_0