This content has been marked as final. Show 6 replies
There's a thread on here which might provide the answer you seek.
Creating job, ran successfuly, but not seen on dba_scheduler_jobs
ora-27475 is a questionable error, could this be from a user defined error?
This limitation is by design. You cannot pass user defined arguments to steps because the user is not calling the steps,1 person found this helpful
just defining rules. The order of step execution is in general not deterministic.
There are meta arguments passed to the step job, for example job_name and job_subname which are the master job
name and the step name respectively. Another useful one is chain_id which is the log id of the master job run.
This can be used as a key to a table the user would create to use as a global context for a job run to pass state.
not sure what you'd want me to read. This link has nothing about chains in it.
thanks for the explanation about the (potentially) non-deterministic execution order. From this point of view I can understand the limitation, although I still find it quite uncomfortable to use the workaround that Eddie pointed me to.
On the other hand, if a step of my chain calls a program, maybe I just don't care about the execution order but I know that the arguments I need to pass to this program are the same at any point in time. That's exactly what happens when using the workaround with job metadata and a lookup table. From this point of view I cannot understand the limitation.
OK, there can be chain configurations where different steps could call the same program and then with different arguments -- but even that wouldn't be possible with this limitation in place. Now, with that woraround I'll have to care about another table, clean it up after job execution etc... not so good, don't you agree?
Enlighten me, please, should I have missed something.
Yes, for constant arguments and other simple scenario's I can understand your frustration.1 person found this helpful
As for the housekeeping of SQL tables. You can easily modify a chain to create a new start step NEW_STEP
by adding a rule TRUE -> START new_start, modify all rules which start the old start to include AND NEW_START COMPLETED
and creates the table in the NEW_START program.
Then add a new end step NEW_END that cleans up the table and adding a rule "OLD_END COMPLETED->START NEW_END".
You may have to add some more steps/states if you have end rules with errors but you get the idea.
Edited by: Eric337 on Jun 17, 2011 10:10 AM