DSXchange

Not sure what nutcracker patch we installed but we are sitting on FP1, no other DS patches installed. Having a quick look JR41654 looks to be a nutcracker fix which applied to the issue we experienced so that may be the patch we installed, the lucky chappie who installed it is not around at present ...

In the same place here (8.5 with FP1)

OCONV(ICONV(DateParameter,"D-"),"DYMD[4'',2'',2'']")) Slight tweak to avoid the convert. (I'm assuming "D-" handles Jan/Feb etc as never dealing with such formats I have no idea). Regarding OP, why all the different date string formats? Consistency through your jobs wo...

Try both ways and then you know.

All down to complexity of query, loads on each server, size of each server etc etc

PaulVL wrote:partition 0 row 464 will colide with partition 4 row 64.

Is that California sun getting to you?

Not quite, partition 0 row 464 will output as 1464 (and partition 4 will be 564)... they are adding 1 to the partition number.

Time to get out the sun

Just given it a test run and it would appear if you provide an input column list to the sequential file, that is all you get in the sequential file. Put a copy stage after the transformer stage, set Force=True, RCP on and have
no output mappings

And just to be sure... your delimiter is set to the comma?

Try changing your delimiter and see if it handles the field differently. Can't say I've ever seen this issue (although rarely use comma as my delimiter)

This sounds suspiciously like the same issue as stated in this thread. Perhaps you can answer the same questions which were asked of DSRajesh in that thread? If it's not the same then there is something spooky going on... two people with the exact same issue down to the row number... [cue]twilight ...

What the OP is saying (at least as how I first read it) is that the source file already has these columns and he wants them to appear in the end file despite not being used anywhere within the process (shared container or otherwise). As such, you shouldn't need to define them in the copy stage/trans...

We applied a patch for Nutcracker and it does seem to have stabilised our system, although we do go through the occassional restart so maybe we're just masking the issue. Still, more harmony in the workplace at the moment so it must have helped at least a bit

DSRajesh wrote:I need to do all the work

Who needs to?

Asking for assistance is one thing... there's an existing routine called DSGetRunJobInfo that would be your good starting point

(@INROWNUM - 1) * @NUMPARTITIONS + @PARTITIONNUM + 1) would be a much tidier way of generating unique numbers. While jwiles example is a good reason why not to follow the concatenation route, it only really applies when you have 9+ partitions (or 10+ if you don't use "+1"). No obvious reas...

As with ArndW, make sure you use BigInt to start with, sometimes DataStage throws out superfluous errors based on a previous error, fixing one ends up fixing them all. On a side note, is that your full query? You aren't joining your two tables so going to get a cartesian. Run the query in a sql edit...

If H.2 = 'OS' IF A.5 ='CJ' Then '5' Else If Substrings(A.6 ,1,1) = 'C' Then '1' Else '4' Else '0' In your original code you had "H.3" not it is "H.2", are you sure you are using the right columns? However, as H.2/H.3 = A.2/A.3, what purpose is your hashed file actually playing i...

We probably should have been able to ascertain that True... if read properly... :? As for issue, not that I know how well it would convert or how a real->decimal would be treated in DataStage but the "Real" datatype allows you to specify a format via the ln_format property, it does state ...