SEO

I am trying to import some data from ixf files into several different
tables in my database. Everything worked on a test database. When we
tried to do the import into our "live" database one of the imports
failed. It produced a SQL0901 error, and the message that it reported
in the error said (Reason "Found zero CLOB.reset".) Note that there
are no Clobs, Blobs, Long VarChars, or anything like that in this
table. The table constists of chars, integers, doubles, and smallints.

Later we found out that the "live" database was running at a different
version then what we had created the ixf files on. The ixf files were
created at 7.2.0 and the "live" database was at 7.2.7 (Fix Pack 9).
Once we upgraded our test machines to 7.2.7 we could now reproduce the
problem.

We then tried to upgrade our test machines to 7.2.8 (Fix Pack 10). To
see if that would fix our problems. It did fix the problem with this
perticlar import command however a different import failed saying the
insert_update statement could not be processed because either all
fields in the ixf file our primay keys or there are no primary keys in
the target table. I know that the ixf has values that are not part of
the primary key and after doing a select from the system tables I have
verfied that the primary key was intact. It was decided at this time
to stay at 7.2.7 and try and find a work around for the orginial
problem.

I did find a work around for the import problem. If I used the load
command instead everything worked fine. However, when trying to find
this work around I found out that a delete from that same table causes
the same SQL0901 error with the same error message. Note that as far
as I can tell this error only happens on one table. Both the import
and the delete statements work fine on the rest of the tables
including the child tables for the table that is causing problems.

I then looked at the db2diag.log and looked up the hex error code
which was 877E. That error says RDS (Remote Data Service) Error.
Overall not very helpful to me.

I then tried a few things. On a different instance I created a brand
new database that was exactly the same structure of the database that
was causing problems to see if I could reproduce the same problems on
a different database. I could not reproduce the problems. I then tried
to see if a database that was first created at 7.2.0 and was now at
7.2.7 could reproduce the problems, and that couldn't reproduce them.
I then took a backup from a different client and restored it on my
machine to see if I could reproduce the problems and I could. That
client is running db2 7.2.0. This seems really weird that I can
reproduce this on some databases but not all.

I then exported all of the data from the table to an ixf file, dropped
the primary key for the table, drop the table, recreated the table,
load the data back into the table, and readded the foreign keys. Both
the import and deleted still failed.

I also know that the childern tables are not causing problems because
I tried to delete a record that did not have any childen and still got
the error. Also, dropping the table invalidated all index and trigger
so I know that its not a problem with them.

I then tried to do a db2dart on the database and the tool reported
that there were no errors in the database. Note that I did have it
examine the entire database not just the table that was causing
problems.

The db2diag.log says that the function sqlrr_dump_ffdc is causing the
problems, however this does not help me as I do not have access to the
db2 code.

Right now upgrade to 8.1 is not an option for me,restoring from a
backup is not an option, and going back to 7.2.0 is not an option.

Does anyone know what is going on and/or how we can fix this problem?

For all your -901 needs please call IBM support.
You should bever see a -901, hence all will lead to an APAR

Cheers
Serge