DSXchange

Me, I'd do one of two things: * Ditch the "sysdate" parameter and just generate it inside the procedure, unless there are times when something else is passed in other than the current date / time. * Dump the procedure and do the equivalent in DataStage, which is what Kim suggested. Writing something...

I don't believe so... or at least I've never found an automated way to do that. Perhaps some kind of routine to farm through the logs?

About the only thing I could add is the last job status dump you find in the email (assuming you include that) is from the one that had a problem.

Jamesvanam wrote:the syntax I've used is {call procedure log_process(arguments)}

The syntax is simply "call log_process(arguments)".

HSBCdev wrote:I used the oconv(ColName,"D4-YMD") check

Use Iconv instead first and check the status. Only do the Oconv if the first step completes successfully.

As Kim mentions, set them up as a character string and then use iconv to try and convert them to internal format. Check the success of the conversion using the STATUS function. An example of doing this is fully documented in the online help for the Status function. I've found it's best to do this in...

Welcome to the Why The Heck Doesn't This Work Club! Many members have joined before you, so don't feel alone. This is a bug. As you noted, it translates the Parameters for the log entry but fails to do the same when it actually executes the command! There are rumors that it actually does work on one...

Actually I was wondering if there is a way to invoke a stored Proc from after SQL tab in the target OCI9stage. I'd be using the IN params from the JOB. Sure, simply "call" the procedure in the Before or After SQL tab. Not sure about the use of Job Parameters at the same time, give that a shot and l...

Fully Generated SQL should be avoided at all costs, IMHO. 'Quirky' is only one label for it. It is slow, in some cases generates bad SQL and you need to rebuild the entire thing (from scratch, unless they've fixed that) to change anything about the query. Yerk. Column Generated has no quirks from w...

There's nothing wrong with your SQL as posted. There are... issues with the View Data option.

What happens when you run the job? Also - I'm assuming you are using the Fully Generated SQL option, what happens when you try the same thing using Column Generated?

For Problem #2 - have you verified that you have an Oracle client installed on and have Oracle connectivity from the new server from outside of DataStage? If you can 'tnsping' or get to your target databases from something like SQL*Plus from it, that would narrow down the problem to an issue with Da...

True... and there are other options from the Notes side as well. I was involved in a project where the Notes database 'pushed' its data over into an Oracle staging table for me. First via something called 'Notes Pump' which was later replaced with something 'more better', I believe they were using J...

Search is your friend.

Here is one topic where Notes connectivity is discussed... there were a few more as well.

I wonder if it is a bug in datastage. Or maybe the way I'm using the routine activity stage is wrong. Neither, more than likely. What does your routine actually do? More importantly, what kind of value or possible values does it return? What you need to understand is what happens when you add outpu...

Double-check which ones you've hooked up to what. I've seen something like this when, say, the userid parameter is sent to the DNS parameter or something similar. If you go the the job's log after it fails and look for the entry that details all of the current run's parameter values, do they look fi...

If the job runs fine standalone but not via the Sequencer, I would guess you're not passing job parameters correctly. Are you using job parameters for Oracle connection (DSN, User, Password) and passing them to the job from the Sequencer?