pwb@trwrba.UUCP (07/24/84)
This article is meant for anyone interested in a device independent queueing system. I designed this beast a few years ago (so don't think it's a ripoff of MDQS from the Army Ballistics Research Lab) and it has been running in a production mode on the Unix service center (trwrb) here at TRW E&DS for the last two years with couple of design upgrades. The Generic Queueing System was built do deal with our everyday queueing needs such as printing, remote printing over a LAN, file transfer to non-Unix hosts, local batch and remote batch (and others still in my head). It was designed to be simple, comprehensive, and modular (i.e. VERY easy to expand). The queueing system supports a very flexible mapping capability with queues mapped onto logical resources and logical resources mapping onto physical (or imaginary) devices. Resources may share queues or devices. A typical graphical representation of a simple configuration would appear as: QUEUES: landscape portrait batch recvfile xmitfile | | | | | ------------------ ---------- ----------------- | | | | | | RESOURCES: linepr laser cat4 local cyber750 | | | | | | -------- | ------------ | | | | | DEVICES: /dev/lp /dev/qms1200 /dev/null /dev/net0 /dev/net1 The configuration information is contained in an keyword based ascii file that is interfaced using a general purpose library package (the `profile' library) developed here independently of the queueing system. Whenever the ascii configuration file is edited, the queueing daemon reconfigures its internal hash tables and circular list. Along with specifying the QUEUE:RESOURCE:DEVICE relationships, the configuration file also provides software mapping information and daemon control information (debug logging level, trusted ids, etc.). Independent scheduling modules may be specified on a per resource basis and the QUEUE:RESOURCE:DEVICE mapping specifies a device (or service) specific module called a `drone'. Given the dynamic nature of the configuration file, new schedulers and drones may be configured into the system on the fly. The queueing system currently runs on 4.x systems and can be easily modified for V7 compatible versions of Unix since the only Berkeley specific code is the use of the Berkeley directory library (-ldir). These areas are CLEARLY identified. All other code is V7 compatible. I'll stop at this. The following is the queueing system introductory manual page. Anyone that is interested beyond reading this article can reach me at {decvax,ucbvax,hplabs,ihnp4}!trwrb!pwb or by phone at 213-535-1980. I can then mail you a shell archive file of all the manual pages, or if enough people express interest, I'll post the shar file to net.sources. If you are still interested after reading the manual pages, we can work out something with the source (you send us a tape, we send it back, or uucp'ing a tar file). Note that the queueing system is accompanied by the profile library and the hash table library developed here. Cheers, Phil Bonesteele, TRW Electronics & Defense Sector {decvax, ucbvax, hplabs, ihnp4}!trwrb!pwb 213-535-1980 QINTRO(1) UNIX Programmer's Manual QINTRO(1) NAME Introduction to the generic queueing system. DESCRIPTION The generic queueing system is a collection of user utili- ties and system modules that provide a general purpose queueing mechanism flexible enough to service a wide variety of device and scheduling needs. The utilities allow users to enqueue a request for services, examine the progress of requests through the queueing system, modify information within a request, and determine the current configuration of the queueing system. The primary interaction with the queueing mechanism is the act of enqueueing a request for a specific service. A ser- ------- ------- ---- vice is a specific action taking place on a given resource ---- ------ -------- at a given time. The qrequest(1) interface provides for the ---- -------- specification of a resource, a queue (representing the -------- ----- action component of the requested service), and a time. ------ ---- If the service time is in the future, the request is in a ---- immature state. When the service time is reached or passed, -------- ---- the request becomes mature. Only mature requests are con- ------ sidered for scheduling. Once a request has achieved matu- rity it will pass through a series of states on its way to completion of the requested service. All state transitions may be traced using qactivity(1) which tracks the progress --------- of a request through the queueing system. If an request has been enqueued erroneously, the qmodify(1) ------- interface may be used to cancel the request or change the incorrect information. To determine mappings of queues onto resources (and thus the actions that are allowed on the resources) use the qmap(1) ---- user interface. TIME Time specification to utilities that offer time options are of the form hh:mm[:ss][a|p][m] [mm/dd[/[yy]yy]] where hh:mm[:ss] represents hours, minutes, and seconds (optional). This time is on a twenty-four hour clock if the [a|p][m] qualification is absent. [a|p][m] represents the optional notation `a', `am', `p', or `pm' as qualifiers to the hour, minute, and second specification for twelve hour median time. [mm/dd[/[yy]yy]] 4bsd TRW (7/24/84) 1 QINTRO(1) UNIX Programmer's Manual QINTRO(1) represents an optional date in a numerical presentation of month, day, and year. The year may be two or four digits, with a two digit year assumed to be an abbrevi- ation for 19XX. If no date is given, the current date is assumed. If no time is given, the present is assumed. USER DEFINED DEFAULTS The first time qrequest(1) is invoked, a .qprofile file is -------- --------