Path: utzoo!attcan!uunet!lll-winken!sun-barr!newstop!sun!imagen!mark From: mark@imagen.UUCP (Mark Peek) Newsgroups: comp.lang.postscript Subject: Re: What functionality does one need? (Was "IP over Ethernet to printers") Summary: Imagen TCP/IP Protocols Message-ID: <14570@imagen.UUCP> Date: 9 Jul 90 17:29:31 GMT References: <6834@umd5.umd.edu> Organization: Imagen Corp., Santa Clara CA Lines: 39 In article <6834@umd5.umd.edu>, zben@umd5.umd.edu (Ben Cranston) writes: > Last time we looked at Imagen's TCP product it was a simple byte pipe, with > every byte sent being interpreted as Impress and no way to do statue querying > or out-of-band commands. This means if your printer runs out of paper it can > sit there idle all night because the drive software cannot determine WHY it > is not printing and so cannot inform a human operator of that fact. In > tomorrow's world of distributed printing resources we cannot assume the > printer will be centrally located. Well, according to my documentation (dated August 1986), Imagen TCP/IP supports a TCP "simple byte pipe" called TRANSPORT1 for sending data, a UDP connection for obtaining status called STATUS1 and a UDP based connection for accounting (both reliable and unreliable) called ACCOUNTING1. TRANSPORT1 and STATUS1 are seperable or can be used together. The status that is available through STATUS1 include: - Engine not ready - Engine out of paper - Paper jam - Lacking consumables (toner) - Job in progress Using our host software on a Berkeley system, lpq will report back the STATUS1 status for a given printer. I'm not sure how status is reported on System V. Tomorrow's printing will probably be like today's printing, you have work-group, satellite, or centralized printing. This boils down to whether you have an operator and how far you have to walk to pick up your printout. Mark ---- Name: Mark Peek Mail: Imagen Corp. 2650 San Tomas Expressway, P.O. Box 58101 Santa Clara, CA 95052-8101 AT&T: (408) 986-9400 UUCP: mark@imagen.com or ...!{decwrl,sun}!imagen!mark