Redefining Alternate index

[anuthereaper]

We recently had a situation where a job was failing when it was trying to write records into an AIX file. We found that there the number of duplicate AIX keys were beyond the calculated limit which resulted in a boundary violation.

However, to rectify the situation, the production support guys ran the job after deleting the AIX file and then redefined and rebuilt the AIX file after the job completed successfully.

I would like to know the method they followed was correct and how come that worked. Shouldn't we get the same/similar problem while redefining the AIX for a VSAM which has too many duplicate AIX keys?

[William Collins]

Ask them for their explanation. Dig into the manuals, and see if it is an automatic update of the AIX when records are deleted from the file (assuming it is not an ESDS).

Alternate indexes can seem convenient, but carry a large overhead. Try to not use them in batch. If that is not possible, remove the alternate index, do any batch updates, then rebuild the alternate index. Every night. This will use much fewer resources. Also look to use them as little as possible.

Write some small programs and do some tests. For batch, you'll find two-file-match and extract-to-new-KSDS may give you big performance improvements, depending on how much the alternate index is used.

[anuthereaper]

I found my answer. I had a look at the out of teh step which production support was using to rebuild the AIX.
IDC1646I 1729 EXCESS PRIME KEY VALUES FOR AIX KEY F0F0F0F0F0F0F0F0F0F0
IDC1653I PGCP.VSAM.PRD2.CMSA.AMDHZ.A1 BUILT WITH ERRORS
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 4

This tells me that there was 1729 more duplicate AIX keys that the file could not handle. The job actually gave a RC of 4 but there was a step to set this to 0 just after which is why the job didn't fail. On digging a bit more I found that these 1729 extra records are dropped.

In response to your comment:
The AIX we are dealing with is of a file which is part of a cobol/Mainframe based product being used in multiple countries as part of our installation. So we cannot change that. However I do get the message that we shouldn't be using AIX unless we really really have no other option. Thanks for that.

[William Collins]

For "online" programs, alternate indexes can be very useful. In batch, however, heavy use (a ball-park figure for "heavy" is perhaps 5% of the records on the file, or less, not tried to evaluate it recently myself) is a performance killer. Easy to code. Runs like a dog with no legs.

Zeros in your key looks like some default value. If there is never a search using that key, then it is not problematic in itself. A thing about the design of a file with an alternate index, is to be very aware of duplicate values and their impact. That key should not have 1700+ duplicates, although you also may be stuck with that.

[academyindia4]

<< Content deleted By Admin >>