Reverse Telnet TNA Device

[Hal Kuff]

Hi, sorry to do Back to the Future.. but I know how to create a service on a DS900 to expose a port.. how do I get to the port (10.10.10.10 port 2010) for say port 10 on the server from a program on the OpenVMS system? Where does the TNA mapping take place? Basicaly we have outbound LAT modems and need LAT to go away...

[Jon Pinkley]

Hal,

Are you using the DS900 still? I would try connecting to tcp port 30xx the ip address associated with the terminal server, where xx is the port #. I.e. to connect to async port 5 on the DS900, connect to tcp port 3005. You have to have the port configured for remote access.

Why the need to have LAT go away? Are there routers between the terminal server and the OpenVMS system? Does there need to be (distance, etc.)?

Jon

[John Gillings]

Hal,

Telnet doesn't work like LAT. Although you can create a TNA device in much the same way as you create a LAT application port, you can't just open it from an application. I've never quite understood the reasons for this, but that's all academic. Banging your head against that brick wall won't help.

One (ugly) way around this uses the pseudo terminal interface. You have a process between your application and the network, which can be fed the appropriate TELNET commands to make the required connection. You can then communicate with an FTA device, just like you're currently communicating with an LTA device. The cost is an extra process per port.

I've got some sample code that does this, if you're interested.

[marsh_1]

alternatively you can spool the tna device to the old lat device.

[Hal Kuff]

Hi, great input (no pun)... basically this is a legacy application that is run from a command file by a vendor at login and then dials back a number tied to their account and sends product labels to a bar code printer conencted to a mode... low tech but has worked for 20 years... interested in 'spooling to the LTA from TNA'... that work?

[marsh_1]

hi,

sorry meant spool the lta device to a telnetsym print queue set up in this instance to point to - /on:"10.10.10.10:2010" -.
but these were set lta devices known to our app going to decserver ports no modems involved, don't how your application does it.
you can try spooling direct to a tna device i got variable results when i tried it.

HTH

[Volker Halle]

Hal,

did you check the $ TELNET/CREATE_SESSION command ? It is supposed to create a TNA device and map it to an IP-port on the DECserver.

Volker.

[Volker Halle]

Hal,

consider to have a look at this thread:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1096598

Volker.

[Hakan Zanderau ( Anders]

Maybe I'm sticking out my neck here......

If your application uses hardcoded LTAdevices.
Wouldn't a logical name take care of the redirection from LTA to TNA +

Create a TNA-device and remap the LTA-device

$ DEFINE/SYS LTA1: TNA1:

Hakan

[marsh_1]

hal,

we did ours like this

$INIT/QUE/PROC=TCPIP$TELNETSYM/RETAIN=ERROR/RECORD_BLOCKING /SCHEDULE=NOSIZE/DEF=(noburst,nofeed,noflag,notrail) /ON:"'decserver_ip_host_name':'ip_port'" 'que_name'

$set dev 'lta_dev_name':/spooled='telnetsym_que

with these two tcp logicals set

$DEFINE/SYSTEM TCPIP$TELNETSYM_IDLE_TIMEOUT "0 00:00:30.00"
$DEFINE/SYSTEM TCPIP$TELNETSYM_RETRY_INTERVAL "0 00:00:30.00"

example tna device creation

$TELNET/CREATE_SESSION/TIMEOUT=(NOIDLE,RECONNECTION=0:0:30) 'ip_host_name' 'port' 'tna_device_number'

HTH

[Richard Jordan]

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]

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.

[Hoff]

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]

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