DSXchange

Hadi,

PX does not have hashed files, the equivalents for your purposes are datasets in PX jobs. You can do this in one PX job, using either permanent datasets or termporary ones for your lookups.

If you run out of space the merge stage will abort with an error - no possible way of "missing" that error, and the solution to that problem has kept all those disk manufacturers in business over the years :D

You need to enter the head/tail/awk command in the filter command.

you can view the UNIX man pages for head & tail & wc and the awk command has whole books written about it.

Kris, I tried in my 7.5.1 version and had the same problem. I would submit this as a bug to IBM/Ascential through your support provider. In order to work around this problem you might want to consider writing your 2 files in a fixed-width format with no quote characters or separators so that the mer...

Edward, the easiest methods are to keep your job that creates and writes this sequential file simple and to not include the trailer write in the job itself, but as either a simple UNIX level command or even another DS job which writes to that sequential file in append mode. I would pass the number o...

Add a ";" so that the engine knows that it is supposed to be a SQL query.

No, the jobid and UNIX pid are not the same. It think in some places the pid is displayed, but DataStage has a another internal number for processes which is used, and the standard process-id and internal job id display in the PORT.STATUS command actually truncates long PIDs.

Compare the number of colum separators in your source file line 64 with line 65 - I bet they are not the same!

Are you inserting 5 rows per minute into the DataStage job log files? (This is a very small amount and could not, by itself, cause I/O issue on the UNIX machine) or do you have 5 multiinstance jobs per minute writing to the same log file? If so, how many records does you log file have? What kind of ...

The error message is clear, you have defined a column in your metadata that does not exist in the file. If you have some rows that have less columns than others you need to handle that in your sequential file definition.

how about a command like dsjob -logsum MyProjectName MyJobName > MyUnixTextFileName.txt from UNIX.

Does that mean the same query works in MSQUERY and doesn't in DataStage? Since the error message you got the second time around was dealing with userid and permissions, are you certain you used the same connection attributes in both cases?

And what happens when you try your query using MSQUERY? From you error message it looks like the DSN is incorrectly specified. If MSQUERY works correctly then it is worth looking in DataStage, otherwise keep the ODBC part separate and get that functioning first.

Hmmm... so you've declared an Excel sheet as a system DSN in Windows. You 've imported the metadata and loaded it into an ODBC stage in a DataStage job. The view-data is giving you an SQL error - have you specified your own SQL? If yes, please post it. If not, then click on user-defined SQL in the O...

What stage are you using to load Oracle? Do you have a reject link defined?