DSXchange

We experienced the same issue where "ulimit -a" reports different results from a shell and from within a DataStage job. It turned out, the LDR_CNTRL setting was the culprit. By removing this setting, ulimit reports the same values.

Thanks Ray - IBM will be providing a patch. Will see if that would work.

Just wondering if you found a solution. I ran into the same issue. We are using DB2 client v8 on the DataStage server and DB2 V9 on the database server. We are able to use both ODBC and DB2/API to query from DB2 V9 but DB2 Enterprise stage aborted with the same error. My next attempt would be instal...

This issue has been resolved. The change to remove EVALs works. Many thanks to all for your help :D

Thanks for saving me some work. Just getting ready to add the filter below and found your latest reply. Ran the new code multiple times today against the largest project and the error has not occured. Will continue to monitor the jobs for a few more days.

We found out that "INVOCATION.ID" is one of the fields that we can use in the SQL. Also decided to bring the FULL.TEXT and not portion of it back. The new SQL now looks like. SELECT @ID, "TYPE", TIMESTAMP, "FULL.TEXT", "INVOCATION.ID" FROM #rtLogFile# WHERE @I...

I have seen this before. I think you need to learn to create dictionary items and not use EVAL. It is less stable. Kim, I only want to bring back the first 8 characters of FULL.TXT so the EVAL "FULL.TEXT[1,8]" entry. Also, I need to find the invocation id and hence the EVAL "@RECORD<...

Thanks for the quick response. The job is scheduled to run at 6:00 everyday on all DataStage servers. It usually fails on Sunday morning and on large (500+ jobs) projects. I have not been able to establish a pattern and will continue to track this. As far as using the UNNEST to normalize FULL.TEXT, ...

I would like to get a list of log entries for a job which were generated after a point in time. I am using a UNIVERSE stage with the below SQL. SELECT @ID, "TYPE", TIMESTAMP, EVAL "FULL.TEXT[1,8]", EVAL "@RECORD<7>" FROM UNNEST RT_LOG2547 ON FULL.TEXT WHERE @ID >= 0 AND...

hi rdsarbo, i had the same problem for which i used user defined environment variables as parameters and this works good . thanks, abhi. Anhi - Can you elaborate on the variables and what you did? We are facing the same problem. When importing table defs via ODBC, the entries are fully qualified an...

We are having problem capturing rows that are not loaded to the DB2 mainframe using the DB2/UDB API stage in a PX job. Here is the basic job design. Seq ---> Transform ---> DB2/UDB API | V Seq2 In the transform, we added an "OTHERWISE" contraint and chhecked the "Otherwise/Log" b...

Technical Support acknowledged that this is a known issue. The workaround was to set TZ=GMT. Once this was set, the correct date was inserted into the Db2 table.

Thanks

I am experiencing the same issue and wondering if there is an explanation. I have the following PX job: seq --> xfm --> DB2/UDB API There is a date field in the incomoing data with YYYY-MM-DD format. The coressponding field in the DB2 database is of type Date. In the tranform stage, I am using the S...

Klaus,

Thanks for confirming this. Not what I wanted to hear but oh well. It looks like DB2/UDB API is the only stage that is working for DB2 on a mainframe.

Our environment: DataStage 7.5 on AIX DB2 Connect Version 8 DB2 Database V7 on Z/OS The DB2/UDB Load stage does not work. The error message returned was " SQL1325N The remote database environment does not support the command or one of the command options. " The DB2/UDB Load Stage documenta...