Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

Telnet Login Problem-VMS 8.3

Go to solution
Jerry Rieman

Telnet Login Problem-VMS 8.3

Ran into a telnet login problem last night that I had never seen before. Perhaps someone can suggest where to look. I suspect it may be related to a terminal naming problem as it looks like the TNA numbers rolled over to 10,000 when it happened.

Symptom -
Telnet users hit the system but do not get Username prompt

Decnet users can login

LAT users can login

Outgoing telnet sessions work ok

Security log shows the following message -

Auditable event: Detached process login failure
Event time: 29-MAR-2007 19:17:30.94
PID: 000190F9
Process name: _TNA10000:
Process owner: [1,4]
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)
Status: %RMS-F-CHN, assign channel system service request failed

I stopped and started telnet service - no luck.

Telnet service is set for Limit=500 - would not have hit that limit.

1 then stopped and started all tcp/ip servicss - that is when system crashed. As mentioned, the rolling over to a 10,000 TNA number seems more than coincidental. Is there a setting on this somewhere? Thanks for any help.
Galen Tackett
Valued Contributor

Re: Telnet Login Problem-VMS 8.3


My VMS V8.3 system is down for a while so I can't for certain if this would be a factor, but perhaps the TCPIP$INETACP process has used up its FILLM quota, which limits the number of open channels ("files").

Try this:

! Note the number shown for "File limit:"
! Note the number of channels open, shown at the end of the listing of
! channels.)


This should settle whether FILLM is the limiting factor.

On my VMS V7.3-2 system, this process when sitting idle appears to be using 24 of its current FILLM of 250. I'm not sure where that number 250 came from, without a little looking...
Jerry Rieman

Re: Telnet Login Problem-VMS 8.3

Thanks Galen-

show proc/phd - file limit - 256

show proc/chn - 25

Of course, this is after the system has only been up for 20 hours. Until my crash last night, the system had been up for about 90 days.

My gut keeps telling me that the "TNA10000" shown in the security log is significant - but not sure how. I have been through all my logs - accounting (which has everything enabled including image accounting), security (anal/audit), and operator - no anomolies until the event noted above.
Honored Contributor

Re: Telnet Login Problem-VMS 8.3

That looks like the roll-over sequence for big BG unit numbers.

Jerry Rieman

Re: Telnet Login Problem-VMS 8.3


That has to be it! Sorry for repeating a known problem but all my ITRC searches for similar problems came up empty. The sysgen help says SCSI devices but I am willing to bet a couple of beers that it is controlling the tna assignment as well. Probably was added in tcp/ip 5.6. It is not a dynamic param so looks like a reboot is in order to pick up the new value.

Many thanks to both of you for taking the time to help. Hoff, you have been properly repped.

atul sardana
Frequent Advisor

Re: Telnet Login Problem-VMS 8.3

dear jerry,

if you set telnet limit in thousands i think your problem will be solve by it,

as per my system i had set that limit to 10,000.
As example for you can check other settings as below ....

SYSTEM>>ucx sho service telnet/full

Service: TELNET
State: Enabled
Port: 23 Protocol: TCP Address:
Inactivity: 1 User_name: not defined Process: not defined
Limit: 10000 Active: 202 Peak: 285

File: not defined
Flags: Listen Rtty IPv6

Socket Opts: Keepalive Rcheck Scheck
Receive: 3000 Send: 3000

Log Opts: Actv Dactv Conn Error Logi Logo Mdfy Rjct
File: not defined

Reject msg: not defined
Accept host:
Accept netw:

I hope its useful for you..
I love VMS
Jerry Rieman

Re: Telnet Login Problem-VMS 8.3


If I am not mistaken, the "Limit" value refers to the number of concurrent sessions - not the max TNA number. My system "Limit" is set to 500 so I do not think that is the parameter that was giving me all the heartburn. I am going to try setting the "Device_Naming" sysgen param to 4. Of course, it will take a while until I know if that does the job. Thanks.
Volker Halle
Honored Contributor

Re: Telnet Login Problem-VMS 8.3


this is a known problem with TCPIP V5.6 - I've also seen it on an OpenVMS I64 V8.3 cluster as the TNA unit numbers exceeded 9999. The workaround is to set DEVICE_NAMING = 4, thereby limiting all devices to 4-digitl unit numbers. This workaround does work successfully.

The problem has been escalated as QXCM1000379192

Frequent Advisor

Re: Telnet Login Problem-VMS 8.3

I have systems which have experienced this and others which don't. There must be something more subtle at hand,,,

Device Device Error
Name Status Count
TNA0: Online 0
TNA24740: Online 0
TNA24776: Online 0
TNA24841: Online 0
TNA24911: Online 0
TNA24915: Online 0

I sure hope this system does not hang this week....

Re: Telnet Login Problem-VMS 8.3

Mr Volker is correct. This problem (which is not technically a TCP/IP problem - it's not our fault that the assign fails - but I digress) will be remedied in the upcomming version V5.6-ECO1 release. It was never a problem in either the V5.4 or V5.5 releases.
There is a patched version of V5.6 TNdriver.
By the way, you must have a six character node name to experience this problem.

Also - In OpenVMS version 8.3 there will be some additions to the sysgen parameter "DEVICE_NAMING" to allow for different unit number maximum values.