DSXchange

Ok, the MAXUPROC isn't applicable after all, just assume I made you do it out of sheer malice

Do you have root access and could manually change the hard file limits to something much larger? Under what user have you configured your datastage jobs to run (is it really 'dsadm'?)?

According to the documentation the fileset will have better performance, since the data is stored in correct form. I've not noticed significant performance differences, but lookup filesets cannot be 'viewed', which is a distinct disadvantage.

what is not working? Are you assigning the string value as the return value?

The logic is to take your year/month, add one month, create a date of the first day of tht month and then subtract a day.

Could you please enter "lsattr -E -l sys0 | grep maxuproc" (not necessarily applicable to your problem). Also, what are the hard and soft limits for user dsrun in smitty?

abhi - what is different between your suggestion and the original post? I can't see a difference.

The CFF (Complex Flat File) stage uses data contents to determine record type, i.e. if the first byte contains one value it is record type 1, on another value it is record type 2, etc. In this case it is line dependent, so I would read the data as one VarChar() column then use @INROWNUM in a transfo...

No, the scores just reflect the text version I posted, showing 2 nodes and 1 node respectively for those stages.

I have a strange problem that I can't really understand and am trying to simplify in order to submit a bug report. One job uses two sources that each go through a filter stage and from there to a sort stage and then to a join stage; the single stream then goes through a transform stage to 2 output d...

Welcome to DSXChange, ntr.

While I don't know what 'sena topics' are or how they apply to real time or to null handling I would like to ask that you describe your question in a bit more detail.

srinivas - the %mi" works in Oracle, but is the wrong format picture for DataStage.

What is your OS? This can be done in the user setup, or in the user ".profile" by executing "umask 022".

Just to see what might be happening, add another transform stage where you convert your timestamp back to a string and see what the value might be. Also, disable operator combination and see which stage is giving you the warning message.

Perhaps it is "nullable no" on output, that would explain the behaviour

In that case you need to follow the same approach, but at a stage level instead of at a column level. Remove stages until the job runs, then the last stage removed is triggering the problem and you can drill down from there.