We recently cut over from Optim z/OS v11.3 to v11.7 for both Data Growth and TDM. We migrated Optim objects by making a copy of the v11.3 Directory DB and its contents. We then used the installation upgrade panels to upgrade all the Optim objects in the new, copied Directory DB in DB2 and it becomes the Directory tied to v11.7. Same process we followed when we went from v7.2 to v11.3.
After cutover to v11.7 and running verification tests, we hit an issue using Optim Connect against our archive collections as it appears Attunity is not really using the index files tied to the archive files in the Collection being queried.
The collection is being queried via a Cobol program invoking z/OS version of ODBC and going against the Binding definition in Attunity. The SQL is a simple keyed query against a single table containing a dense index. There are about 80 archive files in the collection, so it's decent size.
We executed the exact same baseline test with same queries pre-cutover in v11.3 and the job ran in less than 5 minutes. We ran this test after cutover and the job ran for 4 hours before I killed it. Looking at the JESLOG and JESMSGS showed it opened all the VSAM index files, but then proceeded to open and allocate *every* file in the collection (these are virtual tape, so it's not quick) instead of just allocating the archive files that match the SQL criteria. I killed the job after sensing it was doing scans on the archive files as opposed to leveraging the index files.
Wondering if any other users have experienced this issue with Optim Connect ignoring archive index results after a migration to a new version of Optim? And if so, how did you resolve it?
Appreciate the help, thank you.
------------------------------
Keith Tidball
Progressive Insurance
------------------------------
#InfoSphereOptim#Optim