DSXchange

1. Yes
2. Yes. Note that syntax should be " link.datecolumn1 <= link.datecolumn2 "

DataStage will perform implicit conversion of "link.datecolumn" to date type in the first case.

There might be more involved here as well, since MKS Toolkit requires that named pipes must be located at "$ROOTDIR/fifos", where the rootdir is the installation directory, usually "c:\Progra~1\MKS Toolkit\"

Do you have several projects? If so, try to login with your id in another project and see if the error message persists. I am not at a DataStage system right now to check, but there must be hashed file where the session information is written and you most likely don't have UNIX write permissions to ...

1. "Performance should be good". This topic is far too complex to discuss in a single thread. It depends upon so many different factors ranging from performance expectations (e.g. I have a window of 3 hours to load my data and it must finish within that time) to database SQL optimization w...

Can you confirm if this is a version 7 or version 8 installation? Can you login to the director and administrator?

No, that is not what Ray or I said. As written earlier, you transfer data to your DataStage job via the FTP stage then write a file from the job.

Use a dummy schema. You can declare the file to be FTP'd as having one column with fixed length and no line terminators. Write what you've transferred with same settings into a file and you've completed, in a very roundabout way compared with a straight binary FTP command-line, a binary FTP from Dat...

Go into your Programs -> IBM Information Server -> Documentation and, from the list, choose your appropriate language for "Programmer's Guide" in the "Websphere DataStage" section.

In your on-line help guide open up the Designer Client Guide to Chapter 11, page 187 and you will find that it uses the following syntax:

dsexport.exe /D domain /H hostname /U username /P password /JOB jobname /XML /EXT /EXEC /APPEND project pathname1

Your target is an integer column and thus, by definition, does not have leading zeros. If you want leading zeroes on displaying an integer column you will need to declare to the output format accordingly.

1. Yes
2. Unless you choose a block size of 1 and also commit your output every records, you cannot guarantee that there won't be an gaps. Neither of these two options is generally acceptable in production for performance reasons.

Generally it is best practice to include the $APT_CONFIG_FILE parameter in all PX jobs and keep the setting at "PROJDEF", this allows you to change either the project default to affect all jobs or to specifically target those jobs that need or require different configuration file settings.

Could the error be something as banal as the single "#" character being misinterpreted? Does the error go away when you remove the "#" (even if no rows are returned)?

Could you narrow down the "some transformations and some stages" part, since that is most likely where your error is happening. Make a copy of your job with just the input stages and put in dummy output stages (sequential files going to "/dev/null") and see if the job hangs. If n...

At Version 8 look into the "Programmer's Guide" to find those routines documented.