DSXchange

True... your advise to 'disconnect' the two processes is perfectly valid, which I should have mentioned. Regardless, I'd still use those commit settings on the portion that does the actual database work.

kkreddy wrote:how to get the joblog for different instance and sub job status

Same way as you would for a 'normal' job, you just add the invocation id to the jobname with a dot between the two. So you would use jobseq.jobb as the jobname when checking status or pulling the log information.

TNT_ASSET_ACCT_SID may in fact be a column in the table you meant to access, but it's not in the table you are actually referencing in the job. Hence the ORA-00904 error. Check your job carefully... perhaps it is mispelled or the wrong tablename is being passed. Or the right tablename in the wrong s...

Err... what 'same problem'? Start over from the beginning. Or post a link to the other conversation 'cuz we have no idea what you are talking about.

No, didn't say that. Just said that you don't need to use ODBC to access Oracle or Sybase... unless that's really what you want to do.

First question would be - is your DataStage server on UNIX or Windows? That answer will drive how you set things up.

drostnu wrote:i have oracle and sybase dbs running.

Neither of which require ODBC to access as there are 'native' stages available for each.

Um... no, you slide over one character at a time checking for four each time.

'Brute Force' does not imply complexity, per se... just relates more to the fact that the routine is iterating through the string a character at a time.

Equally true.

You could inline multiple calls to EReplace...

That's why I mentioned 'if available' for that Treat Warnings as Fatal option, not all stages support it. OCI does, ODBC doesn't for example. You may be able to leverage the Error Codes tab of the ODBC stage for that. Simplest solution would probably be to run your Sequence job from Tivoli, adding "...

Apparently, the preference is for a more brute force method.

Kind of late to abort at that point, job would have already finished.

Multiple ways. What stages are you using? Some have a check box to 'Treat Warnings as Fatal', that would do it. If you are using reject rows to capture issues, they can be set to abort after X rows - set that to 1. How are you actually running these jobs? The command line dsjob can take a -warn opti...

Oh... and if you do this, open up both the Array and Transaction sizes. If your DB is configured to handle it, consider using a zero transaction size so that restarts don't become a complicated issue.