Operating System - OpenVMS
1755422 Members
2835 Online
108832 Solutions
New Discussion юеВ

Reverse Telnet TNA Device

 
Richard Jordan
Regular Advisor

Re: Reverse Telnet TNA Device

We had to set TNA devices up for direct printing applications when a customer running old code switched from dedicated lines to internet VPN tunnels for their remote locations. No more LAT. Their MUXservers were replaced with DECserver 90M+ units, which use (2000 + physical port number) for the IP port. A printer on port 8 can be connected to using the DECserver IP address, port 2008.

We had to set a couple of additional settings on the ports; you might need to take a look at these if you have communications issues with your modem:

Local> CHANGE PORT 8 TELNET SERVER NEWLINE TO HOST
Local> CHANGE PORT 8 TELNET SERVER TRANSMIT CHARACTER SIZE 8
Local> CHANGE PORT 8 TELNET SERVER RECEIVE CHARACTER SIZE 8


The old applications used direct (non-queued, non-spooled) printing to the 'print device' for critical items, once a TXA serial port, later LTA, and now TNA.

I don't know how closely our experience will map to a modem connection.

TNA devices cannot be spooled, at least in the VMS versions involved. We kept the LTA device and spooled it to the new queue.

The create command looks like this:

TELNET/CREATE/TIMEOUT=0-0:0:10 192.168.178.2 2008 100

which creates device TNA100. We do SET TERM on the device to set page size/width/etc just like a normal physical port. For our queues we use PRTSMB as the processor; LATSYM kept causing spurious data when it disconnected.
John Gillings
Honored Contributor

Re: Reverse Telnet TNA Device

TELNET/CREATE_SESSION and TELNETSYM are great for changing from LAT to Telnet for printers that's what they're for. But they don't work properly for communications from the device back to the program.

In this case we're dealing with a modem which typically requires feedback from the device, so may not be workable.

A crucible of informative mistakes
Hoff
Honored Contributor

Re: Reverse Telnet TNA Device

Some details of the application sequence might be useful; is the widget connecting to a known and fixed LT and lobbing out a dial sequence?

Or is the application going through the LAT $qio interface?

If it's the former, that might be feasible to deal with.

The latter would be a bit more work, as the $qio stuff is going to be different.

Depending on the particular goals and how this whole application is stacked, I might look to use a pseudo terminal. But I'm not sure that's appropriate without a few more words around the environment.

I can think of a massively brute-force and hideously ugly way to do this (if the application does use LAT $qio operations), but that's fodder for another discussion and a discussion only if it becomes necessary.

And depending on what the application does and what use rights exist here, it might be feasible to reverse engineer and/or recode it and/or disassemble it.
Hal Kuff
Occasional Advisor

Re: Reverse Telnet TNA Device

OK, we decided to place an Alpha Ds-10 into the configuration and let the old legacy prgram remian on an Alpha while the rest of the applications are on Itanium... As the code base for this app is 30 years old (litterally) it was more expedient to do this and get a committment to recode it using QIO... Having said that the response and deopth of thinking was just GREAT and no doubt someone hooking up printers will benefit greatly