> -----Original Message-----
> From: Greg Stigers [mailto:[log in to unmask]]
> 
> Here's slightly more detail on PAUSE. See
> http://docs.hp.com/cgi-bin/onlinedocs.py?mpn=32650-90877&servi [...]
[url wrapped -- see original message]
> or just HELP PAUSE at the CI prompt, where it is explained at 
> least as well as I can explain it. [...]
> 
> I seem to recall some discussion of a * rare * case when a 
> job is streamed, and the PAUSE is then issued, but the job
> table does not yet reflect the just streamed job.

The help file does mention that:

                        ... "PAUSE might miss finding
   short-lived jobs. This is particularly true for a
   match on a single job/session number. A more
   practical use might be:

         PAUSE job=@J;notexist

though personally I would recommend the use of the actual jobid instead of @j -- I don't really know why they say it is "more practical" since nowadays most systems have at least one or two "sleeper" type jobs [daemons in Unix-speak], so the case of "ANY job not existing" will almost always be false (err, true? this is a semi-double negative...)  In any case, by using a ";NOTEXIST" check first, you'll almost certainly guarantee you'll "wait until it actually starts", then you can follow it with a ";EXIST" pause to wait until it finishes.

I say "almost certainly guarantee" because the rare (corner?) case that could still happen is that the job aborts on the first line or two of the JCL, and by the time your "pause" operation checks on it, it has not only entered the wait/exec states, but aborted and cleared from the jobtable -- end result, your first job waits forever, thinking that the job never started [which in this scenario this is probably a good thing -- if the second job finished so fast it was never noticed (due to an error), the first job really should NOT continue...]

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *