Printer 'blocked'

[Jon Pinkley]

RE:"Why Telnet over LPD ?"

Thomas, if what you meant by that is "Why do you prefer to use queues with /PROCESSOR=TCPIP$TELNETSYM instead of /PROCESSOR=TCPIP$LPD_SMB, I can think of several reasons. The primary reason is that LPR/LPD queues don't behave the same as normal VMS print queues. If you use print/form= it has a totally different meaning. Also things like flag pages are different. It is a UNIX implementation hung on the side of VMS. If you are just printing source code listings, then they are ok, but if you have preprinted stock, getting LPR/LPD to work like a LATSYM queue is a pain. (Yes, there are relay queues, but even if you can get them to work, you have to have two queues. Here's one thread concerning LPR queues on VMS. Ian's first response in that thread was spot on in my opinion.

https://community.hpe.com/t5/operating-system-openvms/bd-p/itrc-293#.X36hD0czY2x

So, if it is possible to get telnetsysm to work, that is what we use.

I don't see how firewall configuration for LPR/LPD vs. raw tcp on some other port like 9100 would be any more or less difficult. In general we never allow access to our printers from the Internet except via VPN, so it isn't an issue for us.

Jon

[Wim Van den Wyngaert]

BTW : I prefer the telnets over lpd.

In DCPS doc you find several notes on printers reacting badly. May be also applicable to telnetsym.

Look for "starting" in
https://support.hpe.com/hpesc/public/km/search#q=DCPS%20&t=Documents&sort=relevancy&layout=table&numberOfResults=25&f:@kmdoclanguagecode=[cv1871440]&hpe=1

Wim

[Jon Pinkley]

RE:"Would it matter whether these (network) printers are accessed directly, or as a shared printer on a Windows server?"

Willem, I am assuming you are asking about sharing the printer between VMS and windows users, and are asking if the windows PCs are directly accessing the printer, or if they are spooling through a windows server. Different printers handle multi-threading differently. In general, sharing among non-coordinated clients can be problematic, especially for things like resetting the printer. I would guess there would be fewer problems if all the windows jobs came from a single server, but I guess it depends on how the server's print driver deals with the printer vs. how PC print drivers do.

I have never attempted to access a printer from VMS via a Windows server, if that is what you were suggesting.

Jon

[Hoff]

Host-based (served) printers are not worth any cost savings that might be accrued, IMNSHO supporting these things.

Network-based printers are much more manageable, more maintainable, and generally much easier to deal with, and more reliable.

The telnet and lpd paths are largely interchangeable; I find myself choosing and using one over the other basically only when a daemon or client bug is encountered.

I've seen queues get stuck like this when the Windows UI for selecting printers confuses somebody. If you use a stale Windows driver or if you mis-connect the printer, it is easily possible for the Windows box to either skewer the printer, or to allocate the printer to itself. And IIRC, the path that you might think it is to get to the printer using Windows 2000 and Windows XP -- network -- is the wrong path.

On the OpenVMS host side, ensure that your ECOs for OpenVMS and for the queue manager and for whichever IP stack is involved are all current. (The INVSMBMSG implies there's a (usually minor) bug in the symbiont, but whether that is the proximate cause or a symptom here...)

[Anton van Ruitenbeek]

Sorry Willem that I didn't react earlier on your answer of my quenstion ;(

But as I can recall there were in the begin of IP printing (around 1990) a lot of problems because of the implementation of 9100 on some printers.
This had to do with the printers were accepting IPX/SPX, AppleTalk, IP and some also LAT and most also 'that MicroSoft other printer protocol'. It was MS propriaty. Because all these differences sometimes the printerprocessor didn't get the 'end of job' message. So the printer wasn't released from the remote server. You get the same behavior when your printer was connected via LAT on a DECServer and didn't set the protocol to LAT. If you started to print, the connection was made, but never released.

But to make a very long story short (because I can add still a lot of reasons more), maybe a option is to shutdown (remove) all the protocols which aren't used. This to release the printer overhead.
Make sure the timeout on the printer for IP is (lets say) 90 sec.
Also check on the printer the printer 'remote' name and socketnumber. Name is mostly RAW and socket is normaly 9100. But this will be correct otherwise you wouldn't get the first printout.
If you got the option, try to let all the other platforms use the same printprotocol (TELNETSYM), althou I don't think the YouNix guys will follow. But for the MS-Windows it's no problem (sometimes even faster).

AvR

[Willem Grooters]

The problem occurs too random to reproduce it at will on a specific printer; there are too many variable factors (number of prints, from a number of different systems, network issues).
We now run a batch job at regular intervals that checks queues and top job on status and resets the queue when needed. Not what we want but it seems to bypass most problems.

There is another issue with LPD queues, but that's another story.