DSXchange

Describe - fully - the lookup keys that you are using for each of the lookups, including their data type and nullability. Describe also the data type of the field from the source input whose value you are passing as the reference key to each reference input. Explain fully what you mean by "failing" ...

That's up to you and your data - it's nothing to do with the join itself. If there are duplicates on the left input to a left outer join then, yes, you can get duplicates on the output. It's all in the definition of a join.

You need a null handing property - for example Null Field Value or Null Field Length - which informs DataStage what to write into the text file to replace a NULL. Text files don't really have data types - they just have text - so there can be no concept of NULL in a text file, just a pre-defined rep...

Also make sure that relevant environment variables, such as DSHOME, are set for the user ID under which the script runs. I've seen people let scripts run from cron as root, and root does not have DSHOME set (at least not by default).

Point 1: diagnosis is nearly impossible while operator combination is in effect. Lose it.

Point 2: why Unicode?

Point 3: what is the format of TRAN_DATE, and what is the format string in your date_from_string() function?

Give us a View Data from both inputs.

(You can probably predict that I'm going to ask...)

So, what has changed?

(It may or may not be in DataStage, it may or may not be in Information Server. You have to be the detective, with your trusty baseball bat for eliciting information from other IT professionals or management.)

If CleanupFileOut is an after stage subroutine with a compatible COMMON declaration, then it's in the same process and should be able to access the variables declared to be in that COMMON area. If CleanupFileOut is an after job subroutine then it's in a different process and would not be able to acc...

You can't.

What you can do is assign the required value to one of the user system variables (@User.Return.Code or @USER0 through @USER4), have the routine return 0, and have the User Variable access the system variable. This will work because they are all in the same process.

I think you need to check the level of authentication to Information Server and, if they are OK, the credentials that user has as a DataStage user or administrator.

Disabling operator combination, at least temporarily, will allow you to narrow the focus of your diagnostic investigation.

"WHERE condition" is a property of a Filter stage.

I'm thinking you may have identified the wrong job number, because DS.CHECKER did not complain. If you deleted the job from Director and that was successful, then the "support files" are gone too. SELECT NAME FROM DS_JOBS WHERE JOBNO = '<<Job number>>'; will report the job name associated with a par...

Not permissible in a Filter stage. SQL functions are not supported. You need to use a Transformer stage either to do the filtering or to generate an actual length number that you can use in a downstream Filter stage. Or use string_length() or ustring_length() - as appropriate - in an upstream Modify...

Search the forum.