DSXchange

My point was that TNS_ADMIN is not typically set so telling someone it is "to be looked for" may cause confusion when it is not found. Not sure why that would rate a from you.

Keep in mind the fact that you only need TNS_ADMIN if the tnsnames file is in a non-default location. Meaning other than $ORACLE_HOME/network/admin so it knows where to find it.

Do an exact search here for "fork join" or perhaps "fork-join".

Haven't checked in a while but Chuck Smith might under his ETL Tools link. I don't mean something that does exactly what you need but you'd have the source code so that if you found something close you could easily adapt it.

rberman wrote:I can also import the metadata

That typically happens on the client side... unless you are using the command line on the ETL server to do that?

If you are saying that Oracle connectivity is "fine" from the Server side of the house then I'd say you have everything configured correctly there. Others would have to verify that PX uses the exact same mechanism / variables to connect as well as I'm not certain and have no ability to che...

The first ORA message you posted shows that you did indeed connect to an instance but it was not in a running state. Which to me means you didn't connect to the one you thought you did if it is known to be up and accessible. Double-check which $ORACLE_HOME and tnsnames.ora file that DataStage is usi...

After Job ExecSH.

Because they were purged. At least that's what I thinking. It's a common 'issue' with MI jobs.

There is a filter but that controls the number of entries to show in an individual log. You can try bumping that up and see if that changes anything.

srds2 wrote:It is PIC 9(11) COMP-3.

Thanks. Just wanted to see if it was signed and that it was actually a COMP-3. Sometimes people have odd definitions of what "packed decimal" means.

First off, there's no emailing. Questions and answers go into the forum so everyone benefits. Sounds like you have the wrong compiler installed or with invalid options. Make sure you are using one that is officially supported by that release. Don't ask me what that might be as I have no idea, howeve...

Yes and no. There is a project setting for Auto Purge which controls when logs get removed. It can be set for X days or X runs and can be overridden at the individual job level. Don't forget that a MI job is still just a single job under the covers sharing one log table and each "instance"...

Odd reason in my book, we have a ton of "single job" parameters. We use them for data needed during a run that changes on a daily basis without regard to how many jobs may (or may not) need each one.

DSGetLinkInfo needs JOBHANDLE, not JOBNAME.

Which you would have seen if you'd followed the link James posted and read the actual formats needed rather than assume it was the same as Oracle or whatever other tool you are used to.