DSXchange

ds_newbie

In a job sequence you have results from one job that can trigger the next job or routine or whatever. There is a trigger that says if you have any rejects then apply this trigger to job2. So all you need is 2 icons or jobs in the sequence.

Kim.

Kim Duke
DsWebMon - Monitor DataStage over the web
www.Duke-Consulting.com

Don't forget that, in order to show the dependency of job2 on job1, you need to draw a link in the job sequence from the Job Activity that runs job1 to the Job Activity that runs job2. You will find that the Triggers tab then appears in the Job Activity that runs job1 and you can specify the rule under which job2 will be executed right there.

Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518

What is the "Expression Type" that takes care of this?

Raju

The "Expression Type" is usually handled 2 ways. Either you want warnings to go through or you don't. If warnings go through then one link has only Failed results going on to the next step. The other link is "Otherwise". If you want to trap warnings then "OK" goes on and the "Otherwise" is your failed link. I really see no use for more than 2 results but DataStage can do all those plus build your own results.

Kim.

Kim Duke
DsWebMon - Monitor DataStage over the web
www.Duke-Consulting.com

kduke wrote:The "Expression Type" is usually handled 2 ways. Either you want warnings to go through or you don't. [SNIP]

With DataStage 6.0, we discovered that the option for the Triggers are specifically for that situation. In other words, if you say "OK", it'll pass on OK. If "Warning", it will only pass on "Warning" and not "OK".

Thus we use Custom and utilize the $JobStatus variable, for example:

STAGENAME.$JobStatus = 1 OR STAGENAME.$JobStatus = 2

That will pass "OK" and "Warnings", a necessity when we are using Parallel Extender jobs (which apparently is in love with spitting out useless warning messages such as column propagation changes...)

-T.J.

You can have two links from Job Activity 1 into a Job Sequencer with its rule set to "Any" and a link from the Job Sequencer into Job Activity 2.
One link has "OK" as its trigger, the other has "Warning".

TJ

I should of said "I usually handle this in one or two ways". I like doing either an:

1) OK and an Otherwise
2) Failed and Otherwise

That way all results are trapped. It is cleaner than doing custom results.

1) will not allow Warnings to go through.
2) will allow Warnings to go through.

Kim.

Kim --

I agree with that method, and it works 99.999% of the time. However, just last week, I had a situation where a job crashed. Not failed, crashed. We were pushing that box a bit too hard, and triggered something that wasn't expected to be triggered. It is not a failed status, since the job just died without logging. My solution caught it beautifully, and I am told that the above solution will not catch it (nor anything with an JobStatus of 96 to 99. (Forgive me if the numbers are wrong, I got too much on my plate).

Of coure, my solution also work if you only want only one output link, although we've moved away from that practice now that we discovered the wonderful world of "AbortToLog()".

-T.J.

TJ

I did not know that. I another good tip. Thanks.

Kim.

ds_newbie wrote:I have job 1 and job 2. They both run a stored procedure and returns columnID value.
in job 1 I set up a transformer constraint that looks like this.
"[dslin1].columnID = 0"
"[dslink2].columnID = -1" Reject Row Checked.

in job2 i just output a sequential file.

how can i set up a job sequencer that calls job 1 and if the columnID = -1 then execute a command otherwise run job2?

HELP![xx(]

BTW - If I read your original post correctly, you have both a constraint AND the reject row checkbox checked in Job1? Did you want both the constraint and Reject logic to apply? Unless I specifically want the added logging provided by the reject checkbox, I shy away from EVER using it. My preference is for the obvious-ness and self documentation of a nice clean constraint.

One additional note that may help when structuring your job sequencers. You are not only limited to STAGENAME.$JobStatus and $UserStatus, but to any variable in context (as Ray pointed out some time ago in a previous post).

It's important to understand what variables are in context and which are not. Most variables within the sequencer code are not useful and would be out of scope or context with each compiliation (since each compilation yields a different variable name) so what are you left with? You are left with things like err$code etc... I raise this point because it is important to note that any valid variable (and job parameters are variables) can be used in the custom trigger. I have gotten pretty fancy with some of the things I have accomplished using parameters or "in context" variables and wanted to let you know that this is available.

The documentation or help does not outline this, although with a little poking around you can generally accomplish your task.

Regards,

Michael

mhester wrote:One additional note that may help when structuring your job sequencers. You are not only limited to STAGENAME.$JobStatus and $UserStatus, but to any variable in context (as Ray pointed out some time ago in a previous post).

I agree. However, I am still unsure on if there is any possible way to update a job's parameter value, and have it pass back onto the Job Sequencer, and used as a variable for other jobs -- sorta like a function's parameter being returned with a value.

This option would open up a world of possibility in design for our ETL jobs. This, along with dynamic column definitions would, in our view, reign DataStage as equal or superior over custom C++ codes we've been using.

(Yes, PX have column propagation, but... it is so ugly, and there's little you can control on what can be passed or not. We want a situation where we know that a subset of a table could be passed on, but the fields varies between each clients we are developing for. A lot of our programs are duplicated due to difference in 'outside columns' -- columns that have to be there, but is not being 'transformed' or 'modified'.)

-T.J.