$$7 (item process status) field not being included in PST field
- Product: Aleph
- Product Version: 20, 21, 22, 23
- Relevant for Installation Type: Dedicated-Direct, Direct, Local, Total Care
Description
The PST field -- generated by the expand_doc_bib_loc_n_x expands -- does not include the $$e/$$7 (item-processing-status subfield code and text), for example:
PST0 L $$0Z30$$1000149432000010$$bMAIN$$cMAIN$$oBOOK$$y0$$fN$$rXXX60-09949$$n0$$hTP690.2.U6 T48 1974$$3Book$$4Main Library$$5Main Stacks
even though the item *does* have a z30_item_process_status value.
Resolution
The xxx01 tab_expand had:
WORD expand_doc_sort_loc_a
and
U39-DOC expand_doc_sort_loc_b
As described in the https://knowledge.exlibrisgroup.com/@api/deki/files/46879/How_To_Use_Location_Expands.dochttps://knowledge.exlibrisgroup.com/@api/deki/files/46880/Parallel_Indexing_Alternative.doc doc, attached to this article:
expand_doc_sort_loc_a
Sorts uniquely the PS1 (ITEMS + HOLS) creating PST for each unique PS1. PS1 match for uniqueness is on sublibrary, collection, call number and status. (This would be used at sites where the items and HOL are not linked. North American sites would *not* use this.)
expand_doc_sort_loc_b
Sorts uniquely the PS1 (ITEMS) creating PST for each unique PS1. PS1 match for uniqueness is sublibrary, collection, call number and status. Note that the HOLs that do not have linked items already have PST created directly (in expand_doc_bib_loc_1_c). (This would be used at sites where the items and HOL are linked. North American sites *would* use this.)
Thus the solution is to
* change the expand_doc_sort_loc_a occurrences to expand_doc_sort_loc_b
* confirm that the util f/4 now shows the $$e and $$7:
PST0 L $$0Z30$$1000149432000010$$bMAIN$$cMAIN$$oBOOK$$eRM$$y0$$fN$$rXXX60-09949$$n0$$hTP690.2.U6 T48 1974$$3Book$$4Main Library$$5Main Stacks$$7Remote Stacks (Library Annex)
* restart ue_01 so it gets the updated tab_expand
* resend doc 000149432 to the server (using GUI Cataloging or util f/1/13), and, after it's been word-indexed
* confirm that the wrm=remote retrieves it
* Assuming so, then rerun manage-01 to have all of the PST $$7's be properly indexed. See the "Parallel Indexing Alternative" doc attached to this article in regard to the best way to run manage-01 (at sites too big to run it overnight).