• Article Type: General
• Product: Aleph
• Product Version: 18.01

Description:
I'm attempting to update an authority record using p_manage_18. I've already determined match points and have two records which I wanted to overlay. I attempted this using p_manage_18:

csh -f $aleph_proc/p_manage_18 ABC10,nduauth_match_junk,tom_reject_overlay,tom_log_overlay,OLD,,,FULL,MERGE,M,,MOVERLAY,MARCIVEAut,

I have info in tab_merge showing:
MOVERLAY merge_doc_overlay 02

and in tab_merge_overlay, have the following for my 02 version:
!20071121tah - Create a new merge set for Marcive Auth updates
02 1 Y 001
02 1 Y 050##
02 1 Y 053##
02 1 Y 086##
02 1 Y 090##
02 1 Y 096##
02 1 Y 644##,5,*IND*
02 1 Y 645##,5,*IND*
02 1 Y 646##,5,*IND*
02 1 Y 667##
02 1 Y 680##
02 1 Y 690##
02 1 Y UPD
02 1 Y CAT
!
02 2 Y #####

With these settings, it would seem that things like 410, 400, and 670 would update, and I made some odd changes in those fields to see the updates that would be made. But they are not updating.

At the same time, the records are getting processed because I'm getting new CAT records which show that the load was run.

What am I missing here to get the right information updated if it actually came in new.

Also, I'm seeing that I got an 001 filed created during the p_manage_36 portion of the procedures and that that field is being duplicated in the overlayed records. Why did 001 get created and why is it becoming a repeating field rather than being overlayed on subsequent p_mange_18 runs.

Resolution:
From Jerry:

p_manage_18 switches the preferred record. In tab_merge_overlay, the "1"s need to be "2"s and the "2"s, "1"s.

This is described in KB 8192-10007.

From site:

Yep, that was the problem. Once switched, things worked as expected.

• Article last edited: 10/8/2013