Next message: Dan Schwartz: "RE: [WinMac] AppleTalk elimination (Resent as plain text!)"
Expand this message to fill screen width....
Dear Rita,
The answer is that even Apple themselves hasn't eliminated AppleTalk
on their own campus, despite their "Flag Day" in October 1999.
Why is this? One word: Printing!
More accurately, PostScript® printing. We just had a discussion on
this very issue last week on the AlphaNT Mailing List
http://lyris.sunbelt-software.com/scripts/lyris.pl?enter=alphant&text_mode=0
; and this pops up every few weeks on the Mac-NT Mailing list.
http://lyris.sunbelt-software.com/scripts/lyris.pl?enter=mac-nt&text_mode=0
In a nutshell, not routing AppleTalk packets over a WAN link, usually by
stuffing them inside IP packets, is no longer needed for file services. The
AFP/IP (Apple Filing Protocol over IP) part of AFP 2.2 (Apple Filing
Protocol 2.2) works quite well to greatly reduce the need for AppleTalk.
Network printing, on the other hand, suffers from the very limited LPR
(Line Printing Remote) capabilities. Basically, with an LPR job you "throw
it over the wall" and hope it prints. Between each set of dashes -----
you'll see my parts of the thread on the AlphaNT List. This should be enough
to get you started!
Cheers!
Dan Schwartz
PS: I'm CC'ing this to you so you get my pretty picture of the AppleTalk
stack
-----
Actually, AppleTalk is well behaved because of the AURP portion of
the stack; as used in EtherTalk Phase II for almost a decade. The only
downside is that you have to encapsulate the packets if you want to move
them over an IP WAN link...
But then again, print jobs are generally confined to a given LAN
segment, so routing packets is a non-issue.
-----
Sigh...
Go back to my pretty little picture. You'll see TWO communications
links; and the second link - The parallel cable you just admitted using - is
indeed bidirectional.
The path of a print job through a spooler is:
Workstation (PC, Mac, VMS)
|
|
| -> Communication link 1A forward path (via LPR or
PAP)
| TO Spooler ||
| \/ \/ \/
|
|
|
| /\ /\ /\ /\ /\
| FROM Spooler (\\BoPeep\TAprint) ||
| -> Communications link 1 return path (via PAP, SMB,
(PathWorks?))
| *not* available with LPR
|
|
|
NT/2000 Spooler (or RIP station)
|
| -> Communication link 2 (unidirectiional via LPR
| or bidirectional via PAP or parallel cable)
|
Printer
Therefore, the *printer* is sending job status feedback to the NT
workstation (\\BoPeep\TAprint) and then \\BoPeep\TAprint sends out
administrative alerts to others sending jobs via LPR.
Not being that familiar with PathWorks, it appears that is accepting
LPR jobs and using PathWorks or SMB to send administrative alert messages in
return.
But: LPR itself is not sending these alerts... Because it has no
inherent provision to do so!
-----
BEST VIEWED IN COURIER OR MONACO
He he he... You should be on the Mac-NT list; since we talk about this all
the time cause we REAL printing... None of this pansy-ass monochrome text
printing! :)
Actually, you're not *really* using LPR, since you're (probably) connecting
your printers via parallel cable: Yes, you can easily LPR from a workstation
to a spooler; but if the printer can't communicate back to the NT spooler
that same spooler doesn't know to send an administrative popup!
The path of a print job through a spooler is as such:
Workstation (PC or Mac)
|
| -> Communication link 1 (via LPR or PAP)
|
NT/2000 Spooler (or RIP station)
|
| -> Communication link 2 (unidirectiional via LPR
| or bidirectional via PAP or parallel cable)
|
Printer
Notice you have two communication links: Link 1 can be unidirectional (via
LPR), but in your case it's actually a bidirectional link because you said
"it sends out administrative alerts as needed for paper jams and toner
problems through its local alerter service." In other words, you're using
two different paths to achieve bidirectional communications.
The second communication link is the critical one: If you send a job from
the spooler to the printer via LPR, you *lose* the ability for the printer
to send any "trouble" alerts back to the spooler or elsewhere. LPR (Line
Printer Remote) is *unidirectional* i.e. you throw the job over the fence
and *hope* it works.
On the other hand, if you use a parallel cable between the spooler &
printer, the printer can send feedback to the spooler if there's trouble;
and then the spooler can dispatch alerts as it sees fit. By the same token,
you can use PAP (Printer Access Protocol, part of the AppleTalk stack)
between the printer and spooler and *still* maintain that bidirectionality.
The trick is to use PostScript® printing, which leverages PAP... Or more
importantly, the PAP part of the AppleTalk stack and the PostScript® page
description language leverage off each other.
-----
First off, the only stupid question is the one not asked...
Ahhh, printing! :)
The mistake is trying to use LPR (Line Printer Remote) via IP,
which, in a word, *sucks*
With LPR, you basically throw the job over the fence and *hope* it
prints... No bidirectionality.
You can easily gain bidirectionality by using a parallel printer
cable; but often that's not possible... So back to the Ethernet LAN we go.
You have, in general, 2 links with a spooler: The link from the
workstation (any platform) to the spooler; and the link from the spooler to
the network-connected printer.
AppleTalk to the rescue! Since you have an ethernet - equipped
PostScript® printer, you have AppleTalk built in. More specifically, you
have AppleTalk's PAP - Printer Access Protocol - built in.
[AppleTalk stack picture removed]
What you want to do is install Services For Macintosh - It's even in
NT4/TSE - then go into your Services Control Panel, disable File Server for
Macintosh, stop Print Spooler for Macintosh, reapply your Service Pack, and
then reboot.
Next, "Add New Printer" and "Add New Port." On that property sheet,
select "AppleTalk Port" then OK. Then, you'll see the printer when the
AppleTalk network is browsed. Select it and run a test print. Now share the
printer and you're off to the races!
-----
>-----Original Message-----
>From: Tippe, Rita (EDM_EXCHANGE) [mailto:RTippe@thejournal.southam.ca]
>Subject: [WinMac] AppleTalk elimination
>
>
>Hello everyone,
>
>If someone has a business case that they don't mind sharing in regards to
>eliminating AppleTalk on your network, I would really appreciate it if you
>wouldn't mind sharing it with me.
>
>Thank you,
>Rita
This archive was generated by hypermail 2b29
: Thu Feb 08 2001 - 08:28:23 PST