DSXchange

All communication with DB2 will be performed on machines vheter2 and vheter3, possibly because these are the only one on which DB2 client software is installed. Most of the other processing will default to being executed on vheter1 unless stages are constrained to execute in node pool db2 (which is ...

The functions you require are StringToDate() and DateToString().

Research these in the Parallel Job Developer's Guide

You can create a parent sequence that looks after the loop within a day, and schedule this parent sequence once per weekday.

Are you able to remove Unicode from all the fields you are mentioning in the concatenation as a test? It may be that the internal result of concatenation is the "field" that is at fault here.

What you type in is for your user ID. DataStage jobs probably do not run under your user ID. Look at the second event in the job log to determine whether the PWD environment variable is set.

Date data type does not have a format - it is stored in a binary format. StringToDate() function must include a format string that describes the actual format of the input string, in your case %yyyy-%mm-%dd. To format that for output you need to convert back to a string, probably using a DateToStrin...

Essentially you have to include the numeric column headings' values as the sources for the pivot column code - given that they are constant, you can use a Transformer stage to generate the values.

No idea where the underscore is coming from, unless you have somehow managed to declare your decimal placeholder as "_". The leading non-significant zeroes are normal for Decimal data type - they indicate that precision is being handled properly. You can get rid of these by converting to a...

You forgot to include the code column in your Pivot stage as a pivoting column.

Oracle is ... different. You must ensure that the date you provide to Oracle matches the default date picture Oracle uses (or override that with appropriate functions). Oracle DATE data type always includes a time component. Therefore a query against the table is likely to return the time component ...

There isn't, in any version, a means to promote message severity. What you could do is to create an after-job subroutine to check the log for this particular message and generate a fatal error at that point, though any data processed by the job will remain processed.

In either a sequential file or a data set you could use a record schema that contains three fields, field1, field2 and "the rest" (as a VarChar), at the expense of some parsing.

Not true. Any named message handler can include handling of multiple message IDs. Further, you can attach more than one message handler to a job.

We are all presuming that you enabled generation of operational metadata when you submitted the job run requests. Can you please verify that this was done?

Your use of the extended property Unicode is inconsistent across the stage. A ustring[max=100] is a VarChar(100) with Unicode set, a string[max=100] is a VarChar(100) with Unicode not set. Find this discrepancy and fix it.