DSXchange

When you have multiple keys it is sufficient to partition on just the first of those keys.

Most jobs will seamlessly re-compile and run identically on another OS, and going from one unix variant to another is less problematic than between Windows and UNIX. There is no magic method to convert scripts calling CA-Unicenter to automagically use Autsys if they contain scheduler-specific calls ...

Hello Christian, I think that you can take DataStage out of the equation, at least temporarily. from your command line in a shell, try to execute /usr/lib/sendmail -t -v -i <<//// Server: 192.168.1.13 From: procesos_dwh@pronaca.com To: cceron@softconsulting.com.ec Subject: Prueba Hola esto es una pr...

The most important question here is if you have "date" datatypes or "string" datatypes. "Date" has no format, it is an internal binary value and only gets a format when converted to a string, i.e. when writing to a sequential file or displayed to the screen. Assuming yo...

The copy stage is of no use in those 3 scenarios and will most likely be optimized out of the job at runtime.

<sigh> There is no iconv in parallel jobs. This is posted in the Server section. The solution is very different in parallel jobs. The timestamp data read from db2 into timestamp in the job is a "real" timestamp. The derivation you want is "daysSinceFromdate(TimeStampToDate(In.Timestam...

Is this a SERVER job or a PARALLEL job?

The values in the column in DataStage are going to be strings, so a substring will be sufficient, i.e.

DataStage server doesn't have a date or a timestamp data type. If you do an Iconv() from a date using the correct mask ('D4-YMD' in this case) the result is an integer (the number of days since 31 DEC 1967). If you do an Iconv() from the time portion of the string using the mask 'HH:MM:SS' then you ...

I would use the format 'D4-YMD' for the Iconv() and Oconv() functions. If that doesn't work then please tell us how "...does not like that..."

FranklinE - in this case the "binary" refers not to the transfer process but the datatype, which would then be a "PIC S9(6)V9(2) COMP-3" and would necessitate changing the program on the host side.

I wish I had encouraging words, but if it is any consolation, I've had to do the same thing several times before where somehow smething within a job caused problems and a re-code was necessary.

Unfortunately that is not the error code, but the source line number where the error was detected so doesn't help us any further. I've used that stage several times and have never had issue with it. You did define the output column as char(32), right? Try to make a simple job with just 1 of those co...

Your best bet is your support provider. I would replace the Netezza source stage with a row-generator, the output with a peek stage and see if the problem persists, that way you will at least have an acceptable test-case for support. How many columns and what datatypes are you doing the Checksum on?

I think that a bit more information is required.

- Does it always occur
- Does it only occur for one table or for all tables?
- Has this ever worked before and now no longer works?
- Since "commit" is mentioned, what are your commit settings in the stage?
- Can you read from this table?