DSXchange

No problem. This just illustrates the need to not make any assumptions about environment in your scripts. This applies in general but especially when writing scripts for execution inside DataStage. We see tons of posts that basically say "My script works fine from the command line but not from DataS...

Simple answer is - don't use relative paths in your scripts. Fully path the usage of the 'a.ksh' and 'b.ksh' scripts. Either that or explicity 'cd' to the directory in question in the script so that is actually does become the current working directory. Then your relative paths will work. Either way.

If you have been disciplined in your use of metadata, there is the little 'beaker' button in Manager for Usage Analysis. Find the entry in the Manager for the metadata of the hashed file in question and the Usage Analysis tool will show you all jobs it has been used in. If you haven't been, then yo...

'Versioned Folders' need to be in a Project directory. Create a soft link there if your actual location is different.

Another thing to consider would be to switch to the native OCI stage rather than using ODBC.

Ok, so there is no other 'magic' compression other than what is native to the COMP-3 fields? Basically, all you've got is an EBCIDIC record in a database field. Fair enough. First of all, there are routines to unpack fun stuff like this and it seems like you've already found them. In a previous post...

The job get aborted with the error: Fatal: This jobtype is not currectly runable on this platform. Answer is right there in the message. While any version can be installed on Windows, only a very specific version can also run PX jobs on Windows - and 7.5.1A is not that version. A search for your er...

In the Administrator, all you are setting are defaults to be used whenever a new Sequence job is created. Those four options match the four options found on the General tab of a Sequence job and, when you create a new one, you've told it to 'check' (enable) that particular option automatically. The ...

dprasanth wrote:Can anybody suggest whether it is possible to do this?

No, it's not. Why do you think you need to do this? What are you trying to accomplish?

Hmmm... and where would this forthcoming paper be forthcoming, pray tell?

Try posting the link again, Kris - that one is no good. I think yours is from your own search results, you need the simple url like the one that shows at the top of this thread: m Should just have a 'topic number', then you'll be ok. I edited my post to reflect the thread you meant to link to - chec...

My question is more along the general line of "does each instance get its own thread and/or variables? Or are the variables shared?" Ah... not what you asked. You are over thinking it. Think of what the two jobs do without regards to the fact that they have a 'shared container' in them. Can you run...

Can they run in parallel? Yes. Without conflicting one another? Depends on what you are doing in the container.

It's just reusable code that gets compiled into your job. It's more about whether your jobs can run concurrently without issue, not just what is in the shared container.

If you don't need to know it, you could use it directly in a custom insert sql statement.

Sort stage.