Re: [OT] Screen (was Affecting Inst. Change)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/11/07 19:36, s. keeling wrote:
> Ron Johnson <ron.l.johnson@cox.net>:
>> On 05/11/07 12:49, s. keeling wrote:
>>> Ron Johnson <ron.l.johnson@cox.net>:
>>>> Yes, but competent OSs have batch queues for running such jobs. Why
>>>> Unix has never had such a capability is beyond my understanding.
>>> man batch: at, batch, atq, atrm - queue, examine or delete jobs for
>>> later execution.
>>>
>>>> (NO!! cron is *not* an adequate substitute for batch queues!)
>>> cron's for regularly repeated jobs. batch and at are for sequential
>>> job scheduling.
>> How do you create more queues than just "b"?
>
> I'm serious: why? There's only so much resources available in a
> machine. Do you want a job to complete asap, or do you want a number
> of jobs to complete asap? This is the high ground of performance
> analysis we're fiddling with here.
Control and management.
In VMS, most batch jobs (unless you run a dedicated job scheduler)
run in the default batch queue SYS$BATCH. However, most all sites
also create different queues for different classes of processes.
>> How do you limit the number of batch jobs that can run at any one
>> time? (If the "job limit" of a queue is 4 and you submit 20 jobs,
>> the first 4 jobs grab the execute slots, and the remaining 16 wait
>> until execute slots open up.)
>
> Meaning, you'd prefer that all 16 jobs run concurrently? That sounds
> sub-optimal (for most eventual users, at least).
No. Exactly the opposite.
Think of a bank with 4 tellers. If 20 people walk into the bank,
the first 4 get to the tellers, and the other 16 wait in the queue.
As a customer at a teller finishes his business at a teller and
walks away, the next customer in line goes up to that teller.
>> How do you tell one job to synchronize on another (i.e., sleep until
>> the "other" job is complete, and then continue with your own processing.
>
> I never had to deal with that problem, so I don't know. I'd have done
> it another way, personally. Note, I'm not suggesting *nix batch queue
> management is superior to others out there.
It's often necessary in business operations.
>>> I was running simulations with them in OSF/1 batch
>>> queues in the early '90s.
>> DEC OSF/1, you say? I bet that it took queue management concepts
>> from OpenVMS.
>
> You wish. No, even then, the *nix-ish side of DEC barely tolerated
> the existence of the VMS-ish side, and vice versa. OSF/1 was very
> *nix-ish, and tended to avoid doing anything that might brand them as
> being of the same ilk as the VMS side.
>
> It was sure fun to watch those Ultras blow the doors off the VMS
> machines though. OSF/1 wasn't originally available for non-Ultra
> processors.
Ultras? UltraSPARCS?
- --
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGRSZOS9HxQb37XmcRAiSJAJ9WQIoho1U+tKIKGBAoutCVOX1IjACgl36v
xEoGY9H1wFDLFNoQJCZZNlg=
=FhhJ
-----END PGP SIGNATURE-----
Reply to: