DSXchange

Normally the paths used for files are runtime parameters so you can look it up in the log files, or use the dsjob command and a shell script to parse the path out.

There is no builtin mechanism to do that. I would make a loop that runs through many iterations and then put a Execute Command or Routine Activity stage in which checks to see if the time condition has been reached, then branch and exit the loop.

Craig,

at least you didn't get a message

"Sorry, Craig. I cannot open the pod bay doors"

A Date datatype has no format. How you display the Date column is dependant upon the display settings of your target system, that is where you need to look.

You can lookup the PIVOT stage or could write your own DataStage routine like below: Combiner(ColA,ColB) EQUATE LF TO Char(10) Ans = '' ColACount = DCOUNT(ColA,',') ColBCount = DCOUNT(ColB,',') IF ColACount#ColBCount THEN Ans = 'Error, counts do not match' ELSE FOR i ...

The only way to transfer jobs between projects (regardless of what server they are on) is via the DataStage export/import methods. This export file, either in .dsx native format or as .xml, can then be ftp'd.

Or are you looking at the data files used in DataStage?

When you run a job, the complete environment is put into one of the first log entries. Run your job and check to make 100% sure that your LIBPATH at runtime contains "/Datastage/DSEngine/lib"

That is quite strange. What UNIX are you running on? If you execute "$DSHOME/bin/smat -x" do you get output? Also, if you attach to $DSHOME then issue "bin/uvsh" do you get the ">" prompt in UniVerse (if yes, enter "QUIT" to exit.

That is quite strange. Do you know if you are losing the 1st or the last message?

If you are getting a "date" data type then the data is in internal binary form and the field actually has no format at all.

Is this a simple or complex query and is the table partitioned?
The Oracle error message is pretty clear:

The OCI call was invoked when another call on the connection was in progress.

.

It will work with no need to modify anything.

The problem is most likely in Oracle, not in DataStage. Take your SQL from datastage and use your favorite access tool (SQLPlus,TOAD,etc.) and you will see that you get the same error.

Search helps - check out this post.

Checking "first line is column names" makes DS skip that line - regardless of contents or format.
If you have multiple empty lines then pre-process as Ray suggested. You can even do a simple UNIX "sed '/^$/d' InFile.txt >OutFile.txt"