On Friday December 28 2007 14:48:33 David Brodbeck wrote: > On Dec 28, 2007, at 11:17 AM, Ron Johnson wrote: > > That's not how it works on z/OS (OS/MVS), DOS/VSE & OpenVMS. > > > > On them, you have "named batch queues". Each queue has a > > default (in Unix terminology) niceness level, and "width" > > (like how a bank branch has a single line feeding multiple > > teller windows, the "width" defines the number of jobs that > > can be in the Running state, whereas the jobs standing in > > "line" are Pending). Also, there is a job priority, so that > > important Pending jobs jump to the front of the line, and > > less important jobs fall to the rear. Just like with "at", > > jobs can be scheduled to run at various times. Of course, if > > the execute slots are all full at a job's run time, it goes > > not to Executing but to Holding state. > > This sounds pretty similar to what Condor does for clusters: > http://www.cs.wisc.edu/condor/ > > It queues up jobs and executes them on available CPUs, either > locally or on other systems in the cluster. It has a fairly > sophisticated (though some what obscure to configure) priority > system.
Sounds like it, except that mainframe-style batch queue systems don't know nor care about the number of CPUs. It's up to the SysAdmin(s) and users to determine queue width. The big difference is that HPC clusters run CPU-bound jobs, whereas "business" systems usually run highly IO-bound jobs, and while one job is waiting on an IO, other jobs can use the CPU. Thus, many more jobs can run than there are CPUs. > Currently it's free as in beer, but not open source. Rumor has > it Red Hat has gotten involved and future versions will be open > source. -- ----------------------------------------------------------------- Ron Johnson, Jr. Jefferson, LA USA "I don't measure a man's success by how high he climbs but how high he bounces when he hits bottom." General George S. Patton
signature.asc
Description: This is a digitally signed message part.
