DSXchange

Execute the command bin/uv while still attached to the DataStage Engine directory. This will issue a message about the size of the shared memory segment. Ray, don't you always have to regen after making changes to .uvconfig, as Ken mentions? Shouldn't the command be: bin/uv -admin -regen Or is that...

Since DS/OCI Stage does not support LongVarChar, I specified a Varchar with a length of 9,999,999. Have you tried running a job with these settings and does Oracle mind? For 9i, max varchar2 length is 4K from what I recall and there isn't any way to declare it as unlimited in size in DataStage. And...

Woo-hoo! :D I'm almost afraid to post again, it's such a loverly number... whoops, never mind.

Use Job Parameters for all dynamic portions, which you alluded to in your first post. You'll need to build a process that determines the values a particular job would need and then passes them in as Parameter values. Without knowing your processing requirements and your expertise level with DataStag...

I don't see why not - as long as the metadata doesn't change. Have you tried it?

Will you be reusing these dynamically named objects? If not, you'll need to worry about cleaning up after yourself, deleting the hash file when you are finished with it, for example.

No, waiting using this Stage is "synchronous". Having said that... It seems like you could do exactly what you've laid out below and it would work fine: One Sequence that runs multiple (sub)sequences. Make no connection between the two series and they will (in essence) run in parallel - JS_1 & JS_2 ...

In particular those related to "semaphores" but if you haven't addressed this issues at all yet, it would be best to get together with your Admins to double-check all of the requirements listed in the Install Guide.

You don't indicate what hardware / operating system you are using, which can be important in cases like this. Also, in the readme for your server install, is the SQL Server Wire Driver you are trying to use supported on your platform?

And, as the OP has discovered, unable to be used in any fashion without a license for that particular product. You can sometimes find references to XE/390 stages in the online help for Server, for example the Lookup Stage. It does tend to confuse people, occasionally making them think they have acce...

Peter, While I can't add any permformance numbers, not having a comparable platform, I appreciate the effort you've made to quantify various methods and their 'performance'. One point is that you'll see several reference here to 'rows per second' being a somewhat meaningless metric. What matters is ...

I'm pretty sure that is just the way it works and I don't believe that you can "turn off" those kind of warnings. If you don't want to see them, AFAIK you need to ensure that your key combination actually exists before issuing the update by doing a lookup first. Unless someone can point out an ODBC ...

Nope. I'm running 7.0.1 and it still works like that.

You have to retrieve it using a VARCHAR data type. A big VARCHAR.

Soma - I'm curious if you ever got a resolution to this? In case anyone else commits the same sin and starts seeing the same helpful error messages... We had a job start throwing this same error yesterday and were stumped for a bit. It was in all ways a "normal server job", using OCI and Hash to pro...

If you are in that big of a hurry for a solution, expecially if you've got a POC on the line and have Sales Rep in tow - contact Support. That's what they are there for.

I don't have PX or I'd try to help you out...