How to get MARCIt! to overlay its own deleted records

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 18.01

Description:
Some MARCit records marked as "new" in the original MARCit export file are getting "match"ed with existing records when put through the p_manage_36 process, and then are getting rejected because the "match"ed record in ALEPH was previously marked for deletion (the "LDR" field for the existing ALEPH record has a "d" in the 6th character).

MARCit export is identifying these MARCit records as "new" to the catalog, because they were formerly marked as "deleted" by the MARCit export process and are now once again available to us. However, those older MARCit records marked as "deleted" in the "LDR" field by the MARCit process appear to be sticking around in ALEPH, and that's causing manage-36 service to match these "new" records with the older "deleted" record's SYSNO. Then, when the manage-18 import service runs using the "match" data, ALEPH balks at importing the new MARCit record over the old "deleted" record, and throws the following error to the $alephe_scratch service log:

Cannot overwrite a deleted record. Record 003519424 is written to rej file.

So, two possible questions:

(1) Are we *not* running something in ALEPH that would actually delete those records from ALEPH so that the MARCit import process can successfully add those "new" titles to the ALEPH? (In other words, do we need to be running a separate step to get those "deleted" records actually deleted?)

or

(2) Does it sound as if the MARCit load process is defective, in that it *should* allow updates on "deleted" records to make them active again?

Resolution:
It appears that the thing that is missing in your processing is running p_manage_33 to delete the records after the MARCIt! load changes the LDR to call them "deleted".

What p_manage_18 is doing is to leave "deleted" records in the database, nearly as is except with the leader byte 6 value set to "d". Officially, these records are deleted, but they are, of course, still in the database. Additionally, they are also still in the indexes, so they affect the matching of records. But manage-18 has a "rule" that says it cannot overlay "deleted" records. This would leave you in an untenable position if there were no alternative. However, I believe the alternative is to run manage-33 after a successful overlay load of MARCIt! records. You would need to identify records that had been "deleted" by the overlay process.

This could be done with specific criteria to p_ret_01 or some similar service (-- see KB 16384-8641 in regard to using p_ret_01 --), or might perhaps be directly based on the output of p_manage_18. Once you have a file of record numbers such as are produced by ret-01, you can use this as an input file to p_manage_33 to delete the records "totally". They are actually not completely deleted, but all of the information in them is deleted, so they should no longer affect the matching of records.

So, this is the answer to your question 1: you should add a run of p_manage_33 to your processing of MARCIt! records.

The answer to your question 2 should, by the addition of the process above, become irrelevant. Without investigating p_manage_18 any further, it sounds from your description that it rejects overlays of "deleted" records. But if these no longer active MARCIt! records are actually deleted by p_manage_33, this should no longer be a factor in the process.

Article last edited: 10/8/2013