PMP Mail Archive: PMP> New IETF Draft review

PMP Mail Archive: PMP> New IETF Draft review

PMP> New IETF Draft review

Bill Wagner (
Fri, 4 Apr 1997 03:03:01 -0500

I had previously suggested that requiring separate channel listings
for every bindery-based NetWare queue was cumbersome and of little
use. I have seen no refutation of this.

I wish to repeat this contention, this time stressing the difficulties
versus the benefits.

The chNetwarePServer(10), prtChannelInformation keywords currently
include file server and queue. Bindery based print servers can service
multiple queues on multiple fileservers. The suggestion is that a
separate channel listing should be provided for every queue on every
file server.

1.This might amount to 16 or more channel listings.
2.These queues are, in general, not identified in the print server but
rather are on one or more file servers. They must be determined at
power up time and might change while the unit is powered.
3.The information on queues serviced, in general, is retained in the
4.A given queue may be serviced by more than one print server. That
is, knowing the queue does not mean that you know how to print to the
5. Bindery based queues are 'old' Novell technology, being replaced by
NDS queues.
6. The Keywords for Rprinter are the name of the printserver and the
printer. I suggest that the name of the print server and the printer
are also adequate channel information for Pserver channels operating
from bindery based queues.

A printserver will normally service just one NDS queue, so NDS queue
is a justifiable keyword; therefore I do not object to the keywords
NDSTree and NDSQueue for pservers in an NDS environment. However, I
wonder if perhaps Pservers servicing bindery queues and those
servicing NDS queues should be considered different channel types.

Bill Wagner, DPI