DSXchange

Although I haven't seen that error before, the message indicates that DataStage dislikes the .v suffix on text files. What happens if you use another suffix in your job, does the error message go away?

If you print out the value of v_SQL_UPD1 at runtime and the SQL is executable then don't you think that the cause of the problem must be in your routine RtnRunSqlDo()?

What kind of error reporting does this routine do?

What "exception" message are you getting?

What display format does the web service expect the date to be in? DataStage will have to format the date to a string display format that the web service is configured to accept.

I recall having had similar issues a long time ago and it turned out that DB2 was configured to not accept cleartext but only encrypted passwords; I cannot offhand recall what the setting was called...

There is no "dsjob.exe" option which will give you this list. You could write a DataStage job/routine which outputs the list and call that via dsjob, which probably doesn't help you further despite answering the question. What is your intent or goal and perhaps someone here might be able t...

The limit might be set in the filesystem of your target drive, for example just copy a file into your directory, call is "x", then "cat x >> y" then "cat y >> x" until you go over the 2Gb limit, or get an error message. I know there are many other ways of doing this, bu...

You neglected to tell us what the column data type and size is in your Oracle target table.

Do you see any files larger than 2Gb in your target directory or just attempt to manually create a file larger then 2Gb there.

There is no DataStage limit to sequential file size, any limitation would be imposed by the OS and would cause a call to write() to fail. What kind of a stage is "F_1" - is it a parallel job sequential file stage? How is the path to the file specified and what are the runtime values? How l...

When you write to a pipe you need to have a listener as well, otherwise the job will hang - pipes are just buffered areas and when the buffer fills up the writer process waits until the buffer frees up. You can make a dummy named pipe reader by opening up a command line window / session and entering...

When writing DataStage should not be able to detect a difference between that and an sequential file target. What is your error message?

While there are a couple of algorithmic approaches to making your ADDRESS_ID more compact to fit in fewer bytes, the real reason for the join taking a long time has nothing at all to do with the size of the join key and is all about the partitioning and sorting of your two input links. As jhmckeever...

No, I'm stymied as well for an explanation. You've stated that normal hashed file write speeds are similar and I'll assume that the files are on the same disk drive as the 64-bit ones so that should rule out different disk partition types/ I/O speeds being the culprit Something is acting as a bottle...

I mean not after the mkdbfile but immediately after they were filled with data. If the source data is the same then both files should have exactly the same sizes immediately after filling. If they are not identical that would point towards different configurations which, in turn, might explain the l...