TNA device to remote terminal

[Wayne Sothman]

Current system:
DIGITAL TCP/IP Services for OpenVMS VAX Version V4.2 on a VAXstation 4000-60 running OpenVMS V7.2

We're in the dark ages and just now setting up our Decerver 300's for TCPIP. We have a Decserver setup with IP address 156.144.38.80 with a VT terminal connected to Port 1. Defined a listener on the Port 1 as 2001. Did the rest of the port setup, including Proctocol set to TELNET.

I need to create a terminal as in LAT so I can run a detach process that gives users a menu system. Now from the VMS side I can do

TELNET 156.144.28.80 /port=2001

and get to the VT tube fine. So from what I've been reading I setup a TNA device as follows:

TELNET>CREATE_SESSION 156.144.38.80 2001 101

to give me a TNA101: terminal.

Now when I do a
$ Show term TNA101:
%SYSTEM-F-DEVOFFLINE, device is not in configuration or not available

$show device tna101: gives device status offline.

Needless to say then my detached process never seems to be able to connect to the VT tube. I can't seem to find the missing part of the puzzle for creating a device similiar to a LAT port for TCPIP services.

We have a similiar system running Multinet and using NTYCP we can create a port NTY101: and it behaves just like a LTA port and we can run the detched process to the VT terminal fine.

[Jan van den Ende]

Wayne,

I am at home now, so I can not fully check, but this I know: your port 2001 is your MAINTENACE port, the one you log in to for Terminal Server Maintenance Operations.
You need to define other _TELNET_ ports, and connect them each to a _TERMINAL_ port. (And yes, as usual, some morons decided to use the same word for different things that come together in the same device).

At your management console,

HELP will give you a list what HELP is available, and ISTR that under HELP SET PORT you find most (all?) of what you need.

HTH

Cheers.

Have one on me.

Jan

[Bojan Nemec]

Jan,

I am afraid you are wrong. Wayne says that he can connect to the terminal connected to the terminal server with TELNET 156.144.28.80 /port=2001, so the port works fine. This is also the best methot to test if all is setup fine.

Wayne,

If I remember well, there is a /PERMANENT qualifier with the CREATE_SESSION command. But I am not shure if this qualifier is in yours version. Reading the documentation (much newer version) http://h71000.www7.hp.com/doc/732FINAL/6525/6525pro_012.html#create_comm
I supose that the connection is esatablished only when the device is assigned. So try to open the device or simply do a SET HOST/DTE TNA101:.

Bojan

[Wayne Sothman]

Thanks for the quick replies.

Well I did setup port 5 on the Decserver with listener 2005 and attached the VT420 to it.

Then on the VMS side I did:

TELNET>CREATE_SESION 156.144.38.80 2005 105

This created TNA105: which now showed Online when I checked the device, and no errors when I did the SHO TERM TNA105:

After setting up the terminal characteristics and starting the detached process it took off fine on the VT420.

I am confused though about not be able to define listener 2001 on the Decserver 300.

How would I specify a TNA device to just Port 1 on the Decserver if I cannot use listener 2001? I understood it to be listeners 2001-2016 would reference ports 1-16 unless you specified mulitple ports for the listener.

Or as in the second reply is it okay to use 2001 on the Decserver. It did not seem to bother Multinet and I could do a TELNET into it with Dec TCPIP services

I'll have to experiment more tomorrow.

[Antoniov.]

Wayne,
create new session with /NOTIME qualifier.
Also, look at port configuration inside decserver; may be different configuration between port 1 and port 5.

Antonio Vigliotti

[Wayne Sothman]

I seem to have the terminals working now.
Thanks for the help.

But I still have a problem with the system running DEC TCPIP.

I have the Decserver 300 port for the VT terminal set to Remote Access since this is for an operator console that runs a menu system from a detached process. When the system is down or the detached process stops we do not want the operators attempting any login.

However once the detached process is stopped htting a key on the VT terminal offers a login prompt to the VAX on the TNA device.

The Multinet port using NTY device does not do this with Decserver port set to Remote access nor did LAT.

Is this a "feature" of the TNA device? I can't figure anything else to set in the Decserver 300.

[Ian Miller.]

the classic way of preventing a login prompt would be SET TERM/PERM/NOTYPEAHEAD but I don't know if this works on TNA devices.

[Bob Blunt]

Wayne, would it be possible to create the TN device as part of the detached process itself so that it creates and allocates the port rather than create the port independantly? I'm thinking that if the port is created separately, then the demise of the detached process will leave the port virtually connected to the terminal server and logging in will be possible.

If you could create the port as part of the detached process, when it goes away there might be a way to get the port to disconnect from the terminal server. That way, depending on the port's configuration, all your operators should get would be the Local> prompt.

Please also consider that the DECserver 300 has some really primitive and limited TCPIP capabilities when compared to the DECserver 90M or DECserver 7xx families. This might be a consideration for the future if you need to use more advanced features.

bob

[John Gillings]

Wayne,

>TELNET>CREATE_SESSION 156.144.38.80 2001 101
>
>to give me a TNA101: terminal.
>
>Now when I do a
>$ Show term TNA101:
>%SYSTEM-F-DEVOFFLINE, device is not in configuration or not available
>
>$show device tna101: gives device status offline


This might not help in getting to your ultimate goal, BUT it will explain this Heisenburgian behaviour.

TNA101 has no active channels when you create it. SHOW TERMINAL command opens a control channel, then closes it (possibly a few times). When the TNA controller sees the channel count increment then decrement to 0, it puts the terminal offline. This is quite normal for ephemeral devices. The irony is if you hadn't been cautious and issued a SHOW TERMINAL command first, it might have worked!

Make sure the FIRST thing you do with TNA101 is ALLOCATE it. You should then be able to issue SET/SHOW TERMINAL commmands, an open and close channels without the device vanishing from underneath you.

TELNET> create_session cscds700.sno.cpqcorp.net 2002
%TELNET-S-CRSES, Session created on TNA566
TELNET> Exit
$ allocate tna566
%DCL-I-ALLOC, _$1$TNA566: allocated
$ show term tna566
Terminal: _TNA566: Device_Type: Unknown Owner: GILLINGS
Username: GILLINGS
Remote Port Info: 16.176.160.100:2002

Input: 9600 LFfill: 0 Width: 80 Parity: None
Output: 9600 CRfill: 0 Page: 24

etc...


When you've finished DEALLOCATE then DELETE_SESSION to dispose of the device.

That said, CREATE_SESSION probably doesn't do what you want - it's not as flexible as a LAT application port.