DSXchange

So your job only has a source sequential stage, a sort stage and an output sequential file stage? If not, then in what stages are you using this column - chances are high that it's value is being changed elsewhere.

I am not sure of what problem you have. You posted in Quality Stage, but the error refers to DB2 and you gave z-OS as your platform.

Did you get this error using "view data" in the designer? Have you been able to view any other DB2 tables or is this a new installation?

What transform stages do you have?

That sounds like a bug, I have never seen anything like that. If you change the load method does the job still hang? Are these actual data sequential files or are they perhaps named pipes?

If you replace your output sequential stage with a PEEK stage does the job run? Also, do you have all access rights to "'C:\Ascential\DataStage\Projects\Ouput Files\Output.txt" (try deleting the file before a job run, and are you sure that the directory is called "Ouput Files" and not "Output Files"?)

Server jobs don't have a DATE type so there shouldn't be a difference for the sort stage. Where are you changing the datatype?

SQL0002N The bind file name is not valid

. this IBM page describes the error. What is you DB2 stage doing and do you have user-defined SQL?

In that case you should read with DOS format

No, that cannot be done from the command line.

Look at your TRANS2 transform stage. Somewhere in there you are performing a numeric operation (addition, subtraction, etc.) and the column data value that is coming in is a string and cannot be converted to a number.

And you are certain that this extra newline is not in the original file? If the file is a UNIX file it will only have 1 terminator (so don't use DOS-mode). Where in the last column is the new line - at the end of data (if so, what position and how long is the CHAR() definition) or is the last column...

If you dump your sequential file straight into another sequential file are the files identical?

With fixed length fields, how does a 0x00 end up in the last column? What tool are you using to determine this ("View Data" can't show nulls, so it must be some other tool)

Those are DataStage internal files used for the secondary keys of the DS_JOBS hashed file. Don't touch or delete them, otherwise the project will need re-indexing.

I doubt very much that these files have anything to do with your problem. Does your job do Oracle bulk loads?

vnspn - are you working with VarChar() or Char() columns? The 0x00 should not be present in the file. How are you determining that it is present?

Dsnew - there is a little tick box for named pipes in the sequential file stage.