IBM Mainframe Forum

Hi,

Another quick question, I tried to delete just the alternate index which will be entended and rebuilt the alternate index. Just wondering if this will be ok. or do i have to delete the whole cluster? and rebuild all the indexes?

thanks.

I haven't tried it myself, but I can't think of any reason you would have trouble deleting the path, deleting the alternate index, redefining it, rebuilding the index, then defining the path again. You would definitely want to take those steps in order, though. Each alternate index has its own file structure so you don't have to redefine them all if you need to change just one of them.

thanks robert Will just redefine the alternate index ,
btw i have anither question, would it be possible to recreate the same alternate index if the vsam file has already been updated?
for example i will build alternate index for my vsam file on day 1.
then on day 10 after the vsam file has been updated, i would attempt to buiold an alternate index for it, Can the alternate index be identical? or is it to be expected for them to have difference?

Hello,

I'm confused. . .

Can the alternate index be identical?

What does this mean? Are you asking about the definition or the content? If you define/build an alternate index, it will contain data from all of the current entries in the file. I'm not sure where "difference" comes into this. . .

I suspect i'm misunderstanding something.

First thing to remember: an alternate index cannot be built unless the base cluster has data already. So the VSAM has already been updated, as you put it, before the first AIX is defined.

With one caveat, you can delete and redefine / reload the AIX whenever you want and there will be no impact to what is stored. The caveat is: this only holds true as long as the AIX record length is long enough to hold all the duplicates (assuming you have duplicates). If the AIX record length is too short, I wouldn't bet on the same primary keys being picked up -- since the primary keys may have been added out of sequence, building the AIX may change which primary keys are available. Of course, if this happens you've got other problems anyway ....

thanks.
Sorry for the confusion. what i meant was the data does not match .
what i did was for example.

Day1 I copied the production VSAM file, and I built an alternate index for it.
day5, I made another copy of the production VSAM file and built an altername index for it.

When i compared the data in the alternate index , there were differences, is this to be expected since on day 5 the production vsam file already has updates ?

for the definition of the alternate index they are exactly the same.

archiegaw wrote:thanks.
Sorry for the confusion. what i meant was the data does not match .
what i did was for example.

Day1 I copied the production VSAM file, and I built an alternate index for it.
day5, I made another copy of the production VSAM file and built an altername index for it.

When i compared the data in the alternate index , there were differences, is this to be expected since on day 5 the production vsam file already has updates ?

for the definition of the alternate index they are exactly the same.

Btw any tips on how to identify the difference of data in the alternate index built?
problem is the VSAM file is receieving lots of updates to it.

Day1 I copied the production VSAM file, and I built an alternate index for it.
day5, I made another copy of the production VSAM file and built an altername index for it.

When i compared the data in the alternate index , there were differences, is this to be expected since on day 5 the production vsam file already has updates ?

Of course this is to be expected -- any updates to the base cluster on days 1, 2, 3, 4 or 5 until you rebuilt the alternate index would not be reflected in the day 1 version but would show up in the day 5 version. Why would you think anything else?

Hello,

Maybe it will help if you explain what you are trying to accomplish rather than what is causing the confusion. . .

From what you've posted, all is working as it should. . .

Hi ,

I've attached below the original mail minus the names:)
what user wants is to extend the alternate index due to problem below
I was able to build an alternate index, with same characteristics but with difference in data due to time the alternate index was built. I'm uncure how to justify and pinpoint the differences since the vsam files gets updated daily.




Email sender,

thanks for your answer.

Unfornutaley they are only 5 cancelled codes that can possibly be deleted (to confirm) and there are still 41 codes to link to 666666.
Therefore the alternate index size needs to be increased accordingly.
Please keep us informed on the resolution of this issue.

Regards.


--------------------------------------------------------------------------------
EMAIL2

Sender,


I believe your suspicions re. the alternate index for code 666666 are correct. This code is linked to 99 other codes via an alternate index which has reached it's currently defined maximum. No other codes index to anything like 99 other codes. Is it possible that the list of other codes could be rationalised or reduced in some way? This would be a lot quicker for you. Below please find a list of all the codes that 666666 is alternate indexed to.

Regards

007002
007021
007039
007075
090003
099110
195003
208101
407001
423601
430601
700003
700007
700009
700018
700024
700026
700029
700067
700069
700072
700080
700081
700086
700088
700091
700093
700094
700096
700098
700132
700144
700153
700154
700162
700165
700167
700168
700171
700182
700183
700184
700187
700191
700192
760031
760101
760121
760135
760137
760138
760201
760241
760601
760611
760612
760613
760674
760692
760701
760702
760711
760712
760901
760902
760961
760971
760972
761251
761251
761531
761532
761533
761534
761611
761651
761671
761672
761673
761831
761861
761891
761911
761921
761921
762051
762081
762181
762341
762351
762371
762461
762961
762991
763051
763061
763171
763172
763181

--------------------------------------------------------------------------------

EMAIL1:

see attached error message whille attempting to update the BCF.

It may be related to one of the alternate index since the user was updating the same field to a lot of broker codes and it was succesful for the first ten to twelve updates then it failed for the next ones.

I hope this help.

Please assign this issue to the mainframe support group.

Thanks and regards