Just as a warning to other people using a combination of DB2 v8 and DataStage v7.
What we've seen during our upgrade is that DB2 v8 returns a lot more warnings than DB2 v7 and DataStage v7.5 handles them in a strange way which screwed up some of our jobs.
E.g. a simple insert into a view is done in DB2 using an ODBC stage. DB2 returns a warning that the insert is too complex but it does insert the row, DataStage handles this is as a rejected row but in the end a commit is issued by DataStage... so now you have the situation that you have the rows in DB2, but they were also processed as rejected.
Ogmios
Problems with combination of DB2 v8 and DataStage v7.5
Moderators: chulett, rschirm, roy
Problems with combination of DB2 v8 and DataStage v7.5
In theory there's no difference between theory and practice. In practice there is.
We ran into a similar problem with SQL queries several months ago. DB2 would return a sqlstate 437 warning, indicating that it thought the query was too complex, and DataStage would treat the warning as a fatal error. Sometimes using the DB2 plug-in and executing SET CURRENT QUERY OPTIMIZATION = 9 as "before" SQL would get around the problem, and sometimes it would not.
We finally filed a support case with Ascential (# 431966) and back in July they sent us a patch consisting of new versions of uvsh and dsapi_slave. DataStage now ignores the SQL0437 warning, and the problem is solved.
If the insert issue is causing you trouble, you might want to ask Ascential if they can provide you with a patch for it.
--James
We finally filed a support case with Ascential (# 431966) and back in July they sent us a patch consisting of new versions of uvsh and dsapi_slave. DataStage now ignores the SQL0437 warning, and the problem is solved.
If the insert issue is causing you trouble, you might want to ask Ascential if they can provide you with a patch for it.
--James