- Article Type: Q&A
- Product: Aleph
- Product Version: 20
Why is field STS (item status code) from expand program expand_doc_bib_loc_usm (added in xxx01/tab/tab_expand) only created when the item has a 2nd. call number but not when the item has only one call number?
The system creates PST fields of type “HOL” from HOL records, and of type “Z30” from items.
Out of these PST fields, only subfields $b, $c, together with the subfields defined in the “correct_852_subfields” environment variable in $alephe_root/aleph_start, are taken into account when the fields are unique-sorted. For example, the following PST fields are first created:
$$0Z30$$1000239081000010$$bMED$$cGEN$$oBOOK$$d02$$y$$fN$$rXXX60-000070963$$n $$hA 71477
If you take only subfields $b (sublibrary), $c (collection), and $h (call number), you get identical lines:
So, when the system unique-sorts the PST fields, it takes only the first. The second is filtered out (as it is identical).
But since subfield $d with the 02 item status (out of which the “STS” field is built) is only in the second PST field (of type “Z30”), the “STS” field is not created because this PST field is filtered out during the sort.
When a second call number is added, another PST field of type “Z30” is created, this time with $h containing the second call number.
$$0HOL$$1XXX60-000070963$$bMED$$cGEN$$hA 71477$$4Medicine Library2$$5General
$$0Z30$$1000239081000010$$bMED$$cGEN$$oBOOK$$d02$$fN$$rXXX60-000070963$$hA 71477-2$$3Book$$4Medicine Library2$$5General$$6In-library use
Now we don't get identical entries because call number in $$h of Z30 is different:
Thus, the new PST field is not filtered out and an “STS” field is created out of the item status in subfield $d.
This is how the system works and nothing will be changed. You might change the correct_852_subfields environment variable in $alephe_root/aleph_start to contain more subfields.
Subject: Publishing Services
- Article last edited: 10/8/2013