DSXchange

Parameters and SQL Files are mutually exclusive. Only workaround I found was to maintain multiple sql file variations and use parameters in the filename to pull in the right one at the right time. Obviously limits just how dynamic they can be, however.

I've done similar things, so it should work - provided the space is there as you noted.

There are several attempts at links posted here, one even in my very own topic where I asked for a working link some time ago. None of them seem to be valid any longer and the quick search I attempted at the IBM site was fruitless.

AFAIK, none. You'd need the original Orchestrate manuals for that, Ray has posted this many times: "There is an Orchestrate Operators manual among the Orchestrate manuals. Your vendor ought to be able to supply you with a set at no cost. They're also handed out on IBM's DataStage EE classes.&qu...

Great! Now time to mark your post as Resolved using the button at the top of the page.

And if you run it on one node, does it work consistently?

This same script that creates the file with yesterday's date can also land that date for you in a flat file. Then a Sequence job can use 'cat' to capture that and easily pass the value on as a parameter to your job.

What stage? Sounds somewhat familiar, you might want to contact your official support peoples and see if there is a patch for this issue.

There's obviously code missing as there's nothing here to actually run a job. Does "FILE_PRESENCE" actually start and is what "did not stop" or did that happen before that? Use DSLogInfo() in your code to leave breadcrumbs along the way so you know where things go sideways.

Regardless of your experimental conclusions, any settings of this nature are strictly controlled by your DBAs on the Oracle side. What did they say when you showed them your error? You did involve them, yes? :? :!: And before Ray comes back and goes off, anything "kinda very urgent" needs ...

Dearest Moderator, please just delete this now as it has been duplicated over in the proper forum.

Of course. Your CPUs, quad or otherwise, have nothing to do with this. You simply ran out of allocatable memory, which is nowhere near the 7.2GB you think you have. This is 32bit architecture we're talking about here, after all. What is the default hashed file memory allocation size on the new serve...

Are any of these other "tables" really views as well and other views work fine, just not this one? Or is this the only view with an issue? In order words, is this a generic "view problem" where it doesn't work for any of them or is it a problem specific to this view?

Sounds like something out-of-sync between the XMETA repository and reality. From what we've seen for things like this, best to get help from your official support provider.

I'm curious as to the 'why' of this... is the target of your 'desired output' a database table for instance? Flat file? Something else entirely?