home *** CD-ROM | disk | FTP | other *** search
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
-
-