HP3000-L Archives

March 2004, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
John Pitman <[log in to unmask]>
Reply To:
John Pitman <[log in to unmask]>
Date:
Wed, 17 Mar 2004 12:53:03 +1100
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
I also wrote a sort of scheduler years ago, that in simple terms, allowed
only one job per account to run at a time, but the user could specify how
many parallel pseudo queues could exist. The user could change the inpri of
the waiting jobs to modify run sequence if necessary. In the days of either
having to allow only one job at a time to keep them in required sequence, or
manually juggle the jobs, it saved loads of elapsed time in getting long
overnight sequences to completion .
Wonder where it went....
jp
----- Original Message -----
From: "Greg Stigers" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, March 17, 2004 12:00 PM
Subject: Re: [HP3000-L] Temporary files and Unix


> Tim Cummings wrote:
> > Or if you have several jobq's like on the 3000 you can ensure several
> > single threaded lists of tasks be completed.
> Years ago, as proof of concept, I wrote a CI command file (which I
typically
> ran from another job stream) that would read thru a list of job names,
> streaming them one at a time, and waiting for each to finish. It then
> checked that the job had in fact finished, not aborted, then streamed the
> next one. Had the current job aborted, it performed appropriate
> notifications, and exit. Furthermore, it wrote the name of the current job
> to a file. When started, it would check for the existence of this file. If
> found, it would read it, then look for that job name in the list, and
resume
> with the next name in the list. I'm pretty sure that it took less than
half
> a day's work to cobble this together. It was not exactly feature-rich, but
> it did the job for testing batch processing on our development box. It
> certainly beat spending five figures for a third-party scheduler.
>
> Actually, the problem that seems to bedevil OS-provided scheduling is
> holidays. There are certainly ways to script around this, but I have yet
to
> see a system scheduler that could except holidays from production runs.
Then
> again, the day after (American) Thanksgiving can fool third-party
schedulers
> for Novembers that begin on Friday. That makes the day after Thanksgiving
> the fifth Friday of the month, instead of being the fourth Friday of the
> month.
>
> If folks want to go semi-off-topic (SOT?), I bet there is a treasure trove
> of batch-processing horror stories among the members of this list. I
> remember getting about three hours of sleep one night, the Monday after
> Thanksgiving, and not having things back to normal until about 2PM. I had
> found and fixed an old bug with the homegrown scheduler, only to have an
> operator abort a DSLINE session on the corporate system that pulled some
> data from their IMAGE database.
>
> Greg Stigers, MCSA
> this space for rent
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

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

ATOM RSS1 RSS2