Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!uunet!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...
Keywords: nqs
Message-ID: <1991Mar15.174247@igc.ethz.ch>
Date: 15 Mar 91 16:42:47 GMT
References: <1991Mar14.073500.11533@s1.msi.umn.edu> <1991Mar14.221446.14293@odin.corp.sgi.com>
Sender: news@bernina.ethz.ch (USENET News System)
Reply-To: torda@igc.ethz.ch (Andrew Torda )
Organization: InformatikgestutzteChemie, ETH, Zurich
Lines: 38
Nntp-Posting-Host: hermitage

In article <1991Mar14.221446.14293@odin.corp.sgi.com>, bh@sgi.com (Bent
Hagemark) writes:

> Personally, I don't have much fondness for qmgr, either!  I'd rather
> see an ascii file (ala,/etc/printcap) which you can edit directly or
> front-end with (better) qmgr commands or even a GUI.  Also, text files
are

What if you have a big server with no graphics ? One should not
rely on a GUI.
This is not an unlikely machine to be running nqs.

Also, note that nqs qmgr does read from the standard input. This does
give you some scope to construct an ascii file as you suggest. In order
to manage a number of machines here (13 of them running nqs), we
already
keep one ascii file with all the definitions of queues.

We then have a script like

  foreach nqs_machine (`cat machine_list`)
     rsh $nqs_machine qmgr < queue_description_file
  end

although I appreciate this is not as neat as a file analogous to
/etc/printcap.


> However, we do want to hear what people like and don't like.  This
latest
> release of NQS was engineered with a fair amount of customer
feedback.

Does the new nqs maintain SGI's incompatibility with respect to nqs
running on other machines ?

--
Andrew Torda, ETH, Zurich