DSXchange

The command from UNIX is "mkdbfile" and several threads here have information on that, including this one.

sd_ds - I went to search and typed in "ds_ipcgetnext" and got 38 different threads as a result. Most of those looked quite informative.

You have a sporadic error and the text is "Unable to allocate communication resources". Is DB2 on the same machine as DataStage? Is the database or network extremely busy or loaded?

Different flavours of UNIX require slightly different coding. I would suggest you go to Google and search for "shell script ftp {your unix}" to get samples on how to do this.

Since the default is used when a value that doesn't conform to the datatype arrives (i.e. a space in an integer) it works for a sequential file, but since Oracle data is strongly typed the default can be defined but will never be used.

How did you determine that the connections are open? Have you identified the UNIX pids associated with your running job(s)? Once you do that, you can use the "truss" command to see what they are actually doing. Are they using CPU or IO time?

There are several ways for doing this. Each site has different procedures and access rights - you would need to talk to your host administration team to find out which path they allow for remote job submission or scheduling.

Does your oracle load have many columns? It would be best to narrow the problem down to a single column and then to the row causing the error.

You will need to supply some more information in order for anyone to make an analysis. Are the jobs really running or do they just display as running in the director? What sources and targets do these jobs use and can you see if sessions to the appropriate database are actually still open? These two...

This happened months ago. The DataStage engine was split from UV years ago and is still owned by IBM, so nothing will change as far as the uvsh command is concerned.

DataStage server is not strongly typed; actually it is not really typed at all as the underlying engine really only knows about numeric and string data. Thus your job's behaviour is as expected.

Change your query to Then convert the '*' character back into a <Lf> after removing all linefeeds; use some other character if the '*' appears in your text.

Your SELECT output is comin into your script on stdin, right? So just filter it with "tr -d '\n' " and you've achieved your goal.

Your are using "FMT '100L'" in your command, so if you have more than 100 characters the SELECT inserts a line break. It is easiest to filter those out yourself from UNIX or elsewhere.

What does a before-job call of " " df //UnixServer/fld1/fld2/Scratch/"
" return?