Outbound Telnet TNAnnn Lives Forever

[Andreas Freiherr]

Hello again,

we are trying to replace LAT ports with outbound Telnet devices for WAN connections. I have found several hints on how to set up TNA devices for this purpose, but I cannot get rid of them after use.

Using TCP/IP Services V5.1 ECO 3 on OpenVMS V7.3-2 on an AlphaServer, it would appear that some operations on the device, like assigning a channel or writing data (causing the network connection to be established), increment the reference count, as seen in SHOW DEVICE TNAnnn/FULL. However, after finishing work and deassigning the channels, the reference count appears to remain at a non-zero level, inhibiting deletion of the TNA device.

The attached DCL script illustrates the behaviour. I get the following output:

HN02$ @refcnt
%TELNET-S-CRSES, Session created on TNA134
Reference Count is 0 after creation
Reference Count is 1 after opening
Reference Count is 2 after writing
Reference Count is 1 after closing
Reference Count is 1 after waiting 1st time
Reference Count is 1 after deleting
Reference Count is 1 after waiting 2nd time
Reference Count is 0 after using CLRREF
Device is gone after waiting 3rd time.
HN02$

(CLRREF is Hunter Goatley's tool to force a device's reference count to zero with a kernel mode routine.)

What am I doing wrong?

Andreas

[Antoniov.]

Hi Anreas,
first of all I'm afraid you have to change the type/extension of your attachment because the .com files are executable in windows environment :-O

I've looked at your file and it appears simply correct. However I guess your printer has bidirectional handshake and keeps live connection because you created telnet port as:
$ Telnet/Create_Session -
/Protocol=None -
/Timeout=(Idle=0:0:5,Reconnect=0:0:5) -
hph-hn66 9100
Usually I prefer permanet ports like:
$ Telnet/Create_Session -
/Protocol=None -
/Permanent
hph-hn66 9100
When you have to drop the port you can do:
$ UnitNo = F$GetDvi("HP_Printer","unit")
$ Telnet/Delete 'UnitNo'
Notice function f$getdvi to retrieve the unit number :-)
I can't try the above code; I hope can help you.

Antonio Vigliotti

[Andreas Freiherr]

Antonio,

First, thanks for the suggestion to use F$GETDVI to parse the unit number from the logical name. Your code is more obvious, and it does not depend on the prefix to be "_TNA" - two significant improvements. Caveat: the return value of the function is of F$TYPE INTEGER, which might in some cases need conversion to STRING before using.

For the TELNET commands, how exactly does the world change when I specify /PERMANENT? - I noticed that the TNA device was flagged as "Permanent" in the output of SHOW DEVICE in TELNET anyway, so I thought I don't need the option.

In another test that used /PERMANENT, I found myself trapped with a connection that was held open by the VMS side until the printer timed out. As soon as that happened, VMS would immediately reconnect even though there was no data to read or write, even if the owner process of the TNA device had long terminated. You could sit and watch the OPCOM messages keeping you posted about the connections coming and going every 90 seconds - at least, this alerted me that something was going wrong. Is that what you mean by "bidirectional handshaking"?

With the TELNET options in my example script, I get the desired behavior of automatically connecting when output is written and disconnecting shortly after no more output is produced (might be better if it happened immediately when the last channel is deassigned, but that's acceptable for now), so my only problem is that I cannot safely remove a TNA device: just forcing the reference count to zero might certainly have adverse effects if there actually still IS a process that uses the device.

Isn't this what the reference count was actually meant to indicate? So if it is nonzero in my example, then who is keeping the TNA busy?

Oh, and BTW: the attachment is not a DOS executable, it is executable in an OpenVMS environment! - Maybe you need to change your browser? ;-)

Regards,
Andreas

[Jan van den Ende]

Andreas,

I _THINK_ that Antonio ment to indicate that .COM files are _assumed_ to be DOS executable, and therefore to be executed, by M$ environments--- and maybe generate adverse effects.
I _DO_ know that several firewalls (among those the one I have to depend on at work) consider that to be unacceptable. I you rename them to .TXT, every human wil recognise it to be DCL (or DOS, or whatever) commands, but they will NOT be executed automaticly, and that RISK is the reason to refuse all .COM


hth,

Proost.

Have one on me.

Jan

[Andreas Freiherr]

Jan,

You're right: some programs *think* they know .COM means a binary file, sometimes without looking at the MIME type. A specific browser is an example that came to my mind, I didn't think of firewalls doing the same. If you need a copy of REFCNT.COM named REFCNT.TXT, I'd be happy to send one or post again, but I am a bit reluctant to posting the same attachment twice.

To avoid slipping away from the original topic: anybody have an explanation for the odd value of the reference count after the CLOSE?

This appears to be the only thing that keeps TELNET/DELETE from taking the desired effect.

Regards,
Andreas

[Garry Fruth · Accepted solution]

I tried using the commands in your procedure, connecting to an HP printer on port 9100, as well as connecting to localhost port 23. When I closed the file (DCL close), the reference count dropped to 0. I'm using TCPIP 5.4 eco 2.

[Ian Miller.]

I suppose a brute force way would be to use SDA to go through every processes channel table to find which process has a channel open to that TNA device.

[David B Sneddon]

Andreas,

If you are trying to replace LAT queues with TCPIP
then what we do here is define the queue to point
to the network device then setup a dummy LAT device
and spool it to the queue.

$ init/queue qname/on=a.b.c.d:9100/processor=tcpip$telnetsym
plus any other qualifiers you need
$ mcr latcp create port lta666:
$ mcr latcp set port lta666:/port=any_port/node=storm
$ set device lta666/spool=qname

Regards
Dave

[Antoniov.]

Andreas,
/PERMANENT qualifier means device exists until somebody issues delete command (as you posted even though there was no data to read or write).
I'm convinced is usefull for printer ports because users send datas more times.

The "bidirectional handshaking" is when printer send back to computer; this mainly happens when you use laser or inkjet or postscript printers which send information about their internal status. I suppose this data keep alive your connection because system reckons sent and received sockets. Look for received counter of your TNA port before delete it.

Antonio Vigliotti

[Andreas Freiherr]

Garry,

That's interesting: so your version of TCP/IP Services acts differently? - Sounds like it's update time again...

Ian,

I thought there might be a possibility like this, but I am not (yet?) familiar enough with SDA to do that myself without some reading beforehand. Is it very complicated?

David,

This would have been a good reply to my next question, when I proceed to queues. Probably not exactly what the authors had in mind when they invented SET DEV/SPOOL=..., but very useful anyway.

Currently, I need a solution for devices that are directly fed by an application (e.g., label printers where users are waiting for the label before they can proceed to the next transaction), but we'll also need spooled printers soon.

Antonio,

OK, so maybe I'll need the /PERMANENT when I have upgraded to a more recent version of TCP/IP Services. My current (old) version appears to implement this functionality by default.

The particular printer that I used for testing (HP LaserJet 4050TN) did not seem to send back data, at least not while I was watching it. But to be prepared, it might make sense to SET TERMINAL/NOTYPEAHEAD to avoid starting a login process, which might lead to another kind of trouble. Once the connection is established by an application program that knows if and when to expect a response, we shouldn't run into problems.

Thanks, everybody, for your thoughts and help!

Andreas