DSXchange

Because, as noted, DataStage is unpacking the value. You won't be able to do much in your script until you do something to unpack that field into display format - be it a DataStage job or some other tool. There's lots of utilities that can do that unpacking during the transfer from the mainframe tha...

Make it nullable in the lookup. If you really want a non-nullable result, handle the null in a Modify stage after the lookup and make that field not nullable from that point onward.

Still confusing. This 'comparison' you need to do, is it not in a DataStage job? Why would you need to see this from the command line to do that? :? Regardless, you won't be able to see the 'correct' value 'in UNIX' until you unpack the field and write the file out to a new location/name. And since ...

OK, now I'm officially confused. You said you're already handling it correctly in DataStage but that you were "not able to read correctly in unix" which makes sense as you'll see the packed version there.

So... what exactly is the problem that you have, a UNIX or a DataStage one?

Packed decimal / COMP-3?

Kindly have some patience. You waited what - a little over an hour before you bumped your own post? Never mind the fact that it's New Year's Eve and the edge of a big holiday weekend for most (I would assume) and normal people are probably off doing something fun tonight. Wish I was. In the meantime...

You already solved the problem. What you have in the file *is* a Varchar, you then need to use StringToDate to actually turn it into a Date datatype, if that's really what you need.

So... have you not compiled a job with a Transformer yet? Yes, you need to configure your APT linker and compiler variables properly for that to work but that's not your problem here.

Have you tried using the Web Console as Julio mentions here?

First suggestion - make sure the job is not being monitored by anyone. Have you done that?

dsjob -linkinfo

I personally wouldn't use the Sequential File stage as a source for this but rather what Ernie talks about in his blog post here.

This one, as a matter of fact...

viewforum.php?f=19

So i guess there are more reasons for this failure and you can't guess some solutions unless you know what is there in the job. I modified your quote slightly - a nice observation about trouble-shooting in general that some people don't seem to realize, and especially from where we sit on the other...

I don't really see how one versus many connections running the same set of SQL would really make a difference. Have you checked that your explain plans in 10g are still appropriate, what you saw in 9i?