We are using NPDS so we don't have a printer queue name, yet you require one according to the report caster documentation (P. 3-27)(this is release 7.1.3). How can I get around this so I can print reports directly to a printer through report caster?

Hi Jay,
I have to check the doc BUT I thought you could use the ip address of the printer as well?
Rich

Hi,

On the same page (P. 3-27), the doc says:

"ReportCaster can differentiate between the printer queue and the printer host name/IP address due to the presence of the '@' separator. Information Builders recommends specifying both the printer queue and host name/IP address when distributing ReportCaster output to a printer. However, ReportCaster supports specifying only the host name or IP address of the printer. The maximum length of this field is 95 characters."

Hope this helps.

Regards,
Jenn

Rich (and DocServices) is correct. You can simply specify the IP address or printer name. We do this now in Report Caster. However, with some of the newer printers, you can set up queues that provide specific functionality, like faxing, printing PDF docs, etc. so I thought it was rather useful that you can now specify Queuename@printeraddress to avail yourself of some of this (relatively) new functionality. But it isn't required.

When I use the tcp/ip address I get the following message: unable to distribute to 172.21.111.45;Connection timed out: connect

is there a way I can use a trace to figure out where i'm timing out.

Hi Jay,
First make sure you can ping the ip address from the machine where the distribution server is running.
IF that's ok then you may need to turn on the traces to see whats happening under the covers.
Rich

Rich - what traces do I turn on and where do I turn them on. If you can - can you please provide examples - thank you for your help

If I'm not mistaken, ReportCaster uses the LPR/LPD protocol to communicate to the printer over TCP/IP. You might want to check with your site tech support to ensure that the NDPS printer is supporting connections via LPR. The behavior of "connection timeout" on a ping-able print device indicates that the device is not listening on the specific port the service is trying to connect to (LPR: port 515). Since NDPS supports native Windows protocols, in addition to others (IPP and LPR), your print device may configured on (for LPR) by default.


Dan Kenny
University of Nebraska at Omaha
Prod: WF 7.1.6 BID/MRE/DataMigrator Test: WF 7.6.1 BID/MRE/DataMigrator

Is there a way I can trace where the timeout is coming from ?

In a nutshell, no, not without some network help.

Connection timeout means you're not get a response from the printer. This can be blocked (filtered) at the distribution server firewall rules, the switches/router rules, the NDPS rules or the print device itself. It can also be the result signature of the print device not "listening" on the TCP/IP port to begin with.

Standard network tracing/troubleshooting is to first PING the IP to see that the device is routable and alive. That means go to the OS of the distribution server and type "ping 172.21.111.45". If it answers, then a large network layer of problems is removed and you can try connecting to the LPR/LPD port by typing "telnet 172.21.111.45 515". If it opens up the connection, then your problem is most probably in the print queue definition on the distribution server. (If this is all totally greek to you, then you really need to escalate the problem to your TCP/IP/NDPS network support staff.)

Hope that helps,

Dan Kenny
University of Nebraska at Omaha
Prod: WF 7.1.6 Linux BID/MRE/DataMigrator Test: WF 7.6.1 Linux BID/MRE/DataMigrator

When I telnet - I get prompted for a userid and password - if their a default user and id that I can use?

Jay,

Sorry, this one's beyond my expertise/ability to help. When you posted that you use NDPS, that implies that you are using "Novell Distributed Print Services", and that adds another layer to debug in your problem.

I really think you can't do it alone, i.e. you need the assistance of your network support personnel, at least those responsible for configuring print devices under NDPS. The behavior of "telnet IP 515" prompting for a username and password is not normal for the LPD/LPR protocol, it should just open up a connection and leave you hanging, because it expects LPR handshaking. Since NDPS is in the mix, I have no clues as to what's up.

Regards,

Dan Kenny
University of Nebraska at Omaha
7.1.6 Linux