DSXchange

This is something new in 7.5, I suspect (I haven't played with 7.5 yet).

Server side trace files are in the &COMO& subdirectory, while active stage trace files are in the &PH& subdirectory. Neither has the name form given in the original post.

The AND part of the WHERE clause and the GROUP BY clause have been entered manually on the Selection tab. T he parameter markers in the first part of the WHERE clause have been generated by the DRS because these are key columns and you're performing a reference lookup. For whatever reason, DRS uses ...

You need a separate DSN pointing to each workbook (XLS file).

Within a workbook, each worksheet (tab) is reported via DataStage metadata import as a "system table". It must have column headings and a proper columnar structure to work successfully as a data source.

If you don't start fooling in the database (SETFILE), DataStage CAN delete its own hashed files.

A fixed-width flat file is a text file in which the data columns are specified explicitly by their width. 100010SOCKET HEXAGONAL 12.3475012 100011DRIVER HEXAGONAL 29.5032017 A delimited flat file is a text file in which the data columns are specified as lying between a known delimiter character. Com...

Specifically, Ctrl-Z is the end-of-file marker in DOS. So this is a likely candidate if the data originally came from a Windows system. It's also a possibility that "UTF-8" on Windows and "UTF-8" on your UNIX aren't exactly the same; there are quite a few UTF-8 encodings out there. You can learn abo...

Have you satisfied all the "must do" aspects (see page 39-7 of Parallel Job Developer's Guide)?

The error message suggests that you've provided neither a schema nor a schema file (to describe the schema).

NLS is not really intended for translation of character sets, except from the various external coding schemes (such as UTF-8, GB2312, BIG5, SHIFT-JIS and so on) to and from DataStage's internal character set, which is an idiosyncratic encoding (called UV-UTF8) of Unicode code points; UV-UTF8 preserv...

Surely if, as your original post suggests, you have sorted data, you don't need to sort it again in DataStage. You can still use stage variables for counters even though the data aren't sorted, but all you get are blocks of 200 with no relationship to the meaning in the data. What's the requirement ...

You misread it. It was I who was being pedantic. :D Sorry if I caused any offence; certainly none was intended. ETL is a world in which taking pains to be accurate is rewarded by getting things to work correctly first time. Doubtless some of this rubs off on one's personality. And the other post to ...

Because DataStage helpfully substituted a zero-length string for the unassigned variable (Jobname), the only impact was that the logged message had nothing in the parentheses instead of the job name in the parentheses.

Can you create an extra output link to a text file and capture the values of Input.SysID and the values of the stage variables? If what you say is true it's a bug, with potentially catastrophic implications. There is no technical reason (apart from running out of memory) for losing information from ...

The error is in a call to DSLogInfo (presumably in one of your routines). CallerName is the second argument to DSLogInfo. Call DSLogInfo(Message, CallerName) Chances are you've used a variable name for the second argument and that that variable has not been assigned a value in your routine. ...

There is also a known bug in 5.1 (possibly 5.2) where Auto Purge settings are not even propagated into new job designs. I believe it was fixed in 6.0. For RIL I created a routine to add the //PURGE.SETTINGS entry in all job log files, which they run periodically. I believe they're now in the process...

None of that is DataStage.

What you've been doing is fooling around in a database that supports DataStage. If you hadn't wanted SETFILE in the first place, then you would have removed the hashed file via a check box in a stage.