topic Re: Printer problem in Operating System - OpenVMS

Printer problem

Willem Grooters — Thu, 02 Dec 2004 15:14:24 GMT

My client has a number of PC's with (HP) printers attached in his network. These PC's arer used as printer server.
On a VMS cluster on one location, printer queues have been defined to access these printers from VMS.
On another (remote) and newer cluster, the same thing. All required files have been copied from the first cluster to the other, but renamed. The queue definitions reflect this namechange.

On both clusters is VMS 7.3-2, same TCPIP version (not sure which one), and, AFAIK, all relevant patches have been applied.

On the first cluster, printing from the VMS machine is correctly executed. Ifvthe same file is printed from the other cluster, lines are concatenated as if line ends (CR/LF) are not sent or recognized.
The funny thing though is that this excercise has been done with another cluster, and theer is no problem at all.

We've been thinking on forms not defined or not loaded but that seems all ok.

What are other alternatives?

Willem

Re: Printer problem

Craig A Berry — Thu, 02 Dec 2004 20:32:28 GMT

These are LPD queues? You've probably done all this, but compare the results of these on the one that's working and the one that's not:

$ TCPIP SHOW SERVICE LPD/FULL
$ SHOW LOGICAL TCPIP$LPD*

and look at the configuration file (I think it's called TCPIP$LPD.CONF or something like that).

Re: Printer problem

Willem Grooters — Fri, 03 Dec 2004 02:30:10 GMT

No LPD queues.

The attachment shows one of the queues that show this behaviour, both old and new cluster.
10.21.8.154 is one of the PC's.

Re: Printer problem

Martin Vorlaender — Fri, 03 Dec 2004 02:44:05 GMT

Okay, so these are Telnet queues. Do logicals TCPIP$TELNETSYM* show different values?

cu,
Martin

Re: Printer problem

David B Sneddon — Fri, 03 Dec 2004 02:49:47 GMT

Willem,

The obvious difference is the use of the
/SEPARATE=(RESET=(KYO_RESET)) and the use of
/NO_INITIAL_FF and DEFAULT=(FEED,FORM=)
Try setting them up EXACTLY alike and check
for any differences in the *TELNETSYM* logicals.

Regards
Dave

Re: Printer problem

Willem Grooters — Fri, 03 Dec 2004 03:55:23 GMT

$ SHO LOG TCPIP$TELNETSYM* - see attachment

One I could now think of is TCPIP$TELNETSYM_RAW_TCP, but the point is that another site has no problems, and so we cannot change this on the fly.

Willem

Re: Printer problem

Wim Van den Wyngaert — Fri, 03 Dec 2004 03:59:31 GMT

Willem,

What is /PROCESSOR=TCPIP$TELNETSYM1 (1 ???)

Wim

Re: Printer problem

Richard Hafke — Fri, 03 Dec 2004 04:23:38 GMT

Hallo Wilhelm,

Ithink your printing happens on different Printers?? If so, are the printers configured identically for TCP/IP-Printing.
With our Kyocera-Printers we had the same affects, when they are not configured correctly.

Richard

Re: Printer problem

Willem Grooters — Fri, 03 Dec 2004 04:35:40 GMT

Thnaks Wim,
this is something to overlooked completely! What it is, I don't know, probably an old TELNETSYM version?

Client has been informed - He will start eliminating all differences.

Willem

Re: Printer problem

Art Wiens — Fri, 03 Dec 2004 12:46:41 GMT

How about that you have renamed your form BBN_DEFAULT and your library BBN_PRINTLIB1 ... are these both identical defined on both clusters? The forms call the same setup modules which exist in both text libraries and are the same?

Art

Re: Printer problem

Jan van den Ende — Fri, 03 Dec 2004 15:42:40 GMT

Willem,

How about a different approach?
AFAIK, ZUAxxx and ZUBxxx should follow ISC standards, which specify (last time I saw) NETWORK printers!
Put in a JD card, and they are where they want to be, eliminating all Billyware complications, at probably less than an hour of your bill!

('k wis-nie dajje ook in Zuid zat)

Proost.

Have one on me.

jpe

Re: Printer problem

Willem Grooters — Mon, 06 Dec 2004 08:48:31 GMT

Art,
This I already suggested. That is: comparing them. But I've been assured that this is correct. (I cannot check this - I have no access to the system and my collegue over there has asked my support. I agree that this is a complicating factor. But they'll have to, one day -:D)
Jan,
well, whether it's a JD or a PC...They have a bunch of JD's and AXA's floating around - in storage! My collegue came to the same conclusion. On the other hand, I don't think it will solve the problem. It's likeliy to be something else on a higher level..
(ISC-Zuid - Ja en Nee. Ze vragen weleens wat als ze er zlf niet uitkomen ;-) Zoals nu)

Willem

Re: Printer problem

Anton van Ruitenbeek — Thu, 09 Dec 2004 08:38:26 GMT

Willem,

I left the system with also the logical:
TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS = 35

I don't see this one anymore.
We are using this logical and the other logicals do see the same.
Whe are using AXISS boxes, external and internal JD en OCE printers and everything is working fine.
IP 5.4 eco 2

I think that was also the version when I left it.

AvR

Re: Printer problem

Willem Grooters — Mon, 29 Aug 2005 06:44:17 GMT

They have removed all PC as printer servers, and installed AXAs and JetDirect boxes where applicable. PC's now print over the network. It seems this solved their problems.