Print non-stream files to PC using LPD

[Aaron Sakovich]

I'm testing out the capability to be able to print from OpenVMS to a user's locally connected printer on their PC over a wide area network and through multiple firewalls and VPNs. In order to accomplish this, I've created an outbound LPD queue on the VMS systems that points to the user's PC which has got the Windows TCP/IP Printing Services loaded on it.

The printers in this case are PCL and PostScript compatible HP LaserJet 3050s. The OpenVMS system is running 7.3-2 and TCP/IP services version 5.4 ECO 6.

When I print a stream file, everything looks okay. When I print files with other record formats (specifically, I've tested stream lf and variable length) the output looks like it's just getting a line feed and no carriage return.

I've tried setting the default print processor type on Windows to be text, but that didn't help any.

Has anyone seen anything like this? Do you have any suggestions?

[Joseph Huber_1]

The only possibility me thinks is first to convert the file to STM.
This can be automated by putting a queue in front of the LPD queue, which does the converion and the queues the resulting (temporary) file to the destination LPD queue.
One possibility is to use the EXECSYMB symbiont (on the freeware). It would run a simple script to do the conversion, then queues the resulting file. An example for setting up an execsymb script is my CNV_ANSI_PS.COM in
http://wwwvms.mppmu.mpg.de/vms$common/execsymb/

[Aaron Sakovich]

I'm already using that symbiont for several other tasks, but that would be an awfully ugly solution.

I'm wondering if prefacing the LPD queue with a telnet symbiont queue might help. I've researched all the LPD logicals and configuration files, but not found anything that would help in this circumstance. I may have to start searching through the telnet symbiont settings next.

[Hoff]

I don't know any way out of this, short of a file conversion operation.

("Awfully ugly" certainly describes a host-based LPR/LPD connection routed through several firewalls and various VPNs and into an attached printer. The ugliest part is the "attached printer" part.)

Whatever software that is printing the files needs to convert the files from something -- vfc, var -- that isn't recognized on Windows into something that is. Either within a symbiont, or prior to the PRINT command, or...

Alternatively, replace these printers with printers that support networking. Host-based printing is usually more effort than it is worth; a network-attached printer is far easier to manage on all platforms. With a network-attached Postscript printer, you can use DCPS to sling the data directly. Well, directly via the firewalls and VPNs.

[Phil.Howell · Accepted solution]

You may be able to use telnetsym with lpd
Have a look at the section on "relay queues" in this link
http://ftp.openvms.compaq.com/doc/83final/6526/6526pro_055.html
Phil

[Walter Miller_1]

Many printers that support LPD printing will have an option to treat LF as LF + CR. Most of the time it will be on the PCL setup page.

[Aaron Sakovich]

That would be an excellent point, but for the fact that I'm relying on the LPD service in Windows. *sigh*

I did double check the printer's settings to see if there was any way to do that, but to no avail.

Still scratching my head...

[Aaron Sakovich]

Hoff said:

"Well, directly via the firewalls and VPNs."

The problem is, the VPN is hosted on the PC. So regardless of whether the printer is attached to the PC or to the network, it *still* has to go through the PC. So, no matter how demeaning it may be to have to use a PC in this equation, I'm stuck with it, just like I'm stuck with the brand new multifunction HP printers that were bought for these users.

So, given that I can't use reverse telnet (no such client on the PC nor printer), I have to use LPD.

I'm heading home in a few minutes to run some tests on a relay queue, but I have doubts it will -- nay, I'm certain it won't -- re-parse the LF's. Any other ideas?

[Hoff]

Do whatever you can to make the Microsoft Windows box go away here; print directly to the target device, or print via a JetDirect. Getting the host systems out of the printing business -- and whatever the host OS might be -- really makes things easier to configure, and easier to manage.

I just don't purchase printers without NICs any more. The few dollars saved are definitely not worth the costs that are incurred downstream. Going a little more expensive on a printer up front can provide substantial savings on configuration and operation, and -- often -- on the costs of the consumables. And you don't have to deal with getting a host-based printer to work -- every system prints directly.

As for your root question, you're going to have to alter the format of the file before shipping it over the network. Whether this is via TCP/IP Services lpr or via some local or customized lpr or via a local symbiont that then pipes the output over to lpr (or lpd), or via a file format conversion beforehand (manually, as part of the PRINT, etc), you're going to have to sort out a way to do it. Not fun, I know.

It might be worth tossing a request at HP to consider implementing file-level conversion operations in lpr. Other parts of TCP/IP Services -- the NFS ADF stuff, for instance -- already have to deal with this sort of conversion.

[Aaron Sakovich]

Well, mark this day in your calendars folks: I was wrong. ;-)

Creating the relay queue did the trick. Now all my text file printouts come out properly wrapped regardless of the file record format.

Thanks for reminding me about relay queues, Phil!