🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: fa.laser-lovers
Article #55

Re: Services and a question

#55
From: laser-lovers
Date: Mon, 14 Oct 1985 02:07
34 lines
2658 bytes
From: Robert Morris <ram%umass-boston.csnet@csnet-relay.arpa>

At Interleaf we support both protocols (from different hosts). The
spp is more robust and also capabable of reporting more error conditions.
The robustness may not be an issue on short cables. The byte stream protocol
seems to be more useful than the spp in a VMS environment, because VMS has
such an inflexible spooling system (for example, it is a little tough to get
it to send things transparently and not add special control characters to
help the printer along....). On Sun systems we support the spp and do a fair
bit of printer condition reporting.

btw, old versions of Imagen's spp made it difficult to force a page out of the
printer just because it was fully sent to the host (namely, if the page boundary
did not occur on a packet boundary nor on the job boundary, their software
did not send an incomplete packet (other than at the job end)). I don't know if
later software fixed this, but one can envision circumstances where one
might want the host to pause in the middle of the job and await
operator intervention at the printer, some schemes for which require
sending partial impress jobs and continuing later under software control. For
example, if you want to do double sided printing on an 8/300 and provide for
timeouts (i.e. the printer should not require intervention to continue 
if no one turns the paper withing N minutes), you are lead to such a solution.
So, if you modified Imagen software to implement this you may not get quite
enough use of the spp without a little thought.  I believe there is a similar
problem with ethernet protocols, and it may be hopeless with the byte stream
protocol. A nice hardware solution(?) would be if printer vendors could insure
that there is a way for an operator to do something physical at the printer
which could be detected by the host. Then an operator who successfully changed
paper, etc., could notify the host software to continue.
This seems simpler than the elaborate printer control mechanisms in Interpress.

bob morris
interleaf, inc.
and UMASS/Boston
Technical Details
Message-ID: <1648@uw-beaver>
Path: arc1-ca.pugleaf.net!utzoo!linus!decvax!tektronix!uw-beaver!laser-lovers

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site uw-beaver
Path: arc1-ca.pugleaf.net!utzoo!linus!decvax!tektronix!uw-beaver!laser-lovers
From: laser-lovers@uw-beaver
Newsgroups: fa.laser-lovers
Subject: Re:  Services and a question
Message-ID: <1648@uw-beaver>
Date: Sun, 13-Oct-85 22:07:44 EDT
Article-I.D.: uw-beave.1648
Posted: Sun Oct 13 22:07:44 1985
Date-Received: Tue, 15-Oct-85 06:22:18 EDT
Sender: yenbut@uw-beaver
Organization: U of Washington Computer Science
Lines: 35