DSXchange

Date is a data type, and has a specific internal format. They will remain comparable in production.

It is only when folks start converting their dates to incompatible string forms that comparisons fail.

Perhaps you and they have different interpretations of "critical".

A critical issue for IBM is one that would cost them revenue.

You could convert the Unicode data to non-Unicode in an upstream Modify stage. Add a NOWARN specification.

But what's wrong with performing a Unicode comparison?

You can limit the comparison columns to just those ten, and all should be OK.

It's probably a viewing problem only. Send the data to a text file and see what there is to be seen there. Even then there may be an issue. If the encrypted data contain one or more bytes with \x00 the STREAMS I/O module used by the text file writer may interpret it as "end of string" and infer end-...

Are there separate "LANG" environment variables for the two databases? That might be one way.

Otherwise, without NLS enabled for DataStage (which would be overkill for your shop), I don't think there's much alternative than to code it yourself, particularly since you have those skills in-house.

There is (at least at version 7.5 and below) an issue with the DB2 Enterprise stage that prevents it from being used to work with data on a different platform. With DataStage on UNIX you must use the DB2 API stage to access DB2 data on AS/400 and mainframe platforms, via the DB2 Connect client softw...

That must've been fun to track down!

Edit the metadata post-import to get it right - to coincide with what your SQL is returning. The warning is only an alert - it doesn't necessarily mean anything bad has happened - it's alerting you to the fact that you're (theoretically at least) trying to shoehorn a larger data type into a smaller,...

There's nothing wrong with the IsNull() function.

You just didn't understand the implications of using Char(N) data type which, perforce, must contain N characters. It's unfortunate that this was never enforced in server jobs.

Get an operating system other than Windows or UNIX, one that permits multiple writers per file. Neither UNIX nor Windows (nor USS) permits multiple writers per file. This is NOT a DataStage limitation. If you want all the data in one file you are necessarily constrained to a sequential operation. Yo...

You should also ask your vendor to supply the Orchestrate manuals (which IBM sometimes calls the OEM manuals for DataStage) in which all is revealed. Indeed, anyone using the Modify stage without the Orchestrate Operators guide is just looking for trouble (there are certain errors in the Parallel Jo...

Welcome aboard. Yes it is possible, but two pieces of advice. 1. Export these prototype jobs before anyone gets to overwrite (forgets to "Save As") one of them. That way you can reinstate the prototype. Also figure out sanctions against transgressors, such as overwriting their work with the imported...

There is no such thing as a hash file in DataStage. A hashed file is a popular way to store lookup reference data in server jobs. They should not be used in parallel jobs, as to do so will thwart the automatic scaling capability of these jobs. Stop thinking like a server job developer and investigat...

To clarify, this only occurs when run from a job sequence? Try interposing an Execute Command or Routine activity between each pair of Job activities in which you will get the job sequence to sleep for, say, 30 seconds. This will give the file system a chance to flush the Data Sets to disk.