SUMMARY: printers on ethernet

From: David Meleedy (dmm@worf.harvard.edu)
Date: Sat Oct 03 1992 - 05:39:07 CDT


The orginal question was:

        We are thinking of switching over all of our printers,
currently hooked up to Sun computers serially, over to ethernet. i.e.
we are thinking of upgrading all of our Apple IINTX's to Apple IIG's,
which have built in ethernet cards for faster downloading of PostScript
files.

        What I am wondering is if anyone has any good solutions for
keeping track of the queue when you have printers hooked up directly to
ethernet. In the past, the serial host computer would generate a queue
that users could look at to see if their print jobs had finished
printing or not. How can this be achieved with the new printers?

Various answers were given by:

ray@isor.vuw.ac.nz
poul@nilu.no
alastair@eucad.co.uk
davisson@ida.org
miker@sbcoc.com
brent@crick.ssctr.bcm.tmc.edu
whalen@cs.nps.navy.mil
ckd@eff.org
cyerkes@jpmorgan.com
per@erix.ericsson.se

The answer was the Apple LWIIg printers cannot be put directly onto
the ethernet, they speak "ethertalk". Yet another joy that Apple has
provided to us. Basically you have to use a computer as a host, and
then run CAP (Columbia Appletalk Protocol) to have the host speak
ethertalk to the printer. Some other people mentioned that HP products
come with software support such as what I originally envisioned.

Following is the raw data, for those who are curious:

From: ray@isor.vuw.ac.nz

A couple of comments about LaserWriter IIg's.

1) There still needs to be a queue on some machine somewhere, the printer
will not do the job queueing itself.

2) (More important) the IIg is an ethernet printer, but does not talk TCP/IP.
   It uses Ethertalk, which for your purposes will require you to have
   some box somewhere to do the conversion from TCP/IP to Ethertalk. We
   have a LW IIg on our ethernet, but there is also a multigate box and
   a CISCO router, one of these does the conversion (I am not sure which
   one). We use the CAP software to send to the printer.

I can get more information on how our setup works if you need it.

Hope this helps
Ray Brownrigg ray@isor.vuw.ac.nz

From: poul@nilu.no

foreach printer you choose a master spooler for that printer. all machines
print via that machine (using :rm=...:rp=...: in /etc/printcap)
makes it easier to administrate filters, queues, fairness (*), ...
makes the spooler machine (and the network) more over(?)loaded

(*) fairness: First come First served, instead of the following scenario:

user aa on machine aas, user bb on machine bbs.
aa prints 10 files (10 requests) - they are all queued on aas

as few seconds/minuttes later bb prints one file (1 request)
- queued on bbs. when the printer is done with what its is currently doing,
it waits for next request to come - that one could as easyly come from bbs machine
as form aas machine - very unfair for aa (but I think that bb is pleased)

If you did not get the point: try this

aas queue: aa10 aa9 aa8 aa7 aa6 aa5 aa4 aa3 aa2 --->
                                                        printer print aa1
bbs queue: bb1 --->

Q:what is the next request the printer gets?
[A: either aa2 or bb1 or cc? or ...]

Q:where would you chose to put your own print job if you were in a hurry?
[A: on aas because you are a person of justice :-) ???]
[A: on ccs because the queue on ccs is empty, and that makes it 33% sure that your
request will be the next one???]

                                 hilsen/regards

                                     Poul.

From: alastair@eucad.co.uk

In that the actual queues are all on different machines I do not see a way
of doing this directly, and faster machines will usually get the jump on
slower ones in printer access which isn't fair. Wht you could do is
configure all yuor printcaps to regard the printer as a remote queue on a
print server system. This will ensure there is one final queue on Sun for
each printer, and the content can be observed and controlled through
thenormal sun commands. The disadvantage is that you are reliant on the
print server being functional. This still will not tell you what the Apples
are up to unless they too route via the sun.

Al

From: davisson@ida.org (Chuck Davisson)

I'm not trying to rain on your parade, but the Apple IIG's do not
support TCP/IP, they speak EtherTalk and AppleTalk. What were you going
to use to drive the IIGs? We've had to use Cayman GatorBoxes with
GatorPrint software. The sun still manages the queues for us. Here's a
sample of our printcap file to give you an idea of how this looks:

# Gator Print to cs-IIg
cs-IIg:\
        :lp=:rm=cs-gb4-u1:\
        :sd=/usr/spool/lpd/cs-gb4-u1/cs-IIg:\
        :lf=/usr/adm/cs-IIg-errs:\
        :rp=cs-IIg:

Our GatorBox is called cs-gb4-u1.

Hope this helps,

Chuck Davisson
Institute for Defense Analyses
davisson@ida.org

From: Mike Raffety <miker@sbcoc.com>
Can't say for Apple IIG's, but every other Ethernet printer I've seen
is still controlled by a single host, running some special software to
send the print jobs (over the Ethernet) to the printer. All other
hosts talk to this designated host.

Not the most efficient thing in the world (print jobs pass over the
Ethernet twice), but it avoids the problem you're talking about, and
also the printer doesn't have to emulate a BSD (or Sys V) spooling
system, know about IP routing, etc.

From: Brent Alan Wiese <brent@crick.ssctr.bcm.tmc.edu>

     Although the printers will be directly connected to the ethernet, they
do not speak "lpd" and you will still need a host that converts the lpd
requests to something the IIg understands. You should be able to just
keep track of the system you have designated as the "convertor". If you are
managing all the unix systems that print to the printer then this is fine,
but Mac's will be able to print directly to the printer and this will not
be logged on the unix system.

From: whalen@cs.nps.navy.mil (susan whalen)

We have an HP laser jet III on our ethernet. We still have 1 printer server
and the rest of the systems are considered clients - therefore only the
printer server queue is checked.
This ability comes with the HP ethernet software. I cannot vouch for any other.

From: Christopher Davis <ckd@eff.org>

The IIg doesn't do lpd, so you'll still have a queue, you'll just be
using something like the CAP papif to send jobs to the printer, and
instead of a serial host you'll have a "CAP host".

Note that the IIg doesn't have Zapf Dingbats in ROM, and it comes on a
Mac floppy, so you'll need a Mac to download it with... :(

From: cyerkes@jpmorgan.com (Chuck Yerkes)

1) It's ridiculously expensive to change working printers attached
   to a serial/parallel port to ethernet ports if you don't need to.

2) We had some need (a bunch are still on a serial or parallel port on
   Suns). We used HPIIIsi's and Milan Ethernet parallel ports. (NetPrint
   also makes some with multiple serial and parallel ports - multiple
   printers/adapter = much cheaper). These adapters are as fast as the
   built in's of Apple/HP ethernet printers. We have one machine hold
   the queue and print. That way, we can find backed up jobs and
   stop/redirect the queue if need be. It is called by an NIS alias
   (host to print to is HP3SIserver for example). If there is a machine
   problem, we can change the NIS hostname to a backup queue host.
   
3) I have found that Apple is usually more than willing to charge
    extra money for their name on the printer. We use QMS printers
    and find them Cheaper/performance and support for Suns. Apple
    has problems acknowledging operating systems other than Mac OS
    and ProDOS.

From: per@erix.ericsson.se (Per Hedeland)

First of all, I suppose you realize that you need special software for
this - those printers don't talk lpd/TCP/IP or anything nice like that,
only Apple's "EtherTalk phase 2". I'm using the freely available CAP
package, works great, but I believe there are also commercial
alternatives.

This also means that if you have multiple networks, whatever you're
using to route between them may not be able to, and most likely in the
default setup won't, route traffic between the Suns and the printers.

I suppose it would be possible to install and run this software on all
your Suns (although I've never heard of anyone doing this), and having
them fight directly over the printer like Macs do - but in a civilized
Unix world, I'd say it's much better (and the solution that I and
probably just about everybody else use) to still have only one of the
Suns talking to the/each printer - it will then be able to manage the
"total" queue just as before, and the other Suns won't know the
difference from a "conventional" setup.

From: Ray Brownrigg <Ray.Brownrigg@isor.vuw.ac.nz>

Well I have asked more about what should work, and it turns out that
our situation is (perhaps unnecessarily) complicated, as we have many
Sun subnetworks and many Mac (Localtalk and Ethertalk) devices
connected.

Our setup is as follows:

SunOS - CAP6.0 (Ethertalk) - 10BaseT hub - ethernet - CISCO - Multigate
(Phase II Ethertalk) - ethernet - 10BaseT hub - LW IIg

When I asked our local guru what parts of that were necessary for your
situation, he replied:

> The simple asnwer is, CAP with EtherTalk enabled on the SUN is all you
> need to worry about.
>
And when I asked him to confirm that a Sun - ethernet - LWIIg connection
would work, he replied:

> Yes, that config should work. Sun w/ CAP + EtherTalk. Speaks EtherTalk
> to IIg. No problem. You just need to get the config right on the Sun.
>
Hope this helps.
Ray Brownrigg ray@isor.vuw.ac.nz

========
David Meleedy Smithsonian Astrophysical Observatory
meleedy@cfa.harvard.edu 60 Garden Street, MS 70
Phone: 617 495 7252 Cambridge, MA 02138 USA



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:50 CDT