determining orphaned indexes?

[jsquizz]

I am working on a migration, and I am seeing a ton of what I believe to be orphaned indexes in my CMOD system.

07/25/2019 17:57:57   ADMIN        893118   Error   No       24   Object >17939FAAB< in Application Group >EEA< not found in node >centera<  Srvr->prod1 192.168.1.2 non-SSL<-
07/25/2019 16:19:10   ADMIN        893110   Error   No       24   Object >29934FAAD< in Application Group >FEA< not found in node >centera<  Srvr->prod1 192.168.1.2 non-SSL<-

Based on my research/digging through the logs, It looks like there was some type of storage set modification back in 2013. I believe a node was deleted or modified, due to some kind of TSM retention requirement change. I think it may have been done improperly.

My issue is that I am trying to do an extract and reload from our current system into a new system. and part of our recon process is going to be checking our current tables, and making sure that the row count matches after we are done loading, to make sure that we got everything.

Just wondering how everyone has handled situations like this before, or if I am even heading down the right path. Feedback is appreciated, as always.

[Stephen McNulty]

I had to deal with some orphaned indexes recently.

the following support document from IBM may help

https://www-01.ibm.com/support/docview.wss?uid=swg21392642

[jsquizz]

Thanks Stephen. This makes sense. These application groups all have different retention requirements than what most of our heavy hitters do, most of them are legacy too. I will continue to go down this route