|
Job Dependencies: ([JOBA], JOBB)
| |
| |
Note here: --------------
I could not find anything in the documentation concerning this, but after a
few tests it is obvious that those square brackets indicate that JOBA already
completed, and that JOBB still must finish before JOBC may start.
>> Correct. The square brackets around the jobname JOBA indicate that this job
>> is already completed and the dependence of the JOBC on the JOBA is already
>> satisfied.
Anyway, once JOBC is started, both jobA and JOBB are displayed between
brackets, and when JOBC completes, all brackets are removed.
>> Correct. They both (JOBA and JOBB) are already completed.
So far so good. But how is this implemented? A customer wanted to create
a program using the scheduler callable interface that gives him the jobs
on which a job is dependent, indicating which of these jobs did already run
and which jobs still have to complete.
>> Use VSS$SHOW() to retrive the information about the jOBA and JOBB.
>> Then, examine the field record_flags of the ShowBuffer.
>> The bit 22 of the field_set2 struct of the RecordFlags union is
>> last_run_success. (This union is defined in the file VSSDEFS.H).
>> If this bit is set this means that the last run status is success.
We used the item codes NSCHED_SYNC_JOB_NUMS and NSCHED_NO_DEPON.
NSCHED_SYNC_JOB_NUMS gives me correctly an array of 16 integers: the
14 first values are 0, while array element 15 gives me the job number
of JOBA and array element 16 gives me the job number of JOBB.
>> It gives you only the the numbers of the dependent jobs.
NSCHED_NO_DEPON unfortunately indicates always 0. Reading the information
of the call VSS$NO_DEPON, I would expect that NSCHED_NO_DEPON returns
a longword, of which the 16 low-order bits correspond to each job dependency
in the job's synchronization array. If any of the first 16 bits are set,
it indicates that the corresponding job dependency in the synchronization
array is satisfied for the next run.
So when JOBA is finished, and JOBB still runs, I would expect bit 15
to be set in this array. But all bits remain on 0.
>> In this case NSCHED_NO_DEPON should be 0.
>> VSS$NO_DEPON() doenot return the status of the dependent jobs. It is used
>> to override the dependencies for a particular job
>> (as the command 'SCHED SET JOB job#/NO_DEPON=job#')
>>
>> If the specified job is in DEP WAIT state and all of its dependencies are
>> overriden, the job will run immediately. Dependency jobs that are overriden
>> will display in SHOW/FULL with brackets ("[]") around them just as if they had
>> already completed running.
To make the whole story even more complete, I also did a few tests with
VSS$NO_DEPON. This call works indeed very well.
For example, if VSS$NO_DEPON is used to set bit 15 and bit 16,
JOBC starts executing immediately. As expected.
But to make it then a complete mystery: while JOBC is executing,
VSS$SHOW_ITEM returns a bit mask with bit 15 and 16 set! As expected.
When JOBC completes, VSS$SHOW_ITEM returns all bits cleared. As expected.
But run manually JOBA via the scheduler interface, and check then
the no_dep_mask with VSS$SHOW_ITEM, all bits appear to be clear.
>> The overrides will be cleared once the job runs or the job's dependencies are
>> modified.
>> Therefore, after manual running of the JOBA all bits were clear.
Regards,
Igor Skapinker, Scheduler Engineering
|
| You guys basically have it correct. The user interface puts the []
around dependencies in the show job/full display. It does this by
following the same logic NSCHED uses when it decides if a dependency is
satisfied. A dependency for "JOBA" is considered satisfied if any of the
following conditions is true:
1. the "dependency satisfied" bit corresponding to that job in the 16-bit
dependency mask in JOBA's job record is set. (this bit is set by the
$ sched set job /nodepon=xxx command. The bits in the mask correspond
to the jobs in the dependency array - i.e. they are sorted by job
number, highest first. Unused positions contain 0)
2. The dependency job's last completion status was odd (low order bit
is set), and the dependency's completion time is later than JOBA's
"sync time". This field is available from VSS$SHOW_ITEM, I think. The
$ sched set job xxx /clear_deps command sets the sync time to the
current time, and (I think) clears all bits in the dependency mask, so
the effect is that all dependencies are considered to be unsatisfied
and would have to run again. The "sync time" is what you see in the
line "all dependencies must complete after <time> in the
$ sched show job/full display.
The no_depon bit for a dependency in JOBA's dependency mask gets
cleared when the dependency completes with success, I think (someone
would have to look at NSCHED's code to be sure, I don't quite remember)
It DOES NOT get set when dependency jobs complete with success - the
scheduler follows the rules about comparing dependency completion times
and status with a job's "sync time", as mentioned above.
|