p_manage_02: build of z01_id2 fails; duplicate keys found

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

Description:
When running manage_02 on course reading library abc30, step 3, on page 84 of upgrade express 18-19, I get an error that it cannot create the ABC30.Z01_ID2 Oracle index. In the job log I see: "Error : Only 3 indexes out of 4 for table z01 were created"

The error message in the $data_scratch log for the z01_id2 is "duplicate keys found".

When I try util a/17/2 for abc30 z01_id2, I get the following error:

ORA-02219: invalid NEXT storage option value

Resolution:
This ORA-02219 is like KB 8192-424. That was caused by entries with "OK" (the letter "O") in the abc30 file_list where you should have "0K" (the number '0"). That was the case here too.

But even after making this correction, when the site ran p_manage_02, they still got the (duplicate keys) error on the z01_id2.

When I went onto the server I found that the abc30 util g/2 last-acc-number was 0 -- despite the fact that the z01 records had z01_acc_sequence's with a variety of values greater than 0. This was clearly wrong.

I found that though my initial run failed in the same way that the site's did, the second, third, etc. runs were OK. The site later tested it themselves, submitting it via the GUI, and found that it also worked for them.

Something changed. I have a hypothesis as to what this was....

The z01_id2 is an Oracle index built on the z01_acc_sequence. The p_manage_02 job (/b_manage_01_c1 program) assigns the z01_acc_sequence. It does this by taking the z52 (util g/2) last-acc-number and adding 1 to it.

What I noticed when I first did util g/2 for abc30 was that the last-acc-number was 0 -- and though I didn't pay attention to it at the time-- it was in the wrong place in the file. The parameters are supposed to be in alphabetical order. last-acc-number is in the right position now:

1. change-file-name 0 y S c
2. last-acc-number 5075 S
3. last-barcode-number 0 y S c
4. last-bnb-number 0 n S BLN
5. last-doc-number 2655 y S
6. last-file-number 156 y S SAV
7. last-loader-log-no 0 Y S
8. last-long-acc-number 0 y S
9. last-temp-file 0 y S D
10. last-usnaf-number 0 y S NAF
11. last-word-number 0 S
12. last-z0101-sequence 0 y S
13. last-z34-sequence 0 y S
14. last-z418-app-number 0 y S
15. library-lock-status 0 y S
16. max-z02-count 0 y S
17. session-id 0 y S SESSION-

but when I first did util g/2, it was somewhere around 13 or 14. I'm thinking that, because of this, the program was not finding the last-acc-number parameter and not incrementing it.

What I can say with certainty is that the last-acc-number moved from where it was originally (to the correct position). Maybe something with the z52_id Oracle index -- but I (Jerry S.) never did anything with that either.

• Article last edited: 10/8/2013