| Description:
The “22” section of the ./xxx01/tab/tab_filing has the following:
!* LC Call Numbers
22 del_subfield
22 lc_call_no
Two classification systems have 852 first indicator "8": the CalDoc classification system, used for California government documents; and a classification system developed in-house for use with a collection of haiku materials. An example of a CalDoc call number is F377.C35, and an example of a haiku call number is "HAIKU I14id 1990".
For the CalDoc call numbers, Aleph treats the number before the decimal point as a whole number, and the number in the cutter after the decimal point, as a decimal number. For the HAIKU call numbers, Aleph treats the number in the cutter after the word "HAIKU" as a whole number; it should be treated as a decimal.
Why is the system sorting the CalDoc call numbers correctly, but not the haiku numbers?
Resolution:
"HAIKU" is not a legitimate classification number. (An LC classification number consists of 1-3 capital letters followed by a number from 1 - 9999.) The Aleph lc_call_no routine looks for the first number in the call number, assumes it's the classification number, and treats it as a whole number.
To address this:
* change the second indicator for the HAIKU call numbers from "8" to something else
* create a separate index for these HAIKU call numbers
* in the tab_filing entry for this index omit "lc_call_no". Additional Info |
