A drop column should put an object in impaired status on IDAA

After a DROP COLUMN operation against a Db2 for z/OS table which is defined as an accelerator shadow table, and a subsequent online REORG to materialize the change, the table is not reported as "unimpaired" but a subsequent load operation fails with AQT10082E.

IBM answer in case : for altered or added columns we check the altered timestamp in the catalog. For drop column we don't have that. There are other possible sources of information but are not reliable. We could compare the number of columns in DB2 and IDAA but we have the non-offloadable columns like XML that could also cause a difference . Its works as documented

we cannot quite agree with the this answer/analysis. It is true that Db2 removes the column metadata from the catalog. What we do not understand is why the accelerator should not be able to compare the two schemas (the schema in the Db2 BLU database in the accelerator with the Db2 for z/OS schema).

For us a drop column is like any other DDL change, a change which impairs the table and does not allow any subsequent operations and as such should put the table in an impaired status.

As part of our monitoring process we run a check for impaired objects every day to to check if any table was overlooked(impaired tables existing on IDAA) and we repair them. These tables are impaired and have to be reported as such. As of now our automatic check and repair job does not detect them and we have an abend the next day.

The suggestion to have a best practice and reload these tables once changed does not always function. We have different deployment processes and this can and does get overlooked there at times. We have to have a process in place to get everything running smoothly after a deployment (without human intervention.). A deployment script can contain hundreds of changes and not all to a table on the iDAA. We need a process to find and reload them after deployment.