Usenet 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / unix / volume25 / ispin / part13 < prev next >

Wrap

Text File | 1992-02-01 | 53.7 KB | 1,314 lines

Newsgroups: comp.sources.unix From: sir-alan!ispin!lbartz@iuvax.cs.indiana.edu (Larry Bartz) Subject: v25i124: Indianapolis Standard Printer Interface for Networked printers, Part13/15 Sender: sources-moderator@pa.dec.com Approved: vixie@pa.dec.com Submitted-By: sir-alan!ispin!lbartz@iuvax.cs.indiana.edu (Larry Bartz) Posting-Number: Volume 25, Issue 124 Archive-Name: ispin/part13 #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh <file", e.g.. If this archive is complete, you # will see the following message at the end: # "End of archive 13 (of 15)." # Contents: ISPIN/doc/OVERVIEW ISPIN/doc/OLD-DOCS/README.beta.3 # ISPIN/misc/SUID.dr/lp_perms.sh # Wrapped by socrates@indy6 on Tue Jan 28 15:27:14 1992 PATH=/bin:/usr/bin:/usr/ucb ; export PATH if test -f 'ISPIN/doc/OVERVIEW' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'ISPIN/doc/OVERVIEW'\" else echo shar: Extracting \"'ISPIN/doc/OVERVIEW'\" $34406 characters$ sed "s/^X//" >'ISPIN/doc/OVERVIEW' <<'END_OF_FILE' X X # #### ##### # # # X # # # # # ## # X # #### # # # # # # X # # ##### # # # # X # # # # # # ## X # #### # # # # X X XI N D I A N A P O L I S S T A N D A R D P R I N T E R I N T E R F A C E X X for X X N E T W O R K E D P R I N T E R S X X X X X X X F U N C T I O N and D E S I G N O V E R V I E W X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X CONTENTS X XEXECUTIVE OVERVIEW................................. 1 X X XGENERAL OVERVIEW................................... 2 X X X X XATTACHMENT A - SYSTEMS AND SWITCHES................. XX X X XATTACHMENT B - ISPI APPLICATION..................... XX X X XATTACHMENT C - DISCUSSION TOPICS.................... XX X X XATTACHMENT D - FUTURE DIRECTIONS.................... XX X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Page 1 X X X ************* EXECUTIVE OVERVIEW ***************** X X XNetworking of computer resources serves to maximize the potential for Xefficient utilization of resources. Internal Revenue Service (IRS) has Xcapitalized upon this potential by establishing and maintaining a wide Xarea network. In particular, the networking of printing facilities (printers Xand the computers which originate printing activities) permits the widest Xpossible access and utilization of expensive and scarce resources. X X XNetworking hardware serves as the primary enabling factor but efficient, Xreliable software is the only channel through which the promises of Xnetworking can be realized. X X XISPIN is a unique solution to this problem, owing to its simplicity, Xreliability, portability, and flexibility. Its simplicity of design and Xusage is due to its reliance, to the greatest extent possible, on Xexisting software which is native to the UNIX operating system. ISPIN is Xreliable because of its unique capabilities to recognize and deal effectively Xwith error conditions. ISPIN's unique portability and flexibility Xfeatures provide a wide range of hardware compatibility and assurance for Xcompliance with future applications. Its rapid success in this regard is Xevidenced by the fact that more than 40 IRS data processing sites with Xvarious hardware configurations have implemented ISPIN. These sites have Ximproved customer support and reduced maintenance overhead through the Ximplementation of ISPIN. X X X X X X X X X X X X X X X X X X X X X X X X Page 2 X X X ****************** BACKGROUND ****************** X XOVERVIEW X XNetwork-connected printers were an intended feature of the Treasury-wide XConsolidated Data Network (CDN) from its earliest design phases. This feature Xallows levels of access and flexibility previously unavailable to users Xof computer systems. When all computer systems and all printers are connected Xto CDN, a print request can ultimately be routed from any computer Xto any printer. Such flexibility is an obvious benefit to users of computer Xsystems. It is also a boon to systems administration and data communication Xpersonnel, as it eliminates the "hardwired", direct connection of computer Xand printer, which implies frequent re-cabling and software reconfiguration Xas user needs and applications evolve. These benefits also accrue on Xa smaller scale as computer systems and printers are connected to local Xdata switching equipment. X X XPrinting on network-connected printers requires specialized software Xsupport in addition to the above-described hardware component. The UNIX Xoperating system is equipped with a software subsystem known variously Xas a spooler or queuer. The spooler/queuer subsystem consists of a closely Xrelated family of programs which: accept the user's request for printing; Xcoordinate the number and naming of printers known to the system; and Xschedule the execution of (possibly multiple near-simultaneous) requests for Xprinting. The "stock" spooler/queuer subsystem assumes that the printers Xare directly connected to the computer. By itself, the native spooler/queuer Xis incapable of supporting network printing. Absent from the native utilities Xis a facility to "negotiate" a connection from the computer, through the Xnetwork, to the printer. X X XIn 1988, as CDN began to proliferate throughout IRS, the Indianapolis District XOffice studied the issue of supporting printers which are not connected Xdirectly to a given computer, but are connected to the network. X X XFour major themes shaped our design of a unique solution: X X XFirst, was simplicity. Software which avoids unecessary complexity is easier Xand less time consuming to install and support on a continuing basis. Simplicity Xis a significant factor in ISPIN's design. X X XSecond, was reliability. Reliable software possesses sophisticated capabilities Xto recognize and recover from error conditions. The result is a low failure Xrate, high user satisfaction, and infrequent technical support required to Xrectify problems associated with failures. The reliability issue is Xaddressed by building fault detection, fault tolerance and fault recovery Xfeatures into ISPIN. X X XThird, was flexibility. Little of ISPIN's functionality is pre-programmed, so Xit easily adapts to environments it has not previously confronted. ISPIN was Xdesigned with flexibility in mind, so the application is viable for many Xcombinations of computer systems, networking systems, and printers. X X XFourth was portability. Software which is designed to conform with Xestablished standards has the greatest potential for a long life cycle and Xlow long term maintenance costs. ISPIN complies with established Xstandards to assure the greatest degree of portability among UNIX operating Xsystem variants. X X X X X ************* FUNCTIONAL DESCRIPTION *********** X X X - The native spooler/queuer subsystem is adequate for hardwired X printers. It accepts enqueueing and cancellation requests, X reports on its status, and allows for adding and removal of queue X members (printers). When the spooler/queuer program schedules X a user's request for printing, it passes pertinent information to X an executable program or a shell script which sends the print job X via the designated computer port (tty) to the printer. This last X program is known as the backend, or interface. X X X - We substitute a call to ISPIN for the backend. X X X - The ISPIN process reads an entry for itself from an ASCII file X called "rtab". The rtab is intentionally similar to the uucp X L.sys file (or Systems file under HoneyDanBer uucp). There X is one rtab entry per virtual printer (any given physical printer X may be known or treated as several virtual printers). X X X - The rtab entry contains the chat data (EXPECT/SEND) necessary X for the ISPIN process to negotiate through the network to the X printer. This data may also include printer initialization and X configuration commands which can be passed both before and after X the print job. X X X - The rtab entry also contains a field which defines which tty(s) X (from one to eleven possible) through which the printer may be X called. X X X - The ISPIN process passes a formatted message to a daemon process X known as IQUEUER. IQUEUER determines which of the requested X ttys is available, and issues a message back to the ISPIN, telling X it to proceed, using a particular tty. IQUEUER also maintains X lock files, thereby avoiding conflicts with uucp, cu, uugetty, X etc. X X X - The ISPIN process, after receipt of its message from IQUEUER, sets X up the tty, negotiates the network, and sends the job to the X printer. X X X - The rtab entry also contains flags and arguments which indicate X network and printer busy and fault conditions. The ISPIN process X watches for these indications to determine whether it should X terminate and loop or quit. X X X - All the while, the ISPIN process is under the complete control X of the native spooler/queuer. Its status (active or waiting) is X known to the native spooler/queuer daemon. It may be cancelled X or rescheduled by the operating system's native commands. X X X - While the ISPIN is "active" with respect to the native queuer, X the IQUEUER daemon is notified by the ISPIN process of its X current phase of execution (startup, negotiating the network, X printing, disconnecting, looping). The current status of all X currently executing ISPIN processes may be queried via another X command, known as "iq". X X X - While this sounds very busy, it is quite efficient and X gratifyingly robust. If the printer is offline or busy, or X the network is unable to make the connection, the ISPIN will X loop and resubmit itself to the IQUEUER. If other jobs are X waiting for network access through the tty(s), the looper is X made to wait while other potentially successful jobs go ahead. X If a Greyhound bus takes out a telephone pole between the CPU and X the printer (or other mid-job disconnection), ISPIN detects X the fault and loops as above. Upon successful re-connection, X the job will be printed in its entirety. X X X X X ****************** SIMPLICITY ****************** X X XISPIN is uniquely simple in its design and implementation. It is not a Xa trivial utility, nor is it simple with respect to its internal workings. XISPIN consists of four executable programs of approximately 9400 lines of XC code. ISPIN attains its simplicity and ease of use by relying to the Xgreatest extent possible on existing software which is native to the Xoperating system. X X XThe native spooler/queuer is part of the operating system. It is efficient, Xreliable, and well-documented software. Perhaps as important, the usage and Xadministration of the native software is already familiar to systems admini- Xstrators, programmers, and users. X X XAs we studied the native spooler/queuer subsystems, we found that the Xdesigners of those software subsystems designed a flexible interface Xat what is known as the "backend" of the spooler/queuer process. This is the Xpoint at which, in a "hardwired" printer situation, the print job would be Xsent to the printer. The native spooler/queuer is designed to allow the Xsystems administrator or systems programmer an opportunity to insert their Xown special purpose programs as the "backend". This flexible interface Xfeature is well documented in UNIX systems administration manuals and in Xother descriptive files which are part of the operating system. X X XThe flexible backend interface was the obvious point at which to attach Xdata communication and print request execution software. The Xefficient, reliable, and familiar native operating system software would Xremain and would function as intended. This approach appealed to UNIX Xsystems administrators and systems programmers. X X XCapitalizing upon native UNIX facilities is the "UNIX way" of approaching a Xproblem and is generally known as the "tools-based approach" to application Xdevelopment. This application development methodology recognizes the strength Xand flexibility of the UNIX operating system and the rich inventory of Xsoftware tools it offers the systems programmer. This approach not only Xsaves considerable time and effort in development but, done correctly, it Xvirtually guarantees portability, reliability, and ease of use. X X XIn practice, once ISPIN has been installed on a system (usually in an hour Xor less, according to current ISPIN customers), all end-user inter- Xface with requesting and controlling printing activities remains under the Xcontrol of the native software. In addition, all of the systems administra- Xtion activities involving adding, removing, enabling, and disabling queue Xmembers (printers) and manipulating the active queue of print requests also Xremain under the control of the native software. The only additional demand XISPIN imposes upon the systems administrator is the addition of a one line Xentry per printer in an ASCII table (rtab, described later). Even this Xactivity is usually as simple as duplicating a previously existing line, then Xmaking trivial changes to the new entry. X X X X X ****************** RELIABILITY ***************** X X X X XThe issue of fault tolerance was critical. Reliability required facilities Xfor detecting and correctly dealing with situations such as: X X - printer turned off before successful network connection X - printer turned off or data line lost during print job X - printer on "pause" (such as when out of ribbon or paper) for long periods X X XWe designed ISPIN with unique capacities for detecting and handling fault Xconditions such as described above. X X XFirst, ISPIN's reliance upon the native spooler/queuer software virtually Xguarantees that a failure of any particular print request will not jeopardize Xthe print queue as a whole. The native spooler/queuer subsystem is itself Xsimple and robust in this aspect. X X XAnother unique feature of ISPIN which enhances its ability to detect fault Xconditions is ISPIN's "rtab" (for "remote printer table") file. rtab is an XASCII file which is comprised of a one-line entry for each virtual printer. X X XAn ISPIN process obtains all network negotiation and printer set-up informa- Xtion (communication messages, communication timing, network responses, printer Xconfiguration commands) at run time from the rtab file. None of the information Xa given ISPIN process requires to make a network connection or detect errors is Xcompiled into executable code. X X XThe format and usage of the rtab is intentionally reminiscent of UNIX Xuucp's "L.sys" or "Systems" file. This style further reinforces the "UNIX way" Xflavor of the application. Of particular pertinence here are the various means Xby which the systems administrator may easily "tune" an rtab entry to accomodate Xspecific or peculiar network conditions. All timing factors of the network Xnegotiation are minutely adjustable. This is extremely valuable, as for a given Xlocal switch or CDN "pad" the overall response timing may vary over time. The Xrtab also supports the specification of messages the network may issue to Xindicate "busy", "error", or "disconnect" conditions. In the course of Xnegotiating a network connection, the ISPIN process watches for these responses Xand behaves accordingly. X X XA most unique feature of ISPIN is that after the successful connection to Xthe printer, it sends the print job in measured "bursts" of characters. After Xeach "burst" ISPIN waits for the output to drain from the system. Both the Xaction of issuing the characters and the wait for output to drain are timed. XIf the activity takes too long (such as if user puts printer on pause and walks Xaway, or an unattended paper jam) the ISPIN disconnects from the network and Xattempts to re-establish the connection. Upon successful connection, the job Xwill be printed in its entirety. In the course of a normal "no fault" print Xjob, waiting for the output to drain from the CPU is necessary only to Xaccomodate flow control, so there is no additional throughput overhead cost. XThe duration of the wait (if output is not draining) is sufficient to allow Xthe user to replace a ribbon, clear a paper jam, or correct other faults. XThis feature is unique to ISPIN. X X XFurthermore, after the issuance of each "burst" of characters, the ISPIN Xprocess "listens" for any characters which may be coming back to the computer Xthrough the port which ISPIN is using. Again, in the course of a normal X"no fault" print job, there will be no characters at all coming back to the XCPU. ISPIN is performing a "raw" read of the port at this juncture, so Xif there are no characters to be read, no time will be wasted in waiting. XIf any characters are received by the ISPIN process, they are compared to Xmessages which have previously been specified in the rtab entry as Xindicators of a "disconnect" condition. If there is a match, the ISPIN Xprocess will effect a logical disconnection, then attempt to re-connect until Xsuccessful. As above, the job will later be printed in its entirety. XThis is another feature which is unique to ISPIN. X X XIn UNIX jargon, a daemon is a continuously-running program which is not Xassociated with a terminal. ISPIN's "IQUEUER" daemon program controls access Xto CPU ports and acts as a server to the native spooler/queuer client processes. XThe ISPIN print processes are clients which solicit services (access to Xsystem communication facilities) from the IQUEUER. X X XIQUEUER assures that ISPIN jobs which are looping due to error conditions Xdo not "clog" the queue or prevent other potentially successful jobs from Xexecuting. This too is unique to ISPIN. X X XLogical, predictable behavior of a software system is a valuable trait which Xis closely related to reliability: unpredictability imparts unreliability. X X XAnother unique feature of ISPIN is in the control of access to the CPU ports Xwhich are available for access to the network and, ultimately, to the printers. XA common feature of UNIX applications which use CPU ports on an infrequent Xbasis is the reliance on a file known as a "lock" file. Native UNIX utilities Xsuch as "cu", "uucp", and applications such as ISPIN, MDQS, and MMDF all support Xthis feature. These utilities and applications all check for the existence of Xa lock file before they assume control of, and use a CPU port for outbound Xcommunication. If a lock file exists, the application assumes a competing Xprocess has control of the port resource. If no lock file exists, the applica- Xtion can assume it has exclusive access to the port, and creates its own lock Xfile to exclude potential competing processes. At the conclusion of its task, Xthe process removes its own lock file. ISPIN diverges from the others in its Xmethod of handling lock file management. X X XUnder other applications, there is no central management of CPU port access or Xlock file management. Under ISPIN, all CPU access and lock file management is Xcentrally controlled by ISPIN's secondary queueing daemon process, IQUEUER. X X XWhen an ISPIN process is invoked by the native spooler/queuer, it first reads Xits configuration information from its entry in the rtab file. It then passes Xsome of this data and its own identity to the IQUEUER through an interprocess Xcommunication channel (IPC). The ISPIN waits (on a blocking read of its own IPC) Xfor a "go ahead" message from the IQUEUER. IQUEUER maintains in-core tables of XISPIN processes which are waiting, and other tables of those which are currently Xexecuting, including their current phase or state of execution. The table of Xwaiting ISPINs is maintained in first-in, first-out order. ISPIN processes Xwhich are looping due to error conditions are put at the back of the line. It Xis the IQUEUER's responsibility to check for, create, and later remove lock Xfiles. Only upon successful attainment of a lock file does IQUEUER notify the XISPIN process of the CPU port it may use, as part of the "go ahead" order. Even Xin cases where several ISPIN print requests might all require access to the Xsame CPU port, IQUEUER will maintain a fair, logical, and predictable job Xscheduling operation. X X XISPIN's support of these unique fault tolerance features significantly Xreduces the number of failed print requests. As a result, technicians at Xsites which run ISPIN spend little time servicing user requests for Xassistance. X X X X X *********** PORTABILITY ************** X X XThe third major theme which drove the design and programming of ISPIN was Xthe issue of portability and its closely linked companion, flexibility. XWe committed ourselves to the attainment of this goal in order to assure a Xlong and productive future for ISPIN. X X XISPIN was programmed with portability as a principal consideration. We Xrelied upon an AT&T document, "System V Interface Definition" (SVID) as Xour guide to portability. The SVID was the backbone of the POSIX definition Xwhich the Federal Government, and IRS in particular, has adopted as the Xoperating system of virtually all computers to be procured in the Xfuture. Compliance with SVID helped to insure future compliance with POSIX. X X XCompliance with SVID in the earliest stages of design and programming was Xsignificant but was not by itself adequately sufficient to assure portability Xof ISPIN across all IRS UNIX platforms. Some features of SVID are not Xbackwards compatible with older versions of UNIX. The modern inter-process Xcommunication facilities of SVID were not available in the older System III XUNIX environment of the IRS's large inventory of Zilog S8000 computers. XWe designed an innovative inter-process communication (IPC) scheme to Xaddress this situation. The "named pipe", or FIFO, is an IPC facility which Xis supported by the UNIX kernel. The operating system supports specialized Xread and write algorithms which are unique to the FIFO type of IPC. We Xdevised a system in which the ISPIN process communicates with the unrelated XIQUEUER process (and vice versa) through strictly formatted fixed-length Xmessages via named pipes. Similar communication facilities exist between XIQUEUER and IQ, the status inquirer utility of ISPIN. This inter-process Xcommunication facility is portable across all UNIX systems. The use of a Xsimilarly named but unrelated C programming technique (unnamed pipes, Xbetween related processes) is fairly common and well-documented. The FIFO Xtechnique is only obscurely documented and required considerable research Xand testing. We devised this unique solution because it is very efficient Xand because it is portable. X X XWe have succeeded in achieving a unique level of portability for ISPIN. XISPIN customer sites have successfully installed and executed ISPIN on many Xcomputer systems we have never seen or even logged onto remotely. All ISPIN Xcustomer sites receive the same ISPIN source code and documentation. Each Xsite compiles the code for its own machines. There are no machine-specific Xprograms in ISPIN. X X X X X **************** FLEXIBILITY ************** X X XFlexibility is another area in which a unique feature of ISPIN allows it to Xexcel. The previously mentioned rtab file is the key to this flexibility. XAll information the ISPIN process needs in order to effect the network Xnegotiation and connection to the printer is contained in the rtab entry. XDue to rtab's uucp-like construction and syntax, systems administrators find Xit familiar, thus encouraging "field" tuning by ISPIN's customers. X X XISPIN's rtab may be modified "on the fly". Changes take effect with the next Xprint request, thereby allowing rapid-fire testing and results. The rtab entry Xalso allows the issuance of commands directly to the printer upon successful Xconnection and before the print job is issued. Likewise, printer-specific Xcommands can be issued after completion of the job. Some sites use these Xfacilities to treat single physical printers as though they were two or Xmore virtual printers, each configured differently. At the conclusion of Xthe print job, the printer is returned to its "normal" state. The rtab can Xalso be configured to adjust the current parameters of the CDN connection. X X XThis unique designed-in flexibility assures that ISPIN will be ready to Xaccomodate printers, networks, and user demands of which we currently know Xnothing. We stopped counting and recording the known printers serviced by XISPIN long ago. X X X X X X X X X X X X X X ATTACHMENT A X X SYSTEMS & SWITCHES X X X XTo date (October, 1991), ISPIN has been successfully installed and tested Xon these computers: X X ALR 486-33 PowerPro X (running SCO UNIX V ODT) X AT&T 3B1 X AT&T 3B2600G X CCI 6/32 MP (CCI SysV) X Compaq with Intel 80286 CPU X (running XENIX) X IBM PC/AT with Intel 80386 CPU X (running XENIX) X IBM PC/AT with Intel 80386 CPU X (running SCO UNIX V.3.2) X Dell 325 with Intel 80386-25 CPU X (Interactive UNIX V.3.2) X Prime EXL 50 X Pyramid 90x X Pyramid 9805 X Pyramid 9810 X Pyramid MIS-4 X Sequent Balance B8 (DYNIX) X Sequent Symmetry (DYNIX) X Unisys 5000 X Zilog Model 31 X Zilog Model 32 X Zilog Model 130 (Rev J OS) X XThe networks upon which ISPIN has been tested so far include: X X CDN (IRS X.25 network with async interface) X Teltone/Tellabs Switch X Gandolph Switch X David Switch X Mitron Switch X Equinox Switch X Neac Switch/PBX X X X X X X X X X X X X X X ATTACHMENT B X X XISPI X X XThe Indianapolis Standard Printer Interface (ISPI) is a similarly named but Xtotally separate and distinct application which serves as a user interface for Xthe spooler/queuer. The ISPI application is fully self-contained, with its own Xsource code, documentation, etc. ISPI creates a menu-driven interface for Xusers to interact with the native spooler/queuer. X X X ISPIN and ISPI are TWO SEPARATE AND DISTINCT APPLICATIONS. X X X Neither depends upon the other for functionality. You may use ISPIN X without ISPI. You may use ISPI without ISPIN. X X X X X X X X X X X X X X X X X X X X X ATTACHMENT C X X X X Discussion Topics X X X- In less than two years, the number of sites using ISPIN has grown from X six beta test sites to more than forty sites. X X X- ISPIN's growth has been solely through peer-level promotion and distri- X bution channels. ISPIN's growth required no high-level support or sponsorship. X The technicians whose job it is to install, maintain, and use the X product have "sold" each other (and their managers) on its superiority. X X X- ISPIN exhibits outstanding portability and flexibility. Strict adherance to X established programming standards and operating system interfaces permits X one source code release to support all of the systems, networks, and X printers ISPIN has encountered. X X X- ISPIN is not a print spooler application. It is an application which X interfaces with the operating system's native spooler, permitting the X support of printers which are not connected directly to the computer. X This allows user and application access and control via standard X operating system commands. X X X- ISPIN is supported by an extensive electronic mail network which employs X both IRS-private MMDF (where available) and UNIX's uucp e-mail. X X X- ISPIN is a dynamic application. Its features and functionality have X been shaped by its customers. Although ISPIN is mature and stable in terms X of operational reliability, it continues to evolve. ISPIN development X and software releases are customer-driven. The rare bug reports are X addressed immediately. Unsolicited customer site suggestions for additional X features are collected until their volume warrants development, testing, X release, and implementation of a new version. Before new release development X begins, the ISPIN customer sites are polled via electronic mail, so that X all are aware of proposed changes and have another opportunity to X provide their input. X X X- ISPIN software distributions (complete release and updates) are available X electronically (via uucp and kermit protocols and via electronic mail); X a streamlined and efficient support mechanism as compared to magnetic media X distribution, saving mag media handling costs and delays. X X X- A full-featured end-user menu interface application is "bundled" with X the ISPIN distribution. ISPI is easily interfaced with current applications. X ISPI supports many valuable features, such as: support for "auxillary" X printers; view file on screen; choose number of copies; download file X to another computer via protocols such as kermit. Like ISPIN, ISPI works X with the operating system's native spooler/queuer. ISPIN may be used X without ISPI, and vice versa. X X X- A unique feature of ISPIN permits extensive "field tuning" of the X application without requiring source code modification. A tabular ASCII X file (named "rtab") contains all necessary information for: access of X system resources; network negotiation (messages, responses, timing); X printer set-up and return of printer and network to "standard" settings. X The format and usage of the rtab file is purposely reminiscent of X a similar component of UNIX's uucp application, so that systems X administrators find the tunable interface is familiar. X X X- ISPIN has been approved for, and released into, the public domain. X X X X X X X X X X X ATTACHMENT D X X ************ FUTURE DIRECTIONS ************ X X X X XFUTURE DIRECTIONS, ISPIN X X Here, in no particular order of importance, are planned features, X fixes, dreams, etc. X X X - Support variable level debug on execution, similar to X uucico. This would be available to the sysadmin via X an rtab flag and argument. X X - Alternative log file for debug, error, and event logging X specified in rtab X X - Variable output packet size X X - TCP/IP interface for ISPIN to support printers on the LAN. X GOSIP later. X X - Add capability to specify in rtab when speed of tty should X change - we go out at an initial speed, tell the net or modem X to change its speed, then immediately change ours to adjust X X - Add capability to specify in rtab to set up the tty at other X than the current generic 8 data bits, 1 stop bit, no parity. X X - Support additional flags and arguments which can be passed X from the lp command line. The string passed as the arg to X the "-o" flag could be parsed by ISPIN for all sorts of X additional functionality. Right now, ISPIN assumes that any X argument to "-o" is a string which will be substituted X for "\U" in the rtab entry. Possibilities include: X X * variable level debug X * alternative log file for debug, error, and event logging X * specification of filters through which data could be X piped before it is sent out by ISPIN X * multiple substitution strings for rtab entry, such as: X \U, \U1, \U2...\Un X * remove file(s) after printing - some lp/lpscheds already X support this, some don't X * optional/alternative file name for banner page X * read data from a named pipe - lp/lpsched won't permit X queueing a file of null length, so giving a named pipe's X file name to lp doesn't work. Under this option, an X existing non-null "dummy" file would be given to lp as X the file arg, but ISPIN would actually read from the X named pipe specified by this optional flag and arg. X * variable dark/light level for toaster interface X X - Allow rtab entries to be "continued" by quoting the newline X character with "\" (backslash). X X - Support Berkeley lpr X X - On dual universe boxes, switch to att if called from ucb X X - Version control code - Programs which interact with users X will show version number, release date, etc on demand. X Programs which don't directly interact with users will X write such info to specified log file on demand. X X - UNIX "man"-style documentation pages X X X X XFUTURE DIRECTIONS, ISPI X X Here, in no particular order of importance, are planned features, X fixes, dreams, etc. X X - Read termcap/terminfo to retrieve the X string which turns on the terminal's auxiliary port instead X of relying solely on the internal hard-coded table. X X - Clear the screen internally (curses or call up from termcap/ X terminfo) instead of system call to "clear". X X - allow ISPI to accept standard input as the print job, like: X X pr bigfile|ispi -B X X This feature will be supported in addition to ISPI's "-s" X feature, which currently offers this capability indirectly. X X - X-windows face (ISPIX?) X X - Support Berkeley lpr X X - On dual universe boxes, switch to att if called from ucb X X - version control code - Programs which interact with users X will show version number, release date, etc on demand. X X - UNIX "man"-style documentation pages X X X X X FUTURE DIRECTIONS, SUPPORT X X - Implement an automated e-mail response/software-distribution X routine with event-logging capabilities. This will allow customer X sites to request and secure the latest ISPIN software release via X a simple e-mail message. It will not require human response at X the software distribution site. X X X X X X X X X X X END_OF_FILE if test 34406 -ne `wc -c <'ISPIN/doc/OVERVIEW'`; then echo shar: \"'ISPIN/doc/OVERVIEW'\" unpacked with wrong size! fi # end of 'ISPIN/doc/OVERVIEW' fi if test -f 'ISPIN/doc/OLD-DOCS/README.beta.3' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'ISPIN/doc/OLD-DOCS/README.beta.3'\" else echo shar: Extracting \"'ISPIN/doc/OLD-DOCS/README.beta.3'\" $14234 characters$ sed "s/^X//" >'ISPIN/doc/OLD-DOCS/README.beta.3' <<'END_OF_FILE' X X X X date: May 15, 1989 X X to: ISPIN Beta Test Site Volunteer X X from: Chief, Operations Branch, Information Systems Division, 35:IS X X subject: Indianapolis Standard Printer Interface (for Network printers) X BETA Test release 3 X X X This is the third version of the beta test release of ISPIN. X X ISPIN.beta.3 contains all of the functionality and features of the X general release, which will be available June 30, 1989. Beta.3 incor- X porates features and fixes which have been identified and suggested X by those beta test sites which have been actively helping us test. X Except for documentation, this is the way the application is going X to look and work. I am no longer soliciting suggestions for functional X changes or added features. X X June 30th will mark approximately one year since ISPIN was just a X gleam in our eyes, and approx nine months since the first keystrokes X were struck in its development. Three months courting and nine months X gestation is generally adequate to produce something as complex and X wonderful as a baby. I think it should more than suffice for a simple X piece of software like this. X X I do, however, still need help identifying and swatting bugs. So X please, if you have time and inclination, install and test this X release soon. X X ISPIN has been successfully installed and tested on: X X Zilog Model 31 X Zilog Model 32 X Zilog Model 130 X AT&T 3B1 X Sequent Balance B8 X Pyramid 90x X X Except for conditional compile statements required to resolve the X differences between Zeus 3.21's nq/dqueuer and System V's lp, X the source is the same for all target environments. X X This third release contains many functional improvements. In no X particular order of significance they are: X X X DEVICES - each rtab entry may now specify from one to ELEVEN (!) X possible cpu ports (/dev/tty*). See ISPIN/doc/rtab. X X X -L flag - Specification of a "-L" flag in an rtab entry enables X event logging for that queue member. See ISPIN/doc/rtab. X The format of an event entry is similar to error entries in the X log. X If the queue member's rtab entry is one which allows the user to X specify the printer's address at runtime, the address is also X part of the log message. The Data Security Analysts should like X that. X X X -D flag and argument - Specification of this flag and appropri- X ate argument string enables detection of mid-job diconnections X and printer power-downs. Looping ensues. This one is my favorite. X See ISPIN/doc/rtab. X X X \### as octal representation - Not literally "\###" but backslash X and three digits as a valid octal representation of any single X ascii character. This representation facility allows considerable X flexibility when specifying commands to be issued to printers X upon connection and disconnection. See ISPIN/doc/rtab. X X X Time-out on all writes - This feature guarantees that a paper X jam, out of ribbon condition, or printer otherwise "on hold" X will not clog your queue. As shipped, the timeout alarm clock X is set for five minutes (300 sec). If you think more should be X specified, modify the constant definition for WRITEWAIT. Don't X specify less, or your poor users won't have time to figure out X where they hid the supply of printer ribbons. X See ISPIN/h/ispin.h. X X X Error messages - All error condition messages written to the log X contain enough information to allow the administrator to re-submit X the failed request on behalf of the user. X If the queue member's rtab entry is one which allows the user to X specify the printer's address at runtime, the address is also X part of the error message. X X X Banner Page - A strictly business banner page, identifying site, X system name, requesting user, file name, queue member(printer X name), and date & time is available. If you saw the banner from X previous releases, you will know what I mean by "strictly business". X The file ISPIN/h/localcnfg.h contains a constant definition of X the site name, so it is locally adjustable at compile time. X X Under nq/dqueuer, the banner is called-for via nq's "-b" flag (or X omission of "-nb"). X X Under System V's lp, there is no explicit flag for specifying X a banner, so I used "-tTITLE". The "-t" must have an arg, X but any arg will do. I just say "-tt" because it is easy to type. X X A word about network etiquette: I propose that all requests for X print jobs should specify a banner unless the banner would be X a hardship for the user (such as when doing single sheet on the X Qume). That way, when the user screws up and sends hardcopy of X the Superbowl pool to the printer in the Commissioner's office, X Inspection will know who to beat up. X X X User-specified printer addresses - You may create rtab entries X which allow the user to specify the address of the target printer X at runtime. Such an rtab entry contains "\U" at the point in the X particular "SEND" sequence(s) where the user-specified address is X to be written to the network. See ISPIN/doc/rtab. X X Under nq/dqueuer, the user-specified address is given as the arg X to nq's "-d" flag, such as "nq -q net:addr1 -d 99999999 filename". X This assumes that the particular SEND sequence has been specified X as "connect\s000000\U\r" for a PACNET/CDN-connected printer. X X Under System V's lp, the user-specified address is given as the X arg to lp's "-o" flag, such as "lp -daddr1 -o99999999 filename". X This assumes that the particular SEND sequence has been specified X as "connect\s000000\U\r" for a PACNET/CDN-connected printer. X X We have suitably enhanced the companion application "ISPI" to X directly support this feature. You decide at compile time X whether you want your ISPI to support this feature of ISPIN by X adjusting two defined constants. One of the constants is X merely a compile line boolean ("-DEXTERN"), the other gives the X complete path to the rtab file (RTAB_PATH). See ISPI/ispi.c X X X Install it anywhere - The file ISPIN/h/localcnfg.h contains the X constant definitions which must be modified prior to compiliation X if you choose to install ISPIN somewhere other than my "default" X location near the native spooler/queuer software. Bear in mind X that if you so choose, you must also modify the install script X accordingly. X X X IQ, the status inquirer - IQ has been significantly enhanced. X It now executes much faster and gives much more explicit info. X Each ISPIN print job goes through several phases of execution X after the native spooler/queuer gives it the goahead. These X phases include: X X STARTUP - The ISPIN reads and parses its rtab entry, notifies X the daemon iqueuer of its existence. X X WAIT for port - The ISPIN is awaiting its "marching orders" X which will be issued by iqueuer. These orders X include which (of possibly many) /dev/tty* X will be used. X X CONNECTING - The ISPIN is negotiating through the network to X establish a connection with the printer. X X PRINTING - The ISPIN is issuing characters to the printer. X X DISCONNECT - The ISPIN is conducting an orderly disconnection X from the printer and the network. Disconnection X is part of the normal sequence of events after X the job has been printed. Disconnection also X takes place after a failure to connect, upon de- X tection of a printer power-down or disconnect, X and subsequent to a time-out condition. X X LOOPING - The ISPIN is in the "sleep" phase of a loop cycle. X An ISPIN will loop if it is unable to establish X connection with the printer due to network busy X conditions or if the printer is disabled. X An ISPIN also loops after a detection of disconnection X or printer power-down, or after a time-out. When the X connection to the printer is (re)established, the job X will be printed in its entirety. The "header" of IQ's X screen output contains a column labeled "LOOP". This X column displays the current loop cycle, X starting with zero. The "as shipped" limit on number X of loops is 10000 (ten thousand). I strongly suggest X that you do not reduce this constant. A looping ISPIN X does not thrash or consume excessive system resources. X Nor does it keep other print jobs from being satisfied. X X X ISPINTRFCE - Under the System V's lp, each spool member has a file X in the directory /usr/spool/lp/interface. The file is named the X same as the printer name. Under beta.1 and beta.2, I required that X each printer's interface file be a separate and complete copy of X the ISPIN executable. This approach cost a good deal of hard disk X real estate on systems with many spool members to support. X Now each printer's interface file is a significantly smaller exe- X cutable called "ispintrfce". Its only function is to exec a cen- X trally located ISPIN executable. The path to the ISPIN must be X known to ispintrfce, so if you don't plan to leave it where my X install script puts it, modify the constant definition for X "INTRFCE" in the file ISPIN/h/localcnfg.h accordingly. X X X X X The tape upon which I have transmitted the application was created X in cpio format. cd to a directory in which you want this release to X be written, then cpio -iudmvB < your_nine_track_drive X X The result of this cpio will be the creation of a directory named X ISPIN.beta.3. ISPIN.beta.3 will contain two subdirectories, namely X ISPI and ISPIN. X X ISPIN contains the source code, install documents, and install X scripts for the new ISPIN application. Of course, the ISPIN X application serves as a BACKEND for either of two native X queuer/spoolers, lp or dqueuer. For this release, I have X organized the directory ISPIN and its contents into subdirectories X using standard names "doc" (for documentation files), "h" (for header X files), "install" (where install scripts exist, and from which they X must be executed), "obj" (where the executables will be placed as X they are compiled), and "src" (where the source code resides). X X Also, under the ISPIN/install directory, is a directory called X lib_rtab. The contents of this directory represent the first offerings X of proven rtab entries for various situations. X See ISPIN/install/lib_rtab/README. X X The ISPI directory contains the freshest version of our ISPI X application. ISPI is an application which serves as a FRONTEND X for the two queuer/spoolers. The ISPI application is fully self- X contained, with its own source code, documentation, etc. Use it X if you like, or don't use it. I sent ISPI along because we have X found it to be an extremely useful tool to support the native X queuer/spoolers. X X ISPIN and ISPI are TWO SEPARATE AND DISTINCT APPLICATIONS. X Neither depends upon the other for functionality. You may use ISPIN X without ISPI. You may use ISPI without ISPIN. X X The documentation of the formal type is growing, and the code is X overflowing with comments. Read everything in the "doc" directory X to get a general idea of what is going on in ISPIN and X its related entities. X X If you are installing this application under ZEUS 3.21 and its X nq/xq/dqueuer queuer family, read NQinstall.doc. X X If you are installing this application under System V UNIX and X the lp spooler, read LPinstall.doc. X X If you have previously installed a prior release of ISPIN, every- X thing you installed before is made obsolete by beta.3. Go through X a complete new installation. You could/should append your old rtab X entries to the new rtab file, saving you a few keystrokes. Even so, X you should modify those entries to take fullest advantage of all X of the new features (especially the "-D" flags and args, which X allow detection and handling of mid-job printer diconnection and X power-down situations). X See ISPIN/install/lib_rtab/README. X X X Feedback is what I need. Please communicate whatever observations X you may have soon and often. X X X X Larry Bartz X X END_OF_FILE if test 14234 -ne `wc -c <'ISPIN/doc/OLD-DOCS/README.beta.3'`; then echo shar: \"'ISPIN/doc/OLD-DOCS/README.beta.3'\" unpacked with wrong size! fi # end of 'ISPIN/doc/OLD-DOCS/README.beta.3' fi if test -f 'ISPIN/misc/SUID.dr/lp_perms.sh' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'ISPIN/misc/SUID.dr/lp_perms.sh'\" else echo shar: Extracting \"'ISPIN/misc/SUID.dr/lp_perms.sh'\" $2166 characters$ sed "s/^X//" >'ISPIN/misc/SUID.dr/lp_perms.sh' <<'END_OF_FILE' X#!/bin/sh X# lp_perms.sh 05/13/91 LSB IRS Indianapolis X# X# This routine sets up a System V, release 2 lp subsystem to behave X# similar to a System V, release 3 lp subsystem with respect to file X# access. It all runs as setuid to superuser. Under this setup, it X# is CRITICALLY IMPORTANT to have an interface program which will X# setgid and setuid back to the user who requested the job, thus X# maintaining security. X# After implementation of this routine and the setgid/setuid interface, X# users will be able to print any file which they themselves can read. X# X# This is the code fragment for ispin which does the trick: X# #ifdef LP X# /* If this process is running as setuid to root (uid == 0), X# then setuid to the requesting user. 05/09/91 LSB */ X# if(geteuid() == 0) X# { X# setgid(pass->pw_gid); X# setuid(pass->pw_uid); X# } X# #endif X# ISPIN.rel_2.1/src/ISPIN.c can be patched with this code fragment after line X# 1269. All ISPIN releases after ISPIN.rel_2.1 will contain this code. X# X# NOTE: ISPIN.rel_2.2 HAS ALREADY BEEN PATCHED WITH THE ABOVE CODE FRAGMENT X# X# change lp's uid to 0 Xset UID Xset LYNE XUID=`grep ^lp\: /etc/passwd|cut -d\: -f3` XLYNE=`grep -n lp\: /etc/passwd|cut -d\: -f1` Xsed $LYNE\ s/\:$UID\:/\:0\:/g /etc/passwd > /tmp/passwd.TMP Xcp /etc/passwd /tmp/passwd.sav Xcp /tmp/passwd.TMP /etc/passwd X# X# lp administrative stuff, superuser only Xchown lp /usr/lib/lpsched Xchmod 700 /usr/lib/lpsched Xchown lp /usr/lib/lpshut Xchmod 700 /usr/lib/lpshut Xchown lp /usr/lib/lpmove Xchmod 700 /usr/lib/lpmove Xchown lp /usr/lib/accept Xchmod 700 /usr/lib/accept Xchown lp /usr/lib/reject Xchmod 700 /usr/lib/reject X# X# lp user stuff Xchown lp /usr/bin/lp Xchmod 4711 /usr/bin/lp Xchown lp /usr/bin/lpstat Xchmod 4711 /usr/bin/lpstat Xchown lp /usr/bin/cancel X# The following lets any user cancel any job, same as before. X# If you don't like that, change 4711 to 700. Then only superuser can cancel. X# Same goes for enable and disable. Xchmod 4711 /usr/bin/cancel Xchown lp /usr/bin/enable Xchmod 4711 /usr/bin/enable Xchown lp /usr/bin/disable Xchmod 4711 /usr/bin/disable END_OF_FILE if test 2166 -ne `wc -c <'ISPIN/misc/SUID.dr/lp_perms.sh'`; then echo shar: \"'ISPIN/misc/SUID.dr/lp_perms.sh'\" unpacked with wrong size! fi chmod +x 'ISPIN/misc/SUID.dr/lp_perms.sh' # end of 'ISPIN/misc/SUID.dr/lp_perms.sh' fi echo shar: End of archive 13 $of 15$. cp /dev/null ark13isdone MISSING="" for I in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ; do if test ! -f ark${I}isdone ; then MISSING="${MISSING} ${I}" fi done if test "${MISSING}" = "" ; then echo You have unpacked all 15 archives. rm -f ark[1-9]isdone ark[1-9][0-9]isdone else echo You still need to unpack the following archives: echo " " ${MISSING} fi ## End of shell archive. exit 0