-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/11/07 19:36, s. keeling wrote: > Ron Johnson <[EMAIL PROTECTED]>: >> On 05/11/07 12:49, s. keeling wrote: >>> Ron Johnson <[EMAIL PROTECTED]>: >>>> 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----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]