home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / unix / volume25 / ispin / part13 < prev    next >
Encoding:
Text File  |  1992-02-01  |  53.7 KB  |  1,314 lines

  1. Newsgroups: comp.sources.unix
  2. From: sir-alan!ispin!lbartz@iuvax.cs.indiana.edu (Larry Bartz)
  3. Subject: v25i124: Indianapolis Standard Printer Interface for Networked printers, Part13/15
  4. Sender: sources-moderator@pa.dec.com
  5. Approved: vixie@pa.dec.com
  6.  
  7. Submitted-By: sir-alan!ispin!lbartz@iuvax.cs.indiana.edu (Larry Bartz)
  8. Posting-Number: Volume 25, Issue 124
  9. Archive-Name: ispin/part13
  10.  
  11. #! /bin/sh
  12. # This is a shell archive.  Remove anything before this line, then unpack
  13. # it by saving it into a file and typing "sh file".  To overwrite existing
  14. # files, type "sh file -c".  You can also feed this as standard input via
  15. # unshar, or by typing "sh <file", e.g..  If this archive is complete, you
  16. # will see the following message at the end:
  17. #        "End of archive 13 (of 15)."
  18. # Contents:  ISPIN/doc/OVERVIEW ISPIN/doc/OLD-DOCS/README.beta.3
  19. #   ISPIN/misc/SUID.dr/lp_perms.sh
  20. # Wrapped by socrates@indy6 on Tue Jan 28 15:27:14 1992
  21. PATH=/bin:/usr/bin:/usr/ucb ; export PATH
  22. if test -f 'ISPIN/doc/OVERVIEW' -a "${1}" != "-c" ; then 
  23.   echo shar: Will not clobber existing file \"'ISPIN/doc/OVERVIEW'\"
  24. else
  25. echo shar: Extracting \"'ISPIN/doc/OVERVIEW'\" \(34406 characters\)
  26. sed "s/^X//" >'ISPIN/doc/OVERVIEW' <<'END_OF_FILE'
  27. X
  28. X                    #     ####   #####      #    #    #
  29. X                    #    #       #    #     #    ##   #
  30. X                    #     ####   #    #     #    # #  #
  31. X                    #         #  #####      #    #  # #
  32. X                    #    #    #  #          #    #   ##
  33. X                    #     ####   #          #    #    #
  34. X
  35. X
  36. 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
  37. X
  38. X                                    for
  39. X
  40. X                     N E T W O R K E D   P R I N T E R S
  41. X
  42. X
  43. X
  44. X
  45. X
  46. X
  47. X             F U N C T I O N  and  D E S I G N   O V E R V I E W
  48. X
  49. X
  50. X
  51. X
  52. X
  53. X
  54. X
  55. X
  56. X
  57. X
  58. X
  59. X
  60. X
  61. X
  62. X
  63. X
  64. X
  65. X
  66. X
  67. X
  68. X
  69. X
  70. X
  71. X
  72. X
  73. X
  74. X
  75. X
  76. X
  77. X
  78. X
  79. X
  80. X
  81. X
  82. X
  83. X
  84. X
  85. X                          CONTENTS
  86. X
  87. XEXECUTIVE OVERVIEW.................................  1
  88. X
  89. X
  90. XGENERAL OVERVIEW...................................  2
  91. X
  92. X
  93. X
  94. X
  95. XATTACHMENT A - SYSTEMS AND SWITCHES................. XX
  96. X
  97. X
  98. XATTACHMENT B - ISPI APPLICATION..................... XX
  99. X
  100. X
  101. XATTACHMENT C - DISCUSSION TOPICS.................... XX
  102. X
  103. X
  104. XATTACHMENT D - FUTURE DIRECTIONS.................... XX
  105. X
  106. X
  107. X
  108. X
  109. X
  110. X
  111. X
  112. X
  113. X
  114. X
  115. X
  116. X
  117. X
  118. X
  119. X
  120. X
  121. X
  122. X
  123. X
  124. X
  125. X
  126. X
  127. X
  128. X
  129. X
  130. X
  131. X
  132. X
  133. X
  134. X
  135. X
  136. X
  137. X
  138. X                                                               Page 1
  139. X
  140. X
  141. X             ************* EXECUTIVE OVERVIEW *****************
  142. X
  143. X
  144. XNetworking of computer resources serves to maximize the potential for
  145. Xefficient utilization of resources. Internal Revenue Service (IRS) has
  146. Xcapitalized upon this potential by establishing and maintaining a wide 
  147. Xarea network. In particular, the networking of printing facilities (printers 
  148. Xand the computers which originate printing activities) permits the widest 
  149. Xpossible access and utilization of expensive and scarce resources.
  150. X
  151. X
  152. XNetworking hardware serves as the primary enabling factor but efficient,
  153. Xreliable software is the only channel through which the promises of
  154. Xnetworking can be realized.
  155. X
  156. X
  157. XISPIN is a unique solution to this problem, owing to its simplicity,
  158. Xreliability, portability, and flexibility. Its simplicity of design and
  159. Xusage is due to its reliance, to the greatest extent possible, on
  160. Xexisting software which is native to the UNIX operating system. ISPIN is
  161. Xreliable because of its unique capabilities to recognize and deal effectively
  162. Xwith error conditions. ISPIN's unique portability and flexibility
  163. Xfeatures provide a wide range of hardware compatibility and assurance for
  164. Xcompliance with future applications. Its rapid success in this regard is
  165. Xevidenced by the fact that more than 40 IRS data processing sites with
  166. Xvarious hardware configurations have implemented ISPIN. These sites have
  167. Ximproved customer support and reduced maintenance overhead through the 
  168. Ximplementation of ISPIN.
  169. X
  170. X
  171. X
  172. X
  173. X
  174. X
  175. X
  176. X
  177. X
  178. X
  179. X
  180. X
  181. X
  182. X
  183. X
  184. X
  185. X
  186. X
  187. X
  188. X
  189. X
  190. X
  191. X
  192. X                                                               Page 2
  193. X
  194. X
  195. X            ****************** BACKGROUND ******************
  196. X
  197. XOVERVIEW
  198. X
  199. XNetwork-connected printers were an intended feature of the Treasury-wide
  200. XConsolidated Data Network (CDN) from its earliest design phases. This feature
  201. Xallows levels of access and flexibility previously unavailable to users
  202. Xof computer systems. When all computer systems and all printers are connected
  203. Xto CDN, a print request can ultimately be routed from any computer
  204. Xto any printer. Such flexibility is an obvious benefit to users of computer
  205. Xsystems. It is also a boon to systems administration and data communication
  206. Xpersonnel, as it eliminates the "hardwired", direct connection of computer
  207. Xand printer, which implies frequent re-cabling and software reconfiguration
  208. Xas user needs and applications evolve. These benefits also accrue on
  209. Xa smaller scale as computer systems and printers are connected to local
  210. Xdata switching equipment.
  211. X
  212. X
  213. XPrinting on network-connected printers requires specialized software
  214. Xsupport in addition to the above-described hardware component. The UNIX
  215. Xoperating system is equipped with a software subsystem known variously
  216. Xas a spooler or queuer. The spooler/queuer subsystem consists of a closely
  217. Xrelated family of programs which: accept the user's request for printing;
  218. Xcoordinate the number and naming of printers known to the system; and
  219. Xschedule the execution of (possibly multiple near-simultaneous) requests for
  220. Xprinting. The "stock" spooler/queuer subsystem assumes that the printers
  221. Xare directly connected to the computer. By itself, the native spooler/queuer
  222. Xis incapable of supporting network printing. Absent from the native utilities
  223. Xis a facility to "negotiate" a connection from the computer, through the
  224. Xnetwork, to the printer.
  225. X
  226. X
  227. XIn 1988, as CDN began to proliferate throughout IRS, the Indianapolis District 
  228. XOffice studied the issue of supporting printers which are not connected 
  229. Xdirectly to a given computer, but are connected to the network.
  230. X
  231. X
  232. XFour major themes shaped our design of a unique solution:
  233. X
  234. X
  235. XFirst, was simplicity. Software which avoids unecessary complexity is easier
  236. Xand less time consuming to install and support on a continuing basis. Simplicity
  237. Xis a significant factor in ISPIN's design.
  238. X
  239. X
  240. XSecond, was reliability. Reliable software possesses sophisticated capabilities
  241. Xto recognize and recover from error conditions. The result is a low failure
  242. Xrate, high user satisfaction, and infrequent technical support required to
  243. Xrectify problems associated with failures. The reliability issue is 
  244. Xaddressed by building fault detection, fault tolerance and fault recovery 
  245. Xfeatures into ISPIN.
  246. X
  247. X
  248. XThird, was flexibility. Little of ISPIN's functionality is pre-programmed, so 
  249. Xit easily adapts to environments it has not previously confronted. ISPIN was 
  250. Xdesigned with flexibility in mind, so the application is viable for many 
  251. Xcombinations of computer systems, networking systems, and printers.
  252. X
  253. X
  254. XFourth was portability. Software which is designed to conform with
  255. Xestablished standards has the greatest potential for a long life cycle and
  256. Xlow long term maintenance costs. ISPIN complies with established 
  257. Xstandards to assure the greatest degree of portability among UNIX operating
  258. Xsystem variants.
  259. X
  260. X
  261. X
  262. X
  263. X             ************* FUNCTIONAL DESCRIPTION ***********
  264. X        
  265. X
  266. X         - The native spooler/queuer subsystem is adequate for hardwired 
  267. X           printers. It accepts enqueueing and cancellation requests, 
  268. X           reports on its status, and allows for adding and removal of queue
  269. X           members (printers). When the spooler/queuer program schedules
  270. X           a user's request for printing, it passes pertinent information to 
  271. X           an executable program or a shell script which sends the print job 
  272. X           via the designated computer port (tty) to the printer. This last 
  273. X           program is known as the backend, or interface.
  274. X
  275. X
  276. X         - We substitute a call to ISPIN for the backend.
  277. X
  278. X
  279. X         - The ISPIN process reads an entry for itself from an ASCII file
  280. X           called "rtab". The rtab is intentionally similar to the uucp
  281. X           L.sys file (or Systems file under HoneyDanBer uucp). There
  282. X           is one rtab entry per virtual printer (any given physical printer
  283. X           may be known or treated as several virtual printers).
  284. X
  285. X
  286. X         - The rtab entry contains the chat data (EXPECT/SEND) necessary
  287. X           for the ISPIN process to negotiate through the network to the
  288. X           printer. This data may also include printer initialization and
  289. X           configuration commands which can be passed both before and after
  290. X           the print job.
  291. X
  292. X
  293. X         - The rtab entry also contains a field which defines which tty(s)
  294. X           (from one to eleven possible) through which the printer may be
  295. X           called.
  296. X
  297. X
  298. X         - The ISPIN process passes a formatted message to a daemon process
  299. X           known as IQUEUER. IQUEUER determines which of the requested
  300. X           ttys is available, and issues a message back to the ISPIN, telling
  301. X           it to proceed, using a particular tty. IQUEUER also maintains
  302. X           lock files, thereby avoiding conflicts with uucp, cu, uugetty,
  303. X           etc.
  304. X
  305. X
  306. X         - The ISPIN process, after receipt of its message from IQUEUER, sets
  307. X           up the tty, negotiates the network, and sends the job to the
  308. X           printer.
  309. X
  310. X
  311. X         - The rtab entry also contains flags and arguments which indicate
  312. X           network and printer busy and fault conditions. The ISPIN process 
  313. X           watches for these indications to determine whether it should
  314. X           terminate and loop or quit.
  315. X
  316. X
  317. X         - All the while, the ISPIN process is under the complete control
  318. X           of the native spooler/queuer. Its status (active or waiting) is
  319. X           known to the native spooler/queuer daemon. It may be cancelled
  320. X           or rescheduled by the operating system's native commands.
  321. X
  322. X
  323. X         - While the ISPIN is "active" with respect to the native queuer,
  324. X           the IQUEUER daemon is notified by the ISPIN process of its
  325. X           current phase of execution (startup, negotiating the network,
  326. X           printing, disconnecting, looping). The current status of all
  327. X           currently executing ISPIN processes may be queried via another
  328. X           command, known as "iq". 
  329. X
  330. X
  331. X         - While this sounds very busy, it is quite efficient and
  332. X           gratifyingly robust. If the printer is offline or busy, or
  333. X           the network is unable to make the connection, the ISPIN will
  334. X           loop and resubmit itself to the IQUEUER. If other jobs are
  335. X           waiting for network access through the tty(s), the looper is
  336. X           made to wait while other potentially successful jobs go ahead.
  337. X           If a Greyhound bus takes out a telephone pole between the CPU and
  338. X           the printer (or other mid-job disconnection), ISPIN detects
  339. X           the fault and loops as above. Upon successful re-connection,
  340. X           the job will be printed in its entirety.
  341. X
  342. X
  343. X
  344. X
  345. X             ****************** SIMPLICITY ******************
  346. X
  347. X
  348. XISPIN is uniquely simple in its design and implementation. It is not a
  349. Xa trivial utility, nor is it simple with respect to its internal workings.
  350. XISPIN consists of four executable programs of approximately 9400 lines of
  351. XC code. ISPIN attains its simplicity and ease of use by relying to the
  352. Xgreatest extent possible on existing software which is native to the
  353. Xoperating system.
  354. X
  355. X
  356. XThe native spooler/queuer is part of the operating system. It is efficient,
  357. Xreliable, and well-documented software. Perhaps as important, the usage and
  358. Xadministration of the native software is already familiar to systems admini-
  359. Xstrators, programmers, and users.
  360. X
  361. X
  362. XAs we studied the native spooler/queuer subsystems, we found that the
  363. Xdesigners of those software subsystems designed a flexible interface
  364. Xat what is known as the "backend" of the spooler/queuer process. This is the
  365. Xpoint at which, in a "hardwired" printer situation, the print job would be
  366. Xsent to the printer. The native spooler/queuer is designed to allow the
  367. Xsystems administrator or systems programmer an opportunity to insert their
  368. Xown special purpose programs as the "backend". This flexible interface
  369. Xfeature is well documented in UNIX systems administration manuals and in
  370. Xother descriptive files which are part of the operating system.
  371. X
  372. X
  373. XThe flexible backend interface was the obvious point at which to attach 
  374. Xdata communication and print request execution software. The
  375. Xefficient, reliable, and familiar native operating system software would 
  376. Xremain and would function as intended. This approach appealed to UNIX 
  377. Xsystems administrators and systems programmers. 
  378. X
  379. X
  380. XCapitalizing upon native UNIX facilities is the "UNIX way" of approaching a 
  381. Xproblem and is generally known as the "tools-based approach" to application 
  382. Xdevelopment. This application development methodology recognizes the strength 
  383. Xand flexibility of the UNIX operating system and the rich inventory of
  384. Xsoftware tools it offers the systems programmer. This approach not only
  385. Xsaves considerable time and effort in development but, done correctly, it
  386. Xvirtually guarantees portability, reliability, and ease of use.
  387. X
  388. X
  389. XIn practice, once ISPIN has been installed on a system (usually in an hour
  390. Xor less, according to current ISPIN customers), all end-user inter-
  391. Xface with requesting and controlling printing activities remains under the
  392. Xcontrol of the native software. In addition, all of the systems administra-
  393. Xtion activities involving adding, removing, enabling, and disabling queue
  394. Xmembers (printers) and manipulating the active queue of print requests also
  395. Xremain under the control of the native software. The only additional demand
  396. XISPIN imposes upon the systems administrator is the addition of a one line
  397. Xentry per printer in an ASCII table (rtab, described later). Even this
  398. Xactivity is usually as simple as duplicating a previously existing line, then
  399. Xmaking trivial changes to the new entry.
  400. X
  401. X
  402. X
  403. X
  404. X             ****************** RELIABILITY *****************
  405. X
  406. X
  407. X
  408. X
  409. XThe issue of fault tolerance was critical. Reliability required facilities 
  410. Xfor detecting and correctly dealing with situations such as: 
  411. X
  412. X  -  printer turned off before successful network connection
  413. X  -  printer turned off or data line lost during print job
  414. X  -  printer on "pause" (such as when out of ribbon or paper) for long periods
  415. X
  416. X
  417. XWe designed ISPIN with unique capacities for detecting and handling fault
  418. Xconditions such as described above.
  419. X
  420. X
  421. XFirst, ISPIN's reliance upon the native spooler/queuer software virtually
  422. Xguarantees that a failure of any particular print request will not jeopardize
  423. Xthe print queue as a whole. The native spooler/queuer subsystem is itself
  424. Xsimple and robust in this aspect.
  425. X
  426. X
  427. XAnother unique feature of ISPIN which enhances its ability to detect fault
  428. Xconditions is ISPIN's "rtab" (for "remote printer table") file. rtab is an
  429. XASCII file which is comprised of a one-line entry for each virtual printer.
  430. X
  431. X
  432. XAn ISPIN process obtains all network negotiation and printer set-up informa-
  433. Xtion (communication messages, communication timing, network responses, printer 
  434. Xconfiguration commands) at run time from the rtab file. None of the information
  435. Xa given ISPIN process requires to make a network connection or detect errors is
  436. Xcompiled into executable code.
  437. X
  438. X
  439. XThe format and usage of the rtab is intentionally reminiscent of UNIX 
  440. Xuucp's "L.sys" or "Systems" file. This style further reinforces the "UNIX way" 
  441. Xflavor of the application. Of particular pertinence here are the various means 
  442. Xby which the systems administrator may easily "tune" an rtab entry to accomodate
  443. Xspecific or peculiar network conditions. All timing factors of the network 
  444. Xnegotiation are minutely adjustable. This is extremely valuable, as for a given
  445. Xlocal switch or CDN "pad" the overall response timing may vary over time. The 
  446. Xrtab also supports the specification of messages the network may issue to 
  447. Xindicate "busy", "error", or "disconnect" conditions. In the course of 
  448. Xnegotiating a network connection, the ISPIN process watches for these responses
  449. Xand behaves accordingly.
  450. X
  451. X
  452. XA most unique feature of ISPIN is that after the successful connection to
  453. Xthe printer, it sends the print job in measured "bursts" of characters. After 
  454. Xeach "burst" ISPIN waits for the output to drain from the system. Both the 
  455. Xaction of issuing the characters and the wait for output to drain are timed. 
  456. XIf the activity takes too long (such as if user puts printer on pause and walks
  457. Xaway, or an unattended paper jam) the ISPIN disconnects from the network and
  458. Xattempts to re-establish the connection. Upon successful connection, the job
  459. Xwill be printed in its entirety. In the course of a normal "no fault" print
  460. Xjob, waiting for the output to drain from the CPU is necessary only to
  461. Xaccomodate flow control, so there is no additional throughput overhead cost.
  462. XThe duration of the wait (if output is not draining) is sufficient to allow
  463. Xthe user to replace a ribbon, clear a paper jam, or correct other faults.
  464. XThis feature is unique to ISPIN.
  465. X
  466. X
  467. XFurthermore, after the issuance of each "burst" of characters, the ISPIN
  468. Xprocess "listens" for any characters which may be coming back to the computer
  469. Xthrough the port which ISPIN is using. Again, in the course of a normal
  470. X"no fault" print job, there will be no characters at all coming back to the
  471. XCPU. ISPIN is performing a "raw" read of the port at this juncture, so
  472. Xif there are no characters to be read, no time will be wasted in waiting.
  473. XIf any characters are received by the ISPIN process, they are compared to
  474. Xmessages which have previously been specified in the rtab entry as
  475. Xindicators of a "disconnect" condition. If there is a match, the ISPIN
  476. Xprocess will effect a logical disconnection, then attempt to re-connect until
  477. Xsuccessful. As above, the job will later be printed in its entirety.
  478. XThis is another feature which is unique to ISPIN.
  479. X
  480. X
  481. XIn UNIX jargon, a daemon is a continuously-running program which is not 
  482. Xassociated with a terminal. ISPIN's "IQUEUER" daemon program controls access 
  483. Xto CPU ports and acts as a server to the native spooler/queuer client processes.
  484. XThe ISPIN print processes are clients which solicit services (access to 
  485. Xsystem communication facilities) from the IQUEUER.
  486. X
  487. X
  488. XIQUEUER assures that ISPIN jobs which are looping due to error conditions
  489. Xdo not "clog" the queue or prevent other potentially successful jobs from
  490. Xexecuting. This too is unique to ISPIN.
  491. X
  492. X
  493. XLogical, predictable behavior of a software system is a valuable trait which
  494. Xis closely related to reliability: unpredictability imparts unreliability.
  495. X
  496. X
  497. XAnother unique feature of ISPIN is in the control of access to the CPU ports 
  498. Xwhich are available for access to the network and, ultimately, to the printers.
  499. XA common feature of UNIX applications which use CPU ports on an infrequent 
  500. Xbasis is the reliance on a file known as a "lock" file. Native UNIX utilities 
  501. Xsuch as "cu", "uucp", and applications such as ISPIN, MDQS, and MMDF all support
  502. Xthis feature. These utilities and applications all check for the existence of 
  503. Xa lock file before they assume control of, and use a CPU port for outbound 
  504. Xcommunication. If a lock file exists, the application assumes a competing 
  505. Xprocess has control of the port resource. If no lock file exists, the applica-
  506. Xtion can assume it has exclusive access to the port, and creates its own lock 
  507. Xfile to exclude potential competing processes. At the conclusion of its task, 
  508. Xthe process removes its own lock file. ISPIN diverges from the others in its 
  509. Xmethod of handling lock file management.
  510. X
  511. X
  512. XUnder other applications, there is no central management of CPU port access or 
  513. Xlock file management. Under ISPIN, all CPU access and lock file management is 
  514. Xcentrally controlled by ISPIN's secondary queueing daemon process, IQUEUER.
  515. X
  516. X
  517. XWhen an ISPIN process is invoked by the native spooler/queuer, it first reads 
  518. Xits configuration information from its entry in the rtab file. It then passes 
  519. Xsome of this data and its own identity to the IQUEUER through an interprocess 
  520. Xcommunication channel (IPC). The ISPIN waits (on a blocking read of its own IPC)
  521. Xfor a "go ahead"  message from the IQUEUER. IQUEUER maintains in-core tables of
  522. XISPIN processes which are waiting, and other tables of those which are currently
  523. Xexecuting, including their current phase or state of execution. The table of 
  524. Xwaiting ISPINs is maintained in first-in, first-out order. ISPIN processes 
  525. Xwhich are looping due to error conditions are put at the back of the line. It 
  526. Xis the IQUEUER's responsibility to check for, create, and later remove lock 
  527. Xfiles. Only upon successful attainment of a lock file does IQUEUER notify the 
  528. XISPIN process of the CPU port it may use, as part of the "go ahead" order. Even
  529. Xin cases where several ISPIN print requests might all require access to the 
  530. Xsame CPU port, IQUEUER will maintain a fair, logical, and predictable job 
  531. Xscheduling operation.
  532. X
  533. X
  534. XISPIN's support of these unique fault tolerance features significantly
  535. Xreduces the number of failed print requests. As a result, technicians at
  536. Xsites which run ISPIN spend little time servicing user requests for 
  537. Xassistance.
  538. X
  539. X
  540. X
  541. X
  542. X                  *********** PORTABILITY **************
  543. X
  544. X
  545. XThe third major theme which drove the design and programming of ISPIN was
  546. Xthe issue of portability and its closely linked companion, flexibility.
  547. XWe committed ourselves to the attainment of this goal in order to assure a 
  548. Xlong and productive future for ISPIN.
  549. X
  550. X
  551. XISPIN was programmed with portability as a principal consideration. We
  552. Xrelied upon an AT&T document, "System V Interface Definition" (SVID) as
  553. Xour guide to portability. The SVID was the backbone of the POSIX definition
  554. Xwhich the Federal Government, and IRS in particular, has adopted as the
  555. Xoperating system of virtually all computers to be procured in the
  556. Xfuture. Compliance with SVID helped to insure future compliance with POSIX.
  557. X
  558. X
  559. XCompliance with SVID in the earliest stages of design and programming was
  560. Xsignificant but was not by itself adequately sufficient to assure portability
  561. Xof ISPIN across all IRS UNIX platforms. Some features of SVID are not
  562. Xbackwards compatible with older versions of UNIX. The modern inter-process
  563. Xcommunication facilities of SVID were not available in the older System III
  564. XUNIX environment of the IRS's large inventory of Zilog S8000 computers.
  565. XWe designed an innovative inter-process communication (IPC) scheme to
  566. Xaddress this situation. The "named pipe", or FIFO, is an IPC facility which
  567. Xis supported by the UNIX kernel. The operating system supports specialized
  568. Xread and write algorithms which are unique to the FIFO type of IPC. We
  569. Xdevised a system in which the ISPIN process communicates with the unrelated
  570. XIQUEUER process (and vice versa) through strictly formatted fixed-length
  571. Xmessages via named pipes. Similar communication facilities exist between
  572. XIQUEUER and IQ, the status inquirer utility of ISPIN. This inter-process
  573. Xcommunication facility is portable across all UNIX systems. The use of a
  574. Xsimilarly named but unrelated C programming technique (unnamed pipes,
  575. Xbetween related processes) is fairly common and well-documented. The FIFO
  576. Xtechnique is only obscurely documented and required considerable research
  577. Xand testing. We devised this unique solution because it is very efficient
  578. Xand because it is portable.
  579. X
  580. X
  581. XWe have succeeded in achieving a unique level of portability for ISPIN.
  582. XISPIN customer sites have successfully installed and executed ISPIN on many
  583. Xcomputer systems we have never seen or even logged onto remotely. All ISPIN
  584. Xcustomer sites receive the same ISPIN source code and documentation. Each
  585. Xsite compiles the code for its own machines. There are no machine-specific
  586. Xprograms in ISPIN.
  587. X
  588. X
  589. X
  590. X
  591. X             **************** FLEXIBILITY **************
  592. X
  593. X
  594. XFlexibility is another area in which a unique feature of ISPIN allows it to
  595. Xexcel. The previously mentioned rtab file is the key to this flexibility.
  596. XAll information the ISPIN process needs in order to effect the network
  597. Xnegotiation and connection to the printer is contained in the rtab entry.
  598. XDue to rtab's uucp-like construction and syntax, systems administrators find
  599. Xit familiar, thus encouraging "field" tuning by ISPIN's customers. 
  600. X
  601. X
  602. XISPIN's rtab may be modified "on the fly". Changes take effect with the next 
  603. Xprint request, thereby allowing rapid-fire testing and results. The rtab entry
  604. Xalso allows the issuance of commands directly to the printer upon successful
  605. Xconnection and before the print job is issued. Likewise, printer-specific
  606. Xcommands can be issued after completion of the job. Some sites use these
  607. Xfacilities to treat single physical printers as though they were two or
  608. Xmore virtual printers, each configured differently. At the conclusion of
  609. Xthe print job, the printer is returned to its "normal" state. The rtab can
  610. Xalso be configured to adjust the current parameters of the CDN connection.
  611. X
  612. X
  613. XThis unique designed-in flexibility assures that ISPIN will be ready to
  614. Xaccomodate printers, networks, and user demands of which we currently know
  615. Xnothing. We stopped counting and recording the known printers serviced by
  616. XISPIN long ago.
  617. X
  618. X
  619. X
  620. X
  621. X
  622. X
  623. X
  624. X
  625. X
  626. X
  627. X
  628. X
  629. X
  630. X                                                           ATTACHMENT A
  631. X
  632. X                              SYSTEMS & SWITCHES
  633. X
  634. X
  635. X
  636. XTo date (October, 1991), ISPIN has been successfully installed and tested 
  637. Xon these computers:
  638. X
  639. X                                     ALR 486-33 PowerPro
  640. X                                             (running SCO UNIX V ODT)
  641. X                                     AT&T  3B1
  642. X                                     AT&T  3B2600G
  643. X                                     CCI 6/32 MP   (CCI SysV)
  644. X                                     Compaq with Intel 80286 CPU
  645. X                                             (running XENIX)
  646. X                                     IBM PC/AT with Intel 80386 CPU
  647. X                                             (running XENIX)
  648. X                                     IBM PC/AT with Intel 80386 CPU
  649. X                                             (running SCO UNIX V.3.2)
  650. X                                     Dell 325 with Intel 80386-25 CPU
  651. X                                     (Interactive UNIX V.3.2)
  652. X                                     Prime EXL 50
  653. X                                     Pyramid 90x
  654. X                                     Pyramid 9805
  655. X                                     Pyramid 9810
  656. X                                     Pyramid MIS-4
  657. X                                     Sequent Balance B8 (DYNIX)
  658. X                                     Sequent Symmetry (DYNIX)
  659. X                                     Unisys 5000
  660. X                                     Zilog Model 31
  661. X                                     Zilog Model 32
  662. X                                     Zilog Model 130 (Rev J OS)
  663. X
  664. XThe networks upon which ISPIN has been tested so far include:
  665. X
  666. X                                     CDN (IRS X.25 network with async interface)
  667. X                                     Teltone/Tellabs Switch
  668. X                                     Gandolph Switch
  669. X                                     David Switch
  670. X                                     Mitron Switch
  671. X                                     Equinox Switch
  672. X                                     Neac Switch/PBX
  673. X
  674. X
  675. X
  676. X
  677. X
  678. X
  679. X
  680. X
  681. X
  682. X
  683. X
  684. X
  685. X
  686. X                                                           ATTACHMENT B
  687. X
  688. X
  689. XISPI
  690. X
  691. X
  692. XThe Indianapolis Standard Printer Interface (ISPI) is a similarly named but
  693. Xtotally separate and distinct application which serves as a user interface for 
  694. Xthe spooler/queuer. The ISPI application is fully self-contained, with its own
  695. Xsource code, documentation, etc. ISPI creates a menu-driven interface for
  696. Xusers to interact with the native spooler/queuer.
  697. X
  698. X
  699. X        ISPIN and ISPI are TWO SEPARATE AND DISTINCT APPLICATIONS.
  700. X
  701. X
  702. X        Neither depends upon the other for functionality. You may use ISPIN
  703. X        without ISPI. You may use ISPI without ISPIN.
  704. X
  705. X
  706. X
  707. X
  708. X
  709. X
  710. X
  711. X
  712. X
  713. X
  714. X
  715. X
  716. X
  717. X
  718. X
  719. X
  720. X
  721. X
  722. X
  723. X
  724. X                                                           ATTACHMENT C
  725. X
  726. X
  727. X
  728. X                         Discussion Topics
  729. X
  730. X
  731. X- In less than two years, the number of sites using ISPIN has grown from
  732. X  six beta test sites to more than forty sites.
  733. X
  734. X
  735. X- ISPIN's growth has been solely through peer-level promotion and distri-
  736. X  bution channels. ISPIN's growth required no high-level support or sponsorship.
  737. X  The technicians whose job it is to install, maintain, and use the
  738. X  product have "sold" each other (and their managers) on its superiority.
  739. X
  740. X
  741. X- ISPIN exhibits outstanding portability and flexibility. Strict adherance to
  742. X  established programming standards and operating system interfaces permits
  743. X  one source code release to support all of the systems, networks, and
  744. X  printers ISPIN has encountered.
  745. X
  746. X
  747. X- ISPIN is not a print spooler application. It is an application which
  748. X  interfaces with the operating system's native spooler, permitting the
  749. X  support of printers which are not connected directly to the computer.
  750. X  This allows user and application access and control via standard
  751. X  operating system commands.
  752. X
  753. X
  754. X- ISPIN is supported by an extensive electronic mail network which employs
  755. X  both IRS-private MMDF (where available) and UNIX's uucp e-mail.
  756. X
  757. X
  758. X- ISPIN is a dynamic application. Its features and functionality have
  759. X  been shaped by its customers. Although ISPIN is mature and stable in terms
  760. X  of operational reliability, it continues to evolve. ISPIN development
  761. X  and software releases are customer-driven. The rare bug reports are
  762. X  addressed immediately. Unsolicited customer site suggestions for additional
  763. X  features are collected until their volume warrants development, testing, 
  764. X  release, and implementation of a new version. Before new release development 
  765. X  begins, the ISPIN customer sites are polled via electronic mail, so that
  766. X  all are aware of proposed changes and have another opportunity to
  767. X  provide their input.
  768. X
  769. X
  770. X- ISPIN software distributions (complete release and updates) are available
  771. X  electronically (via uucp and kermit protocols and via electronic mail); 
  772. X  a streamlined and efficient support mechanism as compared to magnetic media
  773. X  distribution, saving mag media handling costs and delays.
  774. X
  775. X
  776. X- A full-featured end-user menu interface application is "bundled" with
  777. X  the ISPIN distribution. ISPI is easily interfaced with current applications.
  778. X  ISPI supports many valuable features, such as: support for "auxillary"
  779. X  printers; view file on screen; choose number of copies; download file
  780. X  to another computer via protocols such as kermit. Like ISPIN, ISPI works
  781. X  with the operating system's native spooler/queuer. ISPIN may be used
  782. X  without ISPI, and vice versa.
  783. X
  784. X
  785. X- A unique feature of ISPIN permits extensive "field tuning" of the
  786. X  application without requiring source code modification. A tabular ASCII
  787. X  file (named "rtab") contains all necessary information for: access of
  788. X  system resources; network negotiation (messages, responses, timing);
  789. X  printer set-up and return of printer and network to "standard" settings.
  790. X  The format and usage of the rtab file is purposely reminiscent of
  791. X  a similar component of UNIX's uucp application, so that systems
  792. X  administrators find the tunable interface is familiar.
  793. X
  794. X
  795. X- ISPIN has been approved for, and released into, the public domain.
  796. X
  797. X
  798. X
  799. X
  800. X
  801. X
  802. X
  803. X
  804. X
  805. X
  806. X                                                           ATTACHMENT D
  807. X
  808. X                ************ FUTURE DIRECTIONS ************
  809. X
  810. X
  811. X
  812. X
  813. XFUTURE DIRECTIONS, ISPIN
  814. X
  815. X   Here, in no particular order of importance, are planned features,
  816. X   fixes, dreams, etc.
  817. X
  818. X
  819. X         - Support variable level debug on execution, similar to
  820. X           uucico. This would be available to the sysadmin via
  821. X           an rtab flag and argument.
  822. X
  823. X         - Alternative log file for debug, error, and event logging
  824. X           specified in rtab
  825. X
  826. X         - Variable output packet size
  827. X
  828. X         - TCP/IP interface for ISPIN to support printers on the LAN.
  829. X           GOSIP later.
  830. X
  831. X         - Add capability to specify in rtab when speed of tty should
  832. X           change - we go out at an initial speed, tell the net or modem
  833. X           to change its speed, then immediately change ours to adjust
  834. X
  835. X         - Add capability to specify in rtab to set up the tty at other
  836. X           than the current generic 8 data bits, 1 stop bit, no parity.
  837. X
  838. X         - Support additional flags and arguments which can be passed
  839. X           from the lp command line. The string passed as the arg to
  840. X           the "-o" flag could be parsed by ISPIN for all sorts of
  841. X           additional functionality. Right now, ISPIN assumes that any
  842. X           argument to "-o" is a string which will be substituted
  843. X           for "\U" in the rtab entry. Possibilities  include:
  844. X
  845. X             * variable level debug
  846. X             * alternative log file for debug, error, and event logging
  847. X             * specification of filters through which data could be
  848. X               piped before it is sent out by ISPIN
  849. X             * multiple substitution strings for rtab entry, such as:
  850. X               \U, \U1, \U2...\Un
  851. X             * remove file(s) after printing - some lp/lpscheds already
  852. X               support this, some don't
  853. X             * optional/alternative file name for banner page
  854. X             * read data from a named pipe - lp/lpsched won't permit
  855. X               queueing a file of null length, so giving a named pipe's
  856. X               file name to lp doesn't work. Under this option, an
  857. X               existing non-null "dummy" file would be given to lp as
  858. X               the file arg, but ISPIN would actually read from the
  859. X               named pipe specified by this optional flag and arg.
  860. X             * variable dark/light level for toaster interface
  861. X
  862. X         - Allow rtab entries to be "continued" by quoting the newline
  863. X           character with "\" (backslash).
  864. X
  865. X         - Support Berkeley lpr 
  866. X
  867. X         - On dual universe boxes, switch to att if called from ucb
  868. X
  869. X         - Version control code - Programs which interact with users
  870. X           will show version number, release date, etc on demand.
  871. X           Programs which don't directly interact with users will 
  872. X           write such info to specified log file on demand.
  873. X
  874. X         - UNIX "man"-style documentation pages
  875. X
  876. X
  877. X
  878. X
  879. XFUTURE DIRECTIONS, ISPI
  880. X
  881. X   Here, in no particular order of importance, are planned features,
  882. X   fixes, dreams, etc.
  883. X
  884. X         - Read termcap/terminfo to retrieve the
  885. X           string which turns on the terminal's auxiliary port instead
  886. X           of relying solely on the internal hard-coded table.
  887. X
  888. X         - Clear the screen internally (curses or call up from termcap/
  889. X           terminfo) instead of system call to "clear".
  890. X
  891. X         - allow ISPI to accept standard input as the print job, like:
  892. X
  893. X                 pr bigfile|ispi -B
  894. X
  895. X           This feature will be supported in addition to ISPI's "-s"
  896. X           feature, which currently offers this capability indirectly.
  897. X
  898. X         - X-windows face (ISPIX?)
  899. X
  900. X         - Support Berkeley lpr
  901. X
  902. X         - On dual universe boxes, switch to att if called from ucb
  903. X
  904. X         - version control code - Programs which interact with users
  905. X           will show version number, release date, etc on demand.
  906. X
  907. X         - UNIX "man"-style documentation pages
  908. X
  909. X
  910. X
  911. X
  912. X   FUTURE DIRECTIONS, SUPPORT
  913. X
  914. X         - Implement an automated e-mail response/software-distribution
  915. X           routine with event-logging capabilities. This will allow customer 
  916. X           sites to request and secure the latest ISPIN software release via 
  917. X           a simple e-mail message. It will not require human response at
  918. X           the software distribution site. 
  919. X
  920. X
  921. X
  922. X
  923. X
  924. X
  925. X
  926. X
  927. X
  928. X
  929. X
  930. END_OF_FILE
  931. if test 34406 -ne `wc -c <'ISPIN/doc/OVERVIEW'`; then
  932.     echo shar: \"'ISPIN/doc/OVERVIEW'\" unpacked with wrong size!
  933. fi
  934. # end of 'ISPIN/doc/OVERVIEW'
  935. fi
  936. if test -f 'ISPIN/doc/OLD-DOCS/README.beta.3' -a "${1}" != "-c" ; then 
  937.   echo shar: Will not clobber existing file \"'ISPIN/doc/OLD-DOCS/README.beta.3'\"
  938. else
  939. echo shar: Extracting \"'ISPIN/doc/OLD-DOCS/README.beta.3'\" \(14234 characters\)
  940. sed "s/^X//" >'ISPIN/doc/OLD-DOCS/README.beta.3' <<'END_OF_FILE'
  941. X
  942. X
  943. X
  944. X        date:     May 15, 1989
  945. X
  946. X        to:       ISPIN Beta Test Site Volunteer
  947. X
  948. X        from:     Chief, Operations Branch, Information Systems Division, 35:IS
  949. X
  950. X        subject:  Indianapolis Standard Printer Interface (for Network printers)
  951. X                  BETA Test release 3
  952. X
  953. X
  954. X        This is the third version of the beta test release of ISPIN.
  955. X
  956. X        ISPIN.beta.3 contains all of the functionality and features of the 
  957. X        general release, which will be available June 30, 1989. Beta.3 incor-
  958. X        porates features and fixes which have been identified and suggested
  959. X        by those beta test sites which have been actively helping us test.
  960. X        Except for documentation, this is the way the application is going
  961. X        to look and work. I am no longer soliciting suggestions for functional
  962. X        changes or added features.
  963. X
  964. X        June 30th will mark approximately one year since ISPIN was just a
  965. X        gleam in our eyes, and approx nine months since the first keystrokes
  966. X        were struck in its development. Three months courting and nine months
  967. X        gestation is generally adequate to produce something as complex and
  968. X        wonderful as a baby. I think it should more than suffice for a simple
  969. X        piece of software like this.
  970. X
  971. X        I do, however, still need help identifying and swatting bugs. So
  972. X        please, if you have time and inclination, install and test this
  973. X        release soon.
  974. X
  975. X        ISPIN has been successfully installed and tested on:
  976. X
  977. X                                     Zilog Model 31
  978. X                                     Zilog Model 32
  979. X                                     Zilog Model 130
  980. X                                     AT&T  3B1
  981. X                                     Sequent Balance B8
  982. X                                     Pyramid 90x
  983. X
  984. X        Except for conditional compile statements required to resolve the
  985. X        differences between Zeus 3.21's nq/dqueuer and System V's lp,
  986. X        the source is the same for all target environments.
  987. X
  988. X        This third release contains many functional improvements. In no
  989. X        particular order of significance they are:
  990. X
  991. X
  992. X            DEVICES - each rtab entry may now specify from one to ELEVEN (!)
  993. X            possible cpu ports (/dev/tty*). See ISPIN/doc/rtab.
  994. X
  995. X
  996. X            -L flag - Specification of a "-L" flag in an rtab entry enables
  997. X            event logging for that queue member. See ISPIN/doc/rtab.
  998. X            The format of an event entry is similar to error entries in the 
  999. X            log.
  1000. X            If the queue member's rtab entry is one which allows the user to
  1001. X            specify the printer's address at runtime, the address is also
  1002. X            part of the log message. The Data Security Analysts should like
  1003. X            that.
  1004. X
  1005. X
  1006. X            -D flag and argument - Specification of this flag and appropri-
  1007. X             ate argument string enables detection of mid-job diconnections
  1008. X             and printer power-downs. Looping ensues. This one is my favorite.
  1009. X             See ISPIN/doc/rtab.
  1010. X
  1011. X
  1012. X            \### as octal representation - Not literally "\###" but backslash
  1013. X            and three digits as a valid octal representation of any single
  1014. X            ascii character. This representation facility allows considerable
  1015. X            flexibility when specifying commands to be issued to printers
  1016. X            upon connection and disconnection. See ISPIN/doc/rtab.
  1017. X
  1018. X
  1019. X            Time-out on all writes - This feature guarantees that a paper
  1020. X            jam, out of ribbon condition, or printer otherwise "on hold"
  1021. X            will not clog your queue. As shipped, the timeout alarm clock
  1022. X            is set for five minutes (300 sec). If you think more should be
  1023. X            specified, modify the constant definition for WRITEWAIT. Don't 
  1024. X            specify less, or your poor users won't have time to figure out
  1025. X            where they hid the supply of printer ribbons.
  1026. X            See ISPIN/h/ispin.h.
  1027. X
  1028. X
  1029. X            Error messages - All error condition messages written to the log
  1030. X            contain enough information to allow the administrator to re-submit
  1031. X            the failed request on behalf of the user.
  1032. X            If the queue member's rtab entry is one which allows the user to
  1033. X            specify the printer's address at runtime, the address is also
  1034. X            part of the error message.
  1035. X
  1036. X
  1037. X            Banner Page - A strictly business banner page, identifying site,
  1038. X            system name, requesting user, file name, queue member(printer
  1039. X            name), and date & time is available. If you saw the banner from
  1040. X            previous releases, you will know what I mean by "strictly business".
  1041. X            The file ISPIN/h/localcnfg.h contains a constant definition of
  1042. X            the site name, so it is locally adjustable at compile time.
  1043. X
  1044. X              Under nq/dqueuer, the banner is called-for via nq's "-b" flag (or
  1045. X              omission of "-nb").
  1046. X
  1047. X              Under System V's lp, there is no explicit flag for specifying 
  1048. X              a banner, so I used "-tTITLE". The "-t" must have an arg, 
  1049. X              but any arg will do. I just say "-tt" because it is easy to type.
  1050. X
  1051. X              A word about network etiquette: I propose that all requests for
  1052. X              print jobs should specify a banner unless the banner would be
  1053. X              a hardship for the user (such as when doing single sheet on the
  1054. X              Qume). That way, when the user screws up and sends hardcopy of
  1055. X              the Superbowl pool to the printer in the Commissioner's office,
  1056. X              Inspection will know who to beat up.
  1057. X              
  1058. X
  1059. X            User-specified printer addresses - You may create rtab entries
  1060. X            which allow the user to specify the address of the target printer
  1061. X            at runtime. Such an rtab entry contains "\U" at the point in the
  1062. X            particular "SEND" sequence(s) where the user-specified address is
  1063. X            to be written to the network. See ISPIN/doc/rtab.
  1064. X
  1065. X              Under nq/dqueuer, the user-specified address is given as the arg
  1066. X              to nq's "-d" flag, such as "nq -q net:addr1 -d 99999999 filename".
  1067. X              This assumes that the particular SEND sequence has been specified
  1068. X              as "connect\s000000\U\r" for a PACNET/CDN-connected printer.
  1069. X
  1070. X              Under System V's lp, the user-specified address is given as the
  1071. X              arg to lp's "-o" flag, such as "lp -daddr1 -o99999999 filename".
  1072. X              This assumes that the particular SEND sequence has been specified
  1073. X              as "connect\s000000\U\r" for a PACNET/CDN-connected printer.
  1074. X
  1075. X              We have suitably enhanced the companion application "ISPI" to
  1076. X              directly support this feature. You decide at compile time 
  1077. X              whether you want your ISPI to support this feature of ISPIN by
  1078. X              adjusting two defined constants. One of the constants is
  1079. X              merely a compile line boolean ("-DEXTERN"), the other gives the
  1080. X              complete path to the rtab file (RTAB_PATH). See ISPI/ispi.c
  1081. X
  1082. X
  1083. X            Install it anywhere - The file ISPIN/h/localcnfg.h contains the
  1084. X            constant definitions which must be modified prior to compiliation
  1085. X            if you choose to install ISPIN somewhere other than my "default"
  1086. X            location near the native spooler/queuer software. Bear in mind
  1087. X            that if you so choose, you must also modify the install script
  1088. X            accordingly.
  1089. X
  1090. X
  1091. X            IQ, the status inquirer - IQ has been significantly enhanced.
  1092. X            It now executes much faster and gives much more explicit info.
  1093. X            Each ISPIN print job goes through several phases of execution
  1094. X            after the native spooler/queuer gives it the goahead. These 
  1095. X            phases include:
  1096. X
  1097. X              STARTUP - The ISPIN reads and parses its rtab entry, notifies
  1098. X                        the daemon iqueuer of its existence.
  1099. X
  1100. X              WAIT for port - The ISPIN is awaiting its "marching orders"
  1101. X                              which will be issued by iqueuer. These orders
  1102. X                              include which (of possibly many) /dev/tty*
  1103. X                              will be used.
  1104. X
  1105. X              CONNECTING - The ISPIN is negotiating through the network to
  1106. X                           establish a connection with the printer.
  1107. X
  1108. X              PRINTING - The ISPIN is issuing characters to the printer.
  1109. X
  1110. X              DISCONNECT - The ISPIN is conducting an orderly disconnection
  1111. X                           from the printer and the network. Disconnection
  1112. X                           is part of the normal sequence of events after
  1113. X                           the job has been printed. Disconnection also
  1114. X                           takes place after a failure to connect, upon de-
  1115. X                           tection of a printer power-down or disconnect,
  1116. X                           and subsequent to a time-out condition.
  1117. X
  1118. X              LOOPING - The ISPIN is in the "sleep" phase of a loop cycle.
  1119. X                        An ISPIN will loop if it is unable to establish
  1120. X                        connection with the printer due to network busy
  1121. X                        conditions or if the printer is disabled.
  1122. X                        An ISPIN also loops after a detection of disconnection
  1123. X                        or printer power-down, or after a time-out. When the
  1124. X                        connection to the printer is (re)established, the job
  1125. X                        will be printed in its entirety. The "header" of IQ's
  1126. X                        screen output contains a column labeled "LOOP". This
  1127. X                        column displays the current loop cycle,
  1128. X                        starting with zero. The "as shipped" limit on number
  1129. X                        of loops is 10000 (ten thousand). I strongly suggest
  1130. X                        that you do not reduce this constant. A looping ISPIN
  1131. X                        does not thrash or consume excessive system resources.
  1132. X                        Nor does it keep other print jobs from being satisfied.
  1133. X
  1134. X
  1135. X            ISPINTRFCE - Under the System V's lp, each spool member has a file
  1136. X            in the directory /usr/spool/lp/interface. The file is named the
  1137. X            same as the printer name. Under beta.1 and beta.2, I required that
  1138. X            each printer's interface file be a separate and complete copy of
  1139. X            the ISPIN executable. This approach cost a good deal of hard disk
  1140. X            real estate on systems with many spool members to support.
  1141. X            Now each printer's interface file is a significantly smaller exe-
  1142. X            cutable called "ispintrfce". Its only function is to exec a cen-
  1143. X            trally located ISPIN executable. The path to the ISPIN must be
  1144. X            known to ispintrfce, so if you don't plan to leave it where my
  1145. X            install script puts it, modify the constant definition for
  1146. X            "INTRFCE" in the file ISPIN/h/localcnfg.h accordingly.
  1147. X                        
  1148. X                        
  1149. X            
  1150. X
  1151. X        The tape upon which I have transmitted the application was created
  1152. X        in cpio format. cd to a directory in which you want this release to
  1153. X        be written, then      cpio -iudmvB < your_nine_track_drive
  1154. X
  1155. X        The result of this cpio will be the creation of a directory named
  1156. X        ISPIN.beta.3. ISPIN.beta.3 will contain two subdirectories, namely
  1157. X        ISPI and ISPIN.
  1158. X
  1159. X        ISPIN contains the source code, install documents, and install
  1160. X        scripts for the new ISPIN application. Of course, the ISPIN
  1161. X        application serves as a BACKEND for either of two native
  1162. X        queuer/spoolers, lp or dqueuer. For this release, I have
  1163. X        organized the directory ISPIN and its contents into subdirectories
  1164. X        using standard names "doc" (for documentation files), "h" (for header
  1165. X        files), "install" (where install scripts exist, and from which they
  1166. X        must be executed), "obj" (where the executables will be placed as
  1167. X        they are compiled), and "src" (where the source code resides).
  1168. X
  1169. X        Also, under the ISPIN/install directory, is a directory called
  1170. X        lib_rtab. The contents of this directory represent the first offerings
  1171. X        of proven rtab entries for various situations.
  1172. X        See ISPIN/install/lib_rtab/README.
  1173. X
  1174. X        The ISPI directory contains the freshest version of our ISPI
  1175. X        application. ISPI is an application which serves as a FRONTEND
  1176. X        for the two queuer/spoolers. The ISPI application is fully self-
  1177. X        contained, with its own source code, documentation, etc. Use it
  1178. X        if you like, or don't use it. I sent ISPI along because we have
  1179. X        found it to be an extremely useful tool to support the native
  1180. X        queuer/spoolers.
  1181. X
  1182. X        ISPIN and ISPI are TWO SEPARATE AND DISTINCT APPLICATIONS.
  1183. X        Neither depends upon the other for functionality. You may use ISPIN
  1184. X        without ISPI. You may use ISPI without ISPIN.
  1185. X
  1186. X        The documentation of the formal type is growing, and the code is
  1187. X        overflowing with comments. Read everything in the "doc" directory
  1188. X        to get a general idea of what is going on in ISPIN and
  1189. X        its related entities.
  1190. X
  1191. X        If you are installing this application under ZEUS 3.21 and its
  1192. X        nq/xq/dqueuer queuer family, read NQinstall.doc.
  1193. X
  1194. X        If you are installing this application under System V UNIX and
  1195. X        the lp spooler, read LPinstall.doc.
  1196. X
  1197. X        If you have previously installed a prior release of ISPIN, every-
  1198. X        thing you installed before is made obsolete by beta.3. Go through
  1199. X        a complete new installation. You could/should append your old rtab
  1200. X        entries to the new rtab file, saving you a few keystrokes. Even so,
  1201. X        you should modify those entries to take fullest advantage of all
  1202. X        of the new features (especially the "-D" flags and args, which
  1203. X        allow detection and handling of mid-job printer diconnection and
  1204. X        power-down situations).
  1205. X        See ISPIN/install/lib_rtab/README.
  1206. X
  1207. X
  1208. X        Feedback is what I need. Please communicate whatever observations
  1209. X        you may have soon and often.
  1210. X
  1211. X
  1212. X  
  1213. X                                                         Larry Bartz
  1214. X
  1215. X
  1216. END_OF_FILE
  1217. if test 14234 -ne `wc -c <'ISPIN/doc/OLD-DOCS/README.beta.3'`; then
  1218.     echo shar: \"'ISPIN/doc/OLD-DOCS/README.beta.3'\" unpacked with wrong size!
  1219. fi
  1220. # end of 'ISPIN/doc/OLD-DOCS/README.beta.3'
  1221. fi
  1222. if test -f 'ISPIN/misc/SUID.dr/lp_perms.sh' -a "${1}" != "-c" ; then 
  1223.   echo shar: Will not clobber existing file \"'ISPIN/misc/SUID.dr/lp_perms.sh'\"
  1224. else
  1225. echo shar: Extracting \"'ISPIN/misc/SUID.dr/lp_perms.sh'\" \(2166 characters\)
  1226. sed "s/^X//" >'ISPIN/misc/SUID.dr/lp_perms.sh' <<'END_OF_FILE'
  1227. X#!/bin/sh
  1228. X# lp_perms.sh     05/13/91    LSB     IRS Indianapolis
  1229. X#
  1230. X# This routine sets up a System V, release 2 lp subsystem to behave
  1231. X# similar to a System V, release 3 lp subsystem with respect to file
  1232. X# access. It all runs as setuid to superuser. Under this setup, it
  1233. X# is CRITICALLY IMPORTANT to have an interface program which will
  1234. X# setgid and setuid back to the user who requested the job, thus
  1235. X# maintaining security. 
  1236. X# After implementation of this routine and the setgid/setuid interface,
  1237. X# users will be able to print any file which they themselves can read.
  1238. X#
  1239. X# This is the code fragment for ispin which does the trick:
  1240. X#     #ifdef LP
  1241. X#           /* If this process is running as setuid to root (uid == 0),
  1242. X#              then setuid to the requesting user.      05/09/91  LSB   */
  1243. X#           if(geteuid() == 0)
  1244. X#           {
  1245. X#             setgid(pass->pw_gid);
  1246. X#             setuid(pass->pw_uid);
  1247. X#           }
  1248. X#     #endif
  1249. X# ISPIN.rel_2.1/src/ISPIN.c can be patched with this code fragment after line
  1250. X# 1269. All ISPIN releases after ISPIN.rel_2.1 will contain this code.
  1251. X#
  1252. X# NOTE: ISPIN.rel_2.2 HAS ALREADY BEEN PATCHED WITH THE ABOVE CODE FRAGMENT
  1253. X#
  1254. X# change lp's uid to 0
  1255. Xset UID
  1256. Xset LYNE
  1257. XUID=`grep ^lp\: /etc/passwd|cut -d\: -f3`
  1258. XLYNE=`grep -n lp\: /etc/passwd|cut -d\: -f1`
  1259. Xsed $LYNE\ s/\:$UID\:/\:0\:/g /etc/passwd > /tmp/passwd.TMP
  1260. Xcp /etc/passwd /tmp/passwd.sav
  1261. Xcp /tmp/passwd.TMP /etc/passwd
  1262. X#
  1263. X# lp administrative stuff, superuser only
  1264. Xchown lp /usr/lib/lpsched
  1265. Xchmod 700 /usr/lib/lpsched
  1266. Xchown lp /usr/lib/lpshut
  1267. Xchmod 700 /usr/lib/lpshut
  1268. Xchown lp /usr/lib/lpmove
  1269. Xchmod 700 /usr/lib/lpmove
  1270. Xchown lp /usr/lib/accept
  1271. Xchmod 700 /usr/lib/accept
  1272. Xchown lp /usr/lib/reject
  1273. Xchmod 700 /usr/lib/reject
  1274. X#
  1275. X# lp user stuff
  1276. Xchown lp /usr/bin/lp
  1277. Xchmod 4711 /usr/bin/lp
  1278. Xchown lp /usr/bin/lpstat
  1279. Xchmod 4711 /usr/bin/lpstat
  1280. Xchown lp /usr/bin/cancel
  1281. X# The following lets any user cancel any job, same as before.
  1282. X# If you don't like that, change 4711 to 700. Then only superuser can cancel.
  1283. X# Same goes for enable and disable.
  1284. Xchmod 4711 /usr/bin/cancel
  1285. Xchown lp /usr/bin/enable
  1286. Xchmod 4711 /usr/bin/enable
  1287. Xchown lp /usr/bin/disable
  1288. Xchmod 4711 /usr/bin/disable
  1289. END_OF_FILE
  1290. if test 2166 -ne `wc -c <'ISPIN/misc/SUID.dr/lp_perms.sh'`; then
  1291.     echo shar: \"'ISPIN/misc/SUID.dr/lp_perms.sh'\" unpacked with wrong size!
  1292. fi
  1293. chmod +x 'ISPIN/misc/SUID.dr/lp_perms.sh'
  1294. # end of 'ISPIN/misc/SUID.dr/lp_perms.sh'
  1295. fi
  1296. echo shar: End of archive 13 \(of 15\).
  1297. cp /dev/null ark13isdone
  1298. MISSING=""
  1299. for I in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ; do
  1300.     if test ! -f ark${I}isdone ; then
  1301.     MISSING="${MISSING} ${I}"
  1302.     fi
  1303. done
  1304. if test "${MISSING}" = "" ; then
  1305.     echo You have unpacked all 15 archives.
  1306.     rm -f ark[1-9]isdone ark[1-9][0-9]isdone
  1307. else
  1308.     echo You still need to unpack the following archives:
  1309.     echo "        " ${MISSING}
  1310. fi
  1311. ##  End of shell archive.
  1312. exit 0
  1313.  
  1314.