Inbound IP Printing on VMS? (Reverse Telnet?)

[Dima Bessonov]

I need to receive print jobs via TCP/IP from several diverse remote systems (VMS, UNIX, Windows, SNA mainframe with IP software) and print them on a local DCPS printer. I.e. I DO NOT WANT the remote hosts to print directly into the printer's NIC. Under any circumstances. I want my VMS node to act as a server for remote print jobs that queues them into a local queue. What are my choices?

My first thought is LPD server which is a standard part of HP TCP/IP Services for OpenVMS. Its counterpart, LPR client, is available on any of the above mentioned remote platforms - VMS, UNIX, Windows, mainframe. Still, LPR is unidirectional, i.e. no aknowledgement and no error recovery. I'd prefer a more reliable method, if possible.

My second thought was reverse telnet (aka raw TCP/IP) printing. It is bidirectional and again, the client is available for about any platform. But: can I make a VMS host act as a SERVER for inbound reverse telnet printing? (I never heard of that but I may be wrong.)

Possibly anything else?

[David Jones_21]

My recollection is that LPD does return 1 byte of status. In general, all you can really know at the time you finish submitting a print request is whether or not the data was received and queued for printing. If you find LPD insufficient, it's because the scope of what you want is larger than simply "I need to receive print jobs". Internet Printing Protocol (IPP) is a much more complete printing system, but I don't know of any VMS implementation.

You can write a daemon that pretends to be a network printer's raw (port 9100) interface, but fully mimicing a real printer's bidirectional responses would be problematic.

[Antoniov.]

I'm with David, LPD/LPR is the best and simplest solution you can choice.
I saw a new feature in Advanced Server V7.3 about queue printer server; you can create a NT queue printer on VMS. But I didn't try it and you must buy A/S V7.3.

It's not clear for me why you don't want users send their jobs directly to printer.

Antonio
http://it.openvms.org

[Dima Bessonov]

Antonio,

Why I don't want direct printing from remote systems? Imagine you see a printer in your office which prints an unknown job for half an hour. No one knows, who's printing the job. You look at your local VMS and/or Windows queues - nothing there. You've no idea who's printing it and what's that. Isn't that nice? Imagine an even worse situation: bad PostScript generator on a remote system sent a print job that made your printer freeze. You restart the printer but it's immediately hung again. You don't have any control over the remote system that stubbornly sends this job again and again. Do you like this scenario?

[Antoniov.]

Hi Dima,

how can OpenVMS solve this scenario?
I imagine you could stop bad job printing from OpenVMS but you should do this every time this happens because OpenVMS cannot understand if job is good for print.

I think you want to create some kind of printer firewall but I'm in dubt you can do this with standard VMS commands.

Look at printer menu. Newest printers have some control tools to help you.

Antonio
http://it.openvms.org

[David Jones_21]

I can't fault Dima's argument for printers being driven by a single, manageable, accountable print queue. My site uses a Samba server on VMS to let PC clients print to our printers via their VMS printer queues. I'm not sure if Unix can print as a Samba client, it's not an issue for us. Since the policy is known, we don't have any problems with users trying to discover the printers on their own for direct connection.

[Dima Bessonov]

I agree with David about PC clients, myself running Advanced Server V7.3A . Still, there are systems that just can't participate in MS's domains and therefore, can't use the Advanced Server's printers (or Samba printers, for that matter). Think of mainframes, UNIXes & VMS systems without Pathworks or Samba. So... This all leaves us with LPD/LPR as the only choice, probably?

[Bojan Nemec]

Dima,

Here is a little DCL procedure which I wrote for a test. The procedure acts as a TCP/IP service:
$ define print_dir
$ set noon
$ filename = f$unique ()
$ open/read/write net sys$net
$ convert/fdl=sys$input/stat net print_dir:'filename'
record
format undefined
$ !
$ ! there you will get the error:
$ !%CONV-F-READERR, error reading XX:.;
$ !-RMS-F-RER, file read error
$ !-SYSTEM-F-LINKDISCON, network partner disconnected logical link
$ ! This is because the remote system will close communication and
$ ! convert does not hand...

[Dima Bessonov]

Bojan, I appreciate your work but... Let me put it this way: I've got LPD up & running on my VMScluster. It's quite OK for occasional printing. The point is, my company has several systems in other branches, over like 2,000 Km. They're managed by their local IT folks. My users do telnet sessions on those systems. They want to print documents from their captive accounts there to our printers here. I've already got LPD/LPR communication with one of the IBM mainframes in a remote site and so far so good. But IT folks from other systems express their doubts in LPD/LPR reliabilty. They would prefer a solution which is bidirectional and has some kind of delivery aknowledge. If it's not, there's no point. I might as well use LPD.

[Jan van den Ende]

Dima,

Just some thoughts, without any way to implement or test:

Is there any way that you can somehow recognise where a file came from?
Preferably also, from which account on the remote system? (Maybe the remote app can be modified to include that info in the printjob?)
In that case, would it be possible to use Bojan's procedure (or anything similar), and to add some home-brew back-notification?

Yes, of course it would be much preferable if everything would simply be available, but the multi-OS world still is a long way from utopia...

All-in-all, I don't think it will be easy to generate a one-size-suits-all solution for every remote platform, but hey, "If it was easy we would employ schoolkids to do the job".

Well, I hope I at least woke some idea that might become workable.

If you anyhow succeed (maybe partly), would you please report here as to how you did it?

Just my EUR 0.02

Proost.

Have one on me.

jpe

[Dima Bessonov]

Jan, good point. End user notification won't hurt a bit.

Here's what I've found. Chapter 7.6 of RFC 1179, which defines LPD protocol (http://www.ietf.org/rfc/rfc1179.txt), reads:

!!! BEGIN QUOTE

7.6 M - Mail When Printed

+---+------+----+
| M | user | LF |
+---+------+----+
Command code - 'M'
Operand - User name

This entry causes mail to be sent to the user given as the operand at the host specified by the 'H' entry when the printing operation ends (successfully or unsuccessfully).

!!! END QUOTE

This is a part of Chapter 7, "Control file lines", which "discusses the format of the lines in the control file which is sent to the line printer daemon". I.e. any LPR client conforming to RFC 1179 should have a means to request this notification.

HP TCP/IP for OVMS has "PRINT /PARAMETERS=MAIL" which does just that. I tried the following command

PRINT TEST/QUE=TCPIP$LPD_OUT/PAR=(HOST=NMOS2,PRINT=LJ2302,MAIL)

and soon received the following mail:

MAIL> 29

#29 19-APR-2006 09:36:39.75 NEWMAIL
From: SMTP%"TCPIP$LPD@nmos21.95600.ru.mycompany.com"
To: SMTP%"MOSSDBE@NMOS01.95600.ru.mycompany.com"
CC:
Subj: Printer job

Return-Path: TCPIP$LPD@nmos21.95600.ru.mycompany.com
Received: from NMOS21.95600.ru.mycompany.com (165.0.2.236)
by nmos01.95600.ru.mycompany.com (V5.4-15F, OpenVMS V7.3-2 Alpha);
Wed, 19 Apr 2006 09:36:38 +0300 (EET DST)
Date: Wed, 19 Apr 2006 09:43:52 +0400 (????)
Message-Id: <06041909435200_202E52A5@nmos21.95600.ru.mycompany.com>
From: TCPIP$LPD@nmos21.95600.RU.mycompany.COM
To: MOSSDBE@nmos01.95600.ru.mycompany.com
Subject: Printer job
X-VMS-To: SMTP%"MOSSDBE@NMOS01.95600.ru.mycompany.com"

Your printer job (TEST) on LJ2302
has completed with status %SYSTEM-S-NORMAL, normal successful completion

#29 19-APR-2006 09:36:39.75 NEWMAIL

MAIL>

About notifying the system manager on the remote node. Every time a VMS node receives LPD request, it will be broadcast like this:

%%%%%%%%%%% OPCOM 19-APR-2006 09:43:38.09 %%%%%%%%%%%
Message from user TCPIP$LPD on NMOS21
Request on port 515 (LPD) from 165.0.2.249 remote port 1023

%%%%%%%%%%% OPCOM 19-APR-2006 09:43:52.04 %%%%%%%%%%%
Message from user SYSTEM on NMOS21
Job #562 on queue LJ2302 submitted by MOSSDBE@NMOS01.95600.ru.mycompany.com
is completed

Methinks this should be sufficient for both end user and system manager. It's kinda nice we don't have to reinvent the wheel...