DSXchange

I reckon the users have not got their umask set to 002 or, perhaps, that they're not members of the same group.

Become sure! Your initial post told us it was Line Feed.

(This may well be valid data. You can not unilaterally change the data. You may need to handle these charaters rather than simply eliminating them.)

Simple enough - %* picks up everything from the command line. You'd think they would have had it in from the start.

If they can they will post. Be patient. Many folks are on vacation at present.

Have the DBA monitor the query that is actually being received by Oracle from DataStage, and to capture its execution (explain) plan.

Perhaps dspradeep is being paid by the hour?

You can use the DB2/UDB Enterprise stage without DPF, provided you do not want to make use of any of the DPF functionality (primarily parallel processing with partitioned tables). That db2nodes.cfg is missing (from one or more DataStage nodes) is a far more significant issue. Unless that is present,...

Total production run time includes overheads that are not counted against any one stage (operator). Further, stages are executing simultaneously, so that the elapsed time for any one stage could potentially be the same as (or nearly the same as) the job itself.

My "such as" indicates you can try with ANY other SQL client.

Which map have you specified? In particular, have you specified a map that handles Cyrillic characters?

I wud suggest you to run the same job in production with less number of records... Please strive for a professional standard of written English on DSXchange. The correct spellng of the word is "would", not "wud". More pedantically, perhaps, a better formulation is "fewer re...

The "problem" in DataStage server edition is not one of EXACTNUMERIC but one of PRECISION. The maximum PRECISION setting is 14 significant digits. I guess that stems from the fact that the technology was invented in the mid 1960s, when numbers that large simply did not occur in commercial ...

Welcome aboard.

The choice is really about how you want to capture changes from Oracle, either by scraping transaction logs (from the redo segment) or by having triggers on update, insert and delete transactions. The latter approach requires that you have set up these triggers, of course.

Then why do you talk about DATA.30 and OVER.30? These simply do not exist in the XMETA database. As far as I can determine, U has one job in XMETA but not in DS_JOBS, and two jobs in DS_JOBS but not in XMETA. How this situation came to be I have no idea. Your suggestion of restoring XMETA would not ...

I think you will find that software piracy is definitely a crime in Switzerland.