p_file_20_report: "Succeeded to DELETE table z308"
- Product: Aleph
- Product Version: 20, 21, 22, 23
- Relevant for Installation Type: Dedicated-Direct, Direct, Local, Total Care
Description
Despite the fact that (as seen in util f/2/5/1) all of the USER-KEY-REC segments for certain patrons have ACTION "I", the $data_scratch p_file_20_report produced by the file-20 Service has an "<action>DELETE" as the final action for these patrons, followed by: "Succeeded to DELETE table z308. cur-id IDnnnnnnn". (The preceding actions for patron IDnnnnnn all show "Succeeded".)
We find that all of the USER-KEY-REC segments specified in the input file *are* present in the patron's z308 records after the load. Why does this message appear? Does it indicate a problem?
Resolution
Though this is puzzling, in every case, we have found that the result is that the patron has *exactly* the ID's specified in the input file USER-KEY-REC segments. It seems that this is a deletion of the old ID's which are being replaced by the new (exactly the same ID's). It may be that if the USER-KEY-REC segments had ACTION "A" ("Add") rather than "I" (Insert), we would not see this. In any case, we suggest that you ignore these messages. If you find that there are cases where an input ID is not present in the patron's resulting z308s, please open a Case to your Aleph Support team, referencing this article.
Additional Information
The "Succeeded to DELETE table z308" comes from ./error_eng/p_file_20 message 5001:
5001 0000 L Succeeded to $2 table $1. cur-id $3.
It is written in the b_file_20_a program:
CALL IO-PROC USING
CUR-ACTION
BUF-ZNNN-RECORD-DATA (I)
ERROR-CODE
END-CALL.
IF ERROR-CODE = ZEROS
THEN
IF SW-PLIF-MODIFICATION NOT = "Y"
THEN
MOVE 5001 TO BUF-ZNNN-RECORD-ERROR (I)
ELSE
...
- Article last edited: 27-Mar-2018