Next message: Perbix Michael: "RE: [WinMac] AppleTalk elimination"
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
-----
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 thr
ough 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
*** Windows-MacintoshOS Cooperation List ***
FAQ: http://www.darryl.com/winmacfaq/
Archive: http://www.darryl.com/winmac/
To unsubscribe, send mail to winmac-unsubscribe@iffy.com
This archive was generated by hypermail 2b29
: Thu Feb 08 2001 - 08:49:29 PST