Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!sdd.hp.com!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!cernvax!chx400!chx400!bernina!igc.ethz.ch!torda
From: torda@igc.ethz.ch (Andrew Torda )
Newsgroups: comp.sys.sgi
Subject: Re: What I'd LOVE to see in SGI's NQS...
Message-ID: <1991Mar22.144658@igc.ethz.ch>
Date: 22 Mar 91 13:46:58 GMT
References: <1991Mar14.073500.11533@s1.msi.umn.edu> <1991Mar14.221446.14293@odin.corp.sgi.com> <1991Mar15.174247@igc.ethz.ch> <1991Mar20.112324.17045@rusmv1.rus.uni-stuttgart.de> <1991Mar22.103255.1460@urz.unibas.ch>
Sender: news@bernina.ethz.ch (USENET News System)
Reply-To: torda@igc.ethz.ch (Andrew Torda )
Organization: InformatikgestutzteChemie, ETH, Zurich
Lines: 24
Nntp-Posting-Host: hermitage

In article <1991Mar22.103255.1460@urz.unibas.ch>, doelz@urz.unibas.ch writes:
[...]
> There is a 'original' available from Sterling which also communicates
with the 
> rest of the NQS' implementations. We need to run NQS on more than
SGI's, 
> therefore, would *really* like to see the qmapmgr on SDGI's NQS.
Otherwise 
> we might be tempted to move to the competitor's product. 

We did.
It works and allows us to move jobs between the various machines.
Basically, we are happy, but if you want non-degrading process
priorities,
you have to find the line in the nqs code which spawns off your job, or
invoke the nqs daemon from a line like
   npri -h xx nqsdaemon.

This is a small inconvenience to allow a Network Queue System (nqs) to
work over a network.
Sorry I sound so bitchy about this product.

--
Andrew Torda, ETH, Zurich