With respect to the channel information for a Novell print server, if
I correctly understand Dave K, the suggesting is that each queue
becomes a seperate channel. This is very cumbersome. DPI products, as
do the HP and many other, can service multiple queues on multiple file
servers (non NDS) and multiple NDS queues.
Some background infromation:
1. since both file servers and print servers are involved, the use of
the key-word server is ambiguous (although the description evidentally
applies to file server)
2. printserver applications can be on a file server, in a workstation,
in a box printserver product, or in an printer NIC.
3. the print server itself does have a name which is (I believe)
unique on a given network.
4. the active file servers and queues serviced can (and do) change.
The idea of the channels comming and going, while it can be handeled,
makes for an interesting table.
5. queues can be serviced by multiple printservers. Just because you
know a queue that a given print server (or queue server) services does
not mean that you can reliably send a job to that printer.
6. It is unclear what purpose all this information about queue and
file server will provide.
I suggest that including the name of the printserver, as it is
advertized in the established SAP address for print server, would
provide sufficient information to identify the device, although, for
NDS mode operation, tree may also be useful.
> <bunch of values deleted>
> chNetwarePServer(10), -- Novell, Inc.
> -- prtChannelInformation keywords:
> -- Server Name
> -- Keyword: "Server"
> -- Syntax: Name
> -- Status: Mandatory
> -- Multiplicity Single
> -- Description: The name of the server on which
> -- the queue resides.
> --
> -- Queue
> --
> -- Name: "Queue"
> -- Syntax: Name
> -- Status: Mandatory
> -- Multiplicity Single
> -- Description: The name of the queue on the
> -- server
> --
> -- NDS Tree
> --
> -- Keyword: "NDSTree"
> -- Syntax: Name
> -- Status: Mandatory
> -- Multiplicity Multiple
> -- Description: The NDS Tree SAP name
> --
> -- NDS Queue
> --
> -- Keyword: "NDSQueue"
> -- Syntax: Name
> -- Status: Mandatory
> -- Multiplicity Single
> -- Description: The name of the queue object in
> -- the associated NDS Tree
> -- There must be exactly one Server and one Queue
> -- entry or exactly one NDSTree and one NDSQueue
> -- Entry.
> <bunch of values deleted>
>> The description says "There must be exactly one Server and one Queue entry
> or exactly one NDSTree and one NDSQueue Entry." However, the HP JetDirect
> card for our printers can serve up to 16 server/queue pairs over one
> channel, so we need to allow multiple entries. Also, we can support NDS and
> the other type in various combinations.
>> The questions are:
>> 1) Why is there a limit of one or the other? I think multiple and mixed
> Server/Queue and NDSTree/NDSQueue pairings should be allowed.
>> 2) Why does NDSTree specify "Multiplicity Multiple" but the rest of the
> keywords are "Multiplicity Single"?
>> Unless I'm missing something, I suggest the last sentence for
> chNetwarePServer(10) be changed to: "Keyword entries must be paired (Server
> followed by Queue or NDSTree followed by NDSQueue) and may be repeated."
If I understand the situation correctly (I'm no NDS expert, so bear
with me, but I was in the middle of defining the prtChannelInformation
entry), the way the prtChannelTable is organized, your example would
break out into multiple prtChannelEntry objects. Each of these would
have its own prtChannelInformation value, and they might potentially
differ in other prtChannelEntry fields.
:: David Kellerman Northlake Software 503-228-3383
::david_kellerman at nls.com Portland, Oregon fax 503-228-5662