p_manage_37: unable to change OWN fields because they lack $$a subfield code
- Article Type: General
- Product: Aleph
- Product Version: 20
Description:
In running p_manage_37, these ABC60 records were not fixed because their OWN fields have no $$a. This is an example:
OWN L QRS
FMT L HO
LDR L ^^^^^nx^^a22^^^^^1n^4500
008 L 0412032p^^^^8^^^4001aaeng0000000
LKR L $$aHOL$$lABC01$$b001774037
<etc.>
I thought that p_manage_21 might be used to add this, but it wants a "Subfield and contents".
Resolution:
It's true that in order to specify a particular p_match_text ("Subfield and Contents") in p_manage_21, you need to have a $$a subfield code. But I believe we can omit that.
In a test, I filled in only the p_tag ("Tag"), p_string_replace ("Replace this Text"), and p_string_by ("With this Text") parameters:
setenv p_active_library "ABC60"
setenv p_input_file "jerry_test"
setenv p_output_file "jerry_out"
setenv p_update "N"
setenv p_param_file ""
setenv p_tag "OWN" <----
setenv p_first_ind ""
setenv p_second_ind ""
setenv p_match_text ""
setenv p_delete_tag "N"
setenv p_delete_sub_field_1 ""
setenv p_delete_sub_field_2 ""
setenv p_delete_sub_field_3 ""
setenv p_delete_sub_field_4 ""
setenv p_delete_sub_field_5 ""
setenv p_new_data ""
setenv p_string_replace "QRS" <----
setenv p_string_by "XYZ" <----
setenv p_new_tag ""
setenv p_new_first_ind ""
setenv p_new_second_ind ""
The p_string_replace and p_string_by do *not* require subfield codes.
The program accepted these values.
- Article last edited: 10/8/2013