Loss of non-MARC fields caused by full authority/bib export and reload
- Article Type: General
- Product: Aleph
- Product Version: 18.01
Description:
I have inadvertently caused a major problem during our recent full authority/bib reload.
When I exported the records with p_print_03 to send to Marcive I chose to output in sequential format then used p_file_12 to convert to MaRC format.
During the conversion I did not choose the Convert alphanumeric to MARC option and so lost all the non-MARC tags: LNK, CAT, SYS, STA. These 1.6 million bibs minus the non-MARC tags have been loaded into prod, overwriting the original records.
I am now trying to recover from this error.
Our Test region contains a copy of the data from just before the authority/bib reload. I plan on:
1) Use p-ret-01 in Test to get a file of all bib sysno's
2) Use p-print-03 in Test to output sequential records containing CAT, LNK, STA and SYS tags
3) Use p-manage-18 to append these to existing records in Prod
Questions:
1) Is this plan workable?
2) Is there a better way to do this?
3) What indexing will have to be done after?
4) What is the ramification of not having a SYS field in the current records? I notice that many of our Test records don't contain that field either.
Resolution:
> 1) Is this plan workable?
<<js Yes.
> 2) Is there a better way to do this?
<<js I don't think there is.
> 3) What indexing will have to be done after?
<<js That depends on what indexing option you specify in submitting p_manage_18. If you specify "FULL", z07 records will be generated which will be processed by ue_01. But with 1.6 million records that could take several weeks.
The alternative would be to load them choosing "None II" for indexing. Then no z07s will be generated.
* The loading of the records will update the z103 with the links for the LKR fields.
* I see that you do not index the CAT field, so no indexing would be required for that.
* The STA field is indexed in the WST Word index. So if you choose "None II", p_manage_01 will need to be run. You could do this in a parallel library, if you desire.
> 4) What is the ramification of not having a SYS field in the current records? I notice that many of our Test records don't contain that field either.
<<js The SYS number is the z00_doc_number. Doc records do not need to have any "SYS" tag actually stored in the record. The system displays this number where necessary. I'm uncertain just how your records would gotten actual SYS fields stored in them. In exporting the records, the system number should be in an 001 tag. See KB 8192-2153 for details.
You will need to set up a special tab_merge and tab_merge overlay with lines like these (for use with p_manage_38 or p_manage_18):
08 1 N #####
08 1 Y LKR##
08 1 Y STA##
08 1 Y CAT##
08 1 Y SYS##
08 2 Y #####
The effect will be to take just the LKR, STA, CAT, and SYS fields from the pre-load record.
Or, as an alternative, you could extract *only* the above fields for these records when you run p_print_03 and then run p_manage_18 with "If Updating Current Records" ... "Append fields to a record".
- Article last edited: 10/8/2013