DSXchange

No, afraid not.

aka the 'Java PACK', available as a separate purchase.

Well, technically that's what the Nested Condition stage is for as it's basically a user-defined 'branch' in your job flow. You can also manage this kind of thing with normal triggers. Where does this 'value of one of the output columns of the previous job' that you need to branch based on end up? T...

It's marked as a Server job.

You'd have to check and see what is different from dev to test. Version - client or db? Server settings? Anything other than the data itself, which I'm assuming is different. And if you don't see anything, I'd focus on the nature of the data then.

Still don't see any burning reason why UpCase wouldn't be working for you. And you still haven't said what happens when it doesn't "work fine". Posting an example of what comes out that you don't like would help tremendously. Why not just simplify things and get rid of all that extra stuff? No need...

If you know it won't exceed 3500, then there's no reason to use LongVarchar. What happens when you declare it as a simple Varchar of say, size 4000? If that still doesn't work, add a 'CAST' to your source query to cast the CLOB to that type/size.

Hardly ballistic. And while I can see mutliple developers doing just that, it would seem to be to be prudent to make mention of the fact... or at least change the wording a little! Otherwise you're just gonna get whacked with the dreaded DPRR - Duplicate Post Removal Request.

Confusing. What exactly is your problem? You seem to be saying that you get what you want to get.

UpCase will work just fine and convert a string to all upper case, so that shouldn't be an issue.

And you don't need DS390 to handle packed fields or 'mainframe' data, Server and PX jobs can just as well once the data is on their server. Check out the Complex Flat File (CFF) stage for one way to handle them. came to know that the packed field will get garbage values when it landed in to unix Onl...

It's only useful if you also own the DataStage TX product. If you do, it lets you run TX 'maps' / jobs from inside a Server (and perhaps PX) job.

Ok, I recall that now but I do believe it is the only applicable 'stage' answer. So if that's not an option then scripted extractions and loadings it is.

I'm gonna take a wild guess here and say... ODBC.

kcbland wrote:As for Sybase, you'll need to do something similar, like set SYBASE environment variable and another one I can't remember, plus set the SHLIBS as well.

SYBASE and SYBASE_OCS.

First thing would be to not pass it a bad filename.

I'd suggest passing back a negative number if there are errors in the routine. Add a third trigger that checks for a $ReturnValue < 0 and have it go somewhere... bad. The other two should be fine as is.