home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!crdgw1!newsun!dseeman
- From: dseeman@novell.com (Daniel Seeman)
- Newsgroups: comp.sys.novell
- Subject: Re: ATCON inconsistent with Chooser problem
- Message-ID: <1993Jan8.225540.137@novell.com>
- Date: 8 Jan 93 22:55:40 GMT
- References: <1993Jan8.152901.90924@vaxc.cc.monash.edu.au>
- Sender: news@novell.com (The Netnews Manager)
- Organization: Novell Inc., San Jose, Califonia
- Lines: 81
- Nntp-Posting-Host: db.sjf.novell.com
-
- In article <1993Jan8.152901.90924@vaxc.cc.monash.edu.au> steved@vaxc.cc.monash.edu.au writes:
- >Greetings Fellow Netweavers,
- >
- >I have a problem with getting my server to see a particular printer.
- >Two printers are in the same zone and both can been seen as LaserWriters
- >by the chooser. One is a genuine Apple LaserWriter the other is a
- >Tektronix Phaser III PXi (color A3).
- >
- >Server running NW3.11 NW4MAC 3.01.
- >
- >Running ATCON I can do an NBP Service Lookup on the zone and see
- >the Mac, the LaserWriter, the Server, but no Phaser.
- >
- >When I LOAD ATPS -V at the console I get the following stuff in the log.
- >(compressed/edited for netnews bandwidth)
- >
- >0.0.0 ATPS: using directory SYS:SYSTEM\ATPS
- >0.0.0 ATPS: initializing existing queue PRINTQ_5
- >0.0.0 ATPS: using font list file SYS:SYSTEM\NW-MAC\FONTS\APPLWNT.FNT
- >0.0.0 ATPS: NBP registering spooler <PrintQ_5:LaserWriter@*>
- >0.0.0 ATPS: initializing existing queue PHASERIII
- >0.0.0 ATPS: getting an initial spooler font list from printer <Phaser III PXi>
- >0.0.0 ATPS: initializing existing queue LASER
- >0.0.0 ATPS: getting an initial spooler font list from printer <LaserWriter II NT>
- >0.0.0 ATPS: attaching printer <Phaser III PXi> to queue PHASERIII
- >0.0.0 ATPS: hiding printer <Phaser III PXi>
- >0.0.0 ATPS: attaching printer <LaserWriter II NT> to queue LASER
- >0.0.0 ATPS: hiding printer <LaserWriter II NT>
- >0.0.0 ATPS: NBP registering spooler <Laser:LaserWriter@*>
- >0.0.0 ATPS: can't find printer <Phaser III PXi:LaserWriter@*>, retrying
- >0.0.0 ATPS: can't find printer <Phaser III PXi:LaserWriter@*>
- >0.0.0 ATPS: failed to hide printer <Phaser III PXi>, retrying
- >
- >After which it continues looping.....
- >
- >0.0.0 ATPS: hiding printer <Phaser III PXi>
- >0.0.0 ATPS: can't find printer <Phaser III PXi:LaserWriter@*>
- >0.0.0 ATPS: failed to hide printer <Phaser III PXi>, retrying
- >
- >Anyone with some ideas as to why chooser can see it but ATCON can't?
- >
- >Stephen.Dart@cc.monash.edu.au
-
- Hi,
-
- Thank you for the detailed problem description. It helps to have complete data.
- It appears that the font list query is not being completed. In fact, getting
- this font list back is basically how ATPS.NLM "knows" it has made the connection
- to the printer in question.
-
- When you used ATCON.NLM were you seeing the Macintosh and the LaserWriter in a
- single listing? From your description, it appears that is the case, but I just
- want to verify that. When doing a "general lookup (using the wild card '=' for
- both the NAME and TYPE parameters)" you should see all the devices in the zone.
- So if there are 10 devices (Macintoshes and Printers) you should see 10 entities
- in the list returned by the "general lookup" test. If you are not seeing ALL
- of the devices during that general test, there may be a physical or datalink
- layer problem.
-
- If only 9 of the 10 devices appear, I would begin to suspect that something is
- amis with that 10th device that won't appear. When looking in the chooser of
- the Macintosh, do you see both the LaserWriter and the Tektronix in the SAME
- listing? If you must use a different driver to see the Tektronix printer, you
- may have found the problem as ATPS.NLM tries to make a connection to the named
- device as TYPE LASERWRITER. I understand Tektronix came out with a (for lack of
- a better description) multi-protocol, multi-page description language printer.
- Is this what you are using? I haven't had any experience with this, but maybe
- we can call Tektronix to get some insight to the problem. Certainly a packet
- trace will help us out here so let me know if you want to persue that avenue.
-
- You may want to respond directly to me concerning this post. We will be able
- to be more specific then and won't have to crowd the net (so to speak). I would
- be happy to post the results when the solution is isolated.
-
- Let me know...
-
- Think Peace...
-
- Dan Seeman
- Novell
- Walnut Creek, Ca.
-