Actually..... I got burned by this logic once.  You need to be careful with
the PAUSE 60 command to wait for the clock to change.  I used the same
logic in a job, and had a problem with the fall clock change.  In fall, the
clock on the system was gradually changed back one hour.  Thinking the
PAUSE 60 would cause the minute to change, I placed it in the job.  During
the gradual timezone change, the PAUSE 60 wasn't enough  to cause the
minute to change, and the job re-streamed itself several times within the
same minute.  It seems to me that a PAUSE 60 should guarantee a change in
the minute portion of the time, even if it takes 90 seconds of system time
to complete.  However, HP didn't ask my opinion, and the job didn't work as
intended.  I changed the job to PAUSE 300, and it works now, but I consider
that a kludge.

If you're going to use the PAUSE 60 logic, you might want to consider the
possibility that it will run during the fall time change.

David N. Lukenbill
Computer Sciences Corporation




I will make sa follows:
   !JOB JOB1,USER.ACCT
   !PAUSE 60
   !STREAM JOB1.JOBGROUP.JOBACCT;AT=20:30
  <JOB LOGIC>

   So will cover the event that job logic delays more than one minute
(deppends on system load).


[snip]

   Hello,
I tried the following:
   !JOB JOB1,USER.ACCT
   <JOB LOGIC>
   !PAUSE 60
   !STREAM JOB1.JOBGROUP.JOBACCT;AT=20:30
It worked!
Thank you to all,
Derrick

[snip]

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