DSXchange

That would imply either that someone else already used those key values or the routine has been edited and its behaviour changed. What do you see if you dump the contents of the hashed file? All you need for that is a job with a Hashed File stage set to 'Use account name' with 'SDKSequences' as the ...

Nope, one hashed file with (in your case) 20 records having the name you pass in as the key. And yes, for every new key value you pass to the routine it creates a new record with a starting value of 1. If you don't like this behaviour, you can always copy the routine and edit it to your heart's cont...

No, it doesn't. That function just returns the name of the most recent controlling job, not everything that could ever 'control' it. From the help: Name of the job controlling the job referenced by the job handle. Note that this may be several job names separated by periods if the job is controlled ...

yogeshcts wrote:i have tried using external source file also to read the xml file but of no use

How so 'no use'? That is the answer and the preferred method over the sequential file stage in PX jobs. For example:

http://dsrealtime.wordpress.com/2007/12 ... -a-source/

That static hashed file lives in each Project where you've used the routine, so you should be able to find it just with a wildcard listing or a more better find command: find <ProjectDirectory> -name SDKSequences -print And since it is an account-based hashed file, you cannot simply copy it over to ...

Yes, that's how it is meant to be used - you put the path to the "SQL file" in the user-defined SQL area rather than the sql itself. However, I never had success with it in the DRS stage and there's no such option in the ODBC stage itself... only ever got it to work for the OCI stage.

Perhaps.

And with all the discussion of redness it seems *are* talking about a reference lookup in a transformer stage, but (in my best Dana Carvey George not W Bush imitation) "Try'n to make a point here, people". <waves fingers around>

DataStage 'mission'?

Right... and this supposes that the 'last successful run' information is still in the log. If you really need this, you'd be better off capturing it elsewhere after every job run.

ragunathan13 wrote:We have changed our system settings to incorporate chinese characters.

Also, what exactly does this mean? You changed what?

What did abort your job? Something else, I'd wager.

Checked their posting history and their last post was three years ago, so don't hold your breath. Just exactly how 'same' is your problem? I'd suggest you start your own post, with your details and messages and then see if anyone can help.

No, you can join inside database stages as well. Trying to make a point about the lack of coherent details of the job design in the original post and the assumptions being made, and a weak attempt to get clarification from the OP before people went too deep into the alleged 'solution'.

No thanks. And was wondering when you would make an appearance. :wink: Sorry, I didn't mean to ruffle any feathers. I know it worked well for the PeopleSoft models and how much it meant for the product. And yes, tangential to the main discussion but the OP did throw it in their list so so did I. I'm...

Of course, but you'll need to write your own 'job control' for this. Read the list of parameters into memory, interogate the job for the parameters it needs and set any you have that match.