DSXchange

But it was stated that the source column is of type Date. Therefore you can not use date_from_string().

But it was stated that the source column is of type Date. Therefore you can not use date_from_string().

Probably not, because there is no DSExecute command.

If you consult Help, you will learn about the DSExecute subroutine which is something you use in routines.

Disable operator combination and see whether that has any impact. There are several messages in what you posted dealing with operator combination.

There is no way within DataStage to accomplish this task without a Transformer or Build stage. If the data are coming from a file you might use a Filter command, if coming from a database you might use an SQL expression. But these are not what I include in "within DataStage" techniques.

Have two job parameters, one with the current month, the other with the previous month, in the desired format for the file names. In a before-job subroutine use ExecSH to execute an appropriate mv command, for example mv /usr/Data/MyFile#PrevMonth#.csv /usr/Archive Use the second (current month) job...

Why would you even expect "non-English data" (more technically, I guess, characters outside the specified map set) to be handled properly by a particular character map? (Almost?) all maps incorporate the "English" characters, so choose the one that accurately represents how those other characters ar...

View Data runs its own osh script (you can choose to look at it in one of the dialog screens). This script has hit some in-built row limit. Try limiting View Data to only a few rows, then increase it gradually.

That's what I was trying to get at with my question. In too much of a rush, I guess.

That's what I was trying to get at with my question. In too much of a rush, I guess.

You might like to convert the @FM characters in the command output to commas (for example) or one of the "standard" delimiters handled by the Start Loop activity.

That's no surprise. If it's stopped it can't write anything. Neither could you.

You will definitely need NLS enabled for DataStage to process Taiwanese data. Taiwan uses traditional, rather than simplified Chinese, so there are very many more Unicode codepoints to be mapped. Even so, the map should fit into shared memory without any tuning being needed.

If you are running this from an after-job subroutine, then that job is not finished so you can never get the "job finished" message from the job log.

The job isn't finished until its after-job subroutine is also finished.

Or maybe the other way around, assuming the aggregates will be smaller. Load each into a hashed file, stream in from the parent, perform a lookup against each hashed file, and output to sequential file stage. What do you wish to do in the event of a non-match?