DSXchange

Dynamic hashed files have the effect that, even with the "shrink" set, the OVER.30 overflow file never shrinks. A "RESIZE HashedFileName * * *" cures this and can increase performance significantly.

That would not be a hex or binary viewer. The goal is to get the numeric representation of what is in that character.

Remember that DB2 has no "truncate" function, there is a "LOAD FROM /DEV/NULL OF DEL REPLACE INTO YourTable" equivalent, though.

Ha - I reread the post and saw "while compiling" - that isn't data dependant at all. As Sainath has stated, you have metadata differences.

The environment settings are stored in the project directory in the file DSParams. I would think that your error is not due to different installations, but due to different data between the two environments.

The "dbms_lob.substr" function is for clob and clobs alike. Declare the column as varbinary and then don't do an explicit character conversion. You could then work witha column export stage.

You are going to

Approach the problem from another angle and ask "what has changed between now and when the jobs ran correctly". Also, asking UNIX admins if the systems are "OK" is similar to asking a chef if his or her food tastes good.

Are databases involved?

Ahh, sorry - when writing to Oracle it is easier, in your case you would need to use user-defined SQL and of the form

You can declare the data type as binary in order to read it.

No, not directly. You would need to filter these entries out manually. Perhaps modify your script to get a list of jobs, then loop through each one and drop jobs that generate the -1004 error from the output.

What happens if you turn off row buffering - does the problem go away? Which of the stages reports the error?

Do you know which stage this is happening at?

sshettar wrote:...but having problems executing the statement...

What type of problems?

I would recommend using the repository for which you have a DBA.

Partitioning isn't directly related to what you asked - you just need to ensure that both parts of the join have identical partitioning.