099 call numbers "inherit" extra subfields in batch loads

• Article Type: General
• Product: Aleph
• Product Version: 16.02

Description:
When loading records from OCLC or RLIN, the resulting 852 fields consist of the 099 $a in 852 $h, but have the 090 or other call number field's $b tacked on as a $i.

The tab_mapping table looks like this:

ABCD 050## a 8520 h Y N
ABCD 050## b 8520 i Y N
ABCD 090## a 8520 h Y N
ABCD 090## b 8520 i Y N
ABCD 099## a 8528 h Y N

If the incoming record has an 090 like this:

$$aPR123$$b.A35

And has an 099 like this:

$$aSPEC1234

The 852 ends up looking like this:

$$hSPEC 1234$$i.A35

Is there some way to configure ALEPH so this does not happen?

Resolution:
The problem is that the loader program creates the various subfields as it goes along. When it comes to the point of creating a new subfield, it deletes any such subfield that it has already created, but does not delete others that might be hanging around. So, in this case, it has already created a subfield i, and does not get any trigger that tells it to drop that one, which thus gets added to your final call number. This may or may not be a bug, as perhaps there are occasions where you would want to get subfields from different fields, such as a subfield i from the 090, then the subfield h from the 099. I've never seen any such example, but with lots of international libraries on Aleph, there could be such a situation somewhere.

To resolve it, you need to do something that will trigger the deletion of the remaining subfield i, but not actually create a new one. You can do this by adding a line to your tab_mapping that will try to create an empty subfield i for each 099 $$a it finds. The program won't add an empty subfield, but that will be enough to make it delete the already created one. The 099 lines in tab_mapping should look like this:

ABCD 099## a 8528 h Y N
ABCD 099## a 8528 i s/*// Y N

This mechanism instructs the loader to create a subfield i from each 099 $$a, but then to delete all the content.