Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!ukma!usenet.ins.cwru.edu!eagle!data.nas.nasa.gov!wilbur.nas.nasa.gov!eugene From: eugene@nas.nasa.gov (Eugene N. Miya) Newsgroups: comp.sys.super Subject: Re: NQS info wanted (do we need a FAQ posting?) Keywords: NQS Message-ID: <1991Jan4.181847.24382@nas.nasa.gov> Date: 4 Jan 91 18:18:47 GMT References: <1991Jan4.171447@obelix.anu.edu.au> Sender: news@nas.nasa.gov Reply-To: eugene@wilbur.nas.nasa.gov (Eugene N. Miya) Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA Lines: 61 [Just kidding about the FAQ; yet again from COSMIC's official page.....] [I do not know if international distribution of NQS is permitted.] M88-10054 Sterling NOS- NETWORK OUEUEING SYSTEM B. KINGSBURY C-LANGUAGE Approximately 75,000 source statements 9 Track 1600 BPI UNIX CPIO Format Magnetic Tape UNIX OPERATING SYSTEM ARC-11750 Price: Program $6,000.00/Documentation $21.00 The Network Queueing System, NQS, provides batch and device queueing facilities for various computers comprising a networked UNIX environment. With the UNIX operating system as a common interface, a user can invoke the NQS collection of user-space programs to move freely around the different computer hardware tied into a network. NQS provides facilities for remote queueing, request routing, remote status, queue access controls, batch request resource quota limits, and remote output return. NQS was developed as part of an effort aimed at tying together diverse UNIX based machines into NASA's Numerical Aerodynamic Simulator Processing System Network. The NQS architecture was written with the following design goals: 1) provide full support for both batch and device requests, 2) support all of the resource quotas enforceable by the underlying UNIX kernel implementation that are relevant to any particular batch request and its corresponding batch queue, 3) support remote queueing and routing of batch and device requests throughout the NQS network, 4) modularize request scheduling algorithms so that schedulers can be easily modified at individual installations, S) support queue access restrictions through user and group access lists for all queues, 6) enable networked output return of both output and error files to possibly remote machines, 7) allow mapping of accounts across machine boundaries, 8) provide friendly configuration modification mechanisms for each installation, 9) support status operations across the network, without requiring a user to log in on remote target machines, and 10) provide for file staging, or copying of files for movement to the actual execution rnachine. There are three types of queues supported by NQS. Batch queues do not require a specific device, that is the batch request can be routed around the network with no detrimental effects. Device queues are for requests which require the direct services of a specific device, such as a line printer. A pipe queue exists to transport requests to other batch, device, or pipe queues at possible remote machine destinations. The pipe queue mechanism is responsible for routing and delivering requests to other queues in spite of machine failures, lack of owner authorization, insufficient space, disabled queues, and other rejections. All NQS network conversations are performed using the Berkeley socket mechanism as ported into the respective vendor kernels. Computer networks which have successfully implemented NOS include DEC VAX, Silicon Graphics IRIS, Amdahl 5840 mainframes and CRAY-2 machines. NQS is written in the C language for interactive execution and has been implemented on various computers operating under UNIX. NQS has a central memory requirement of approximately 160K of 8 bit bytes on a DEC VAX computer. The NQS daemon must reside on every computer in the network. NQS requires the nmap utility, which is supplied as part of the NQS package. This program was developed in 1986.