Services problem on VMS 6.2 ucx 4.1

[DennisKennedy]

Hello All,

I hope everyone is have a great day!

When running a telnet session to this server(production) I recieve the following error:

************** ERROR **********************
DEVICE NOT SET UP, CONTACT SYSTEM MANAGER
myclientipaddress
NODE: myclientipaddress
************** ERROR **********************

This happens after sucessful login. I have followed some leads from earlier posts as I am a 2 week old on Openvms:

sys$manager:ucx$config: servers and clients are enabled.

UCX> show version

Digital TCP/IP Services for OpenVMS Alpha Version V4.1 on a AlphaServer 4000 5/466 4mb running OpenVMS V6.2-1H3

This is pre-migration so new software/upgrades are not an option.

I can however "set host/telnet" from this server to my development server which is not having this problem.

Telnet at the moment is just a plus or first step, ftp is also not communicating:

421 Service not available, Remote server has closed the connection
%FTP-E-LOGREJ, Login request rejected

I believe I had seen a .mdd? file with a list of ipaddress' somewhere.

Any help would be appreciated and scored =)

[Volker Halle]

Dennis,

welcome to the OpenVMS ITRC forum and the world of OpenVMS !

The error messages shown after your successful TELNET login is NOT coming from UCX or OpenVMS, but must be a system-specific message set up by the system manager of this system. You can search for this message in either SYS$MANAGER:SYLOGIN.COM or LOGIN.COM in your login-directory.

Regarding the FTP error, please check, whether the FTP service is enabled:

$ UCX SHOW SERVICE

If it's disable,d you can use @SYS$MANAGER:UCX$CONFIG to enable the FTP service - assuming you have system manager privileges on this system.

Volker.

[DennisKennedy]

Thanks Volker for your reply.

I will check the syslogin.com and login.com. I only have console access so will be a bit. The ftp services (client/server) are enabled via ucx so I will check the login script to see if the previous admin had some tricks up his sleeve.

[DennisKennedy]

The login.com file on the production server is identical to the login.com on the dev server so that rules out the login.com.

The syslogin.com was not found on either server:

Severname>type/page sys$manager:syslogin.com
%TYPE-W-SEARCHFAIL, error searching for SYS$COMMON:[SYSMGR]SYSLOGIN.COM;
-RMS-E-FNF, file not found

I appreciate it as admin documentation is hard to find on these versions.

[Steven Schweda]

> [...] SYS$MANAGER:SYLOGIN.COM

> [...] sys$manager:syslogin.com

More than case differs here.

[Hoff · Accepted solution]

And if it's not the extra S, issue the command

SHOW LOGICAL SYS$SYLOGIN

as that logical name may well translate to a different directory and/or different filename than the one that Volker pointed to.

The massive brute-force approach is to issue SEARCH commands for each of your disk devices that is presently mounted and in use on the affected (afflicted?) server:

SEARCH SYS$SYSDEVICE:[*...]*.*;0/WINDOW=0 -
"DEVICE NOT SET UP, CONTACT SYSTEM MANAGER"

where SYS$SYSDEVICE is your system disk device, and where you'll have to use SHOW DEVICE D or such to find the other disk device names present in your configuration. This command will take a while to complete.

Stephen Hoffman
HoffmanLabs LLC

[Volker Halle]

Dennis,


I appreciate it as admin documentation is hard to find on these versions.


OpenVMS system management is in nearly all cases independant of the OpenVMS version or architecure and did not cahnge too much over the last 30 years.

In your case, it seems like your system setup documentation is incomplete or even non-existing ? So you might need to trace your system login procedures step-by-step to find the procedure, which emits these error messages after TELNET login.

LOGINOUT calls the DCL-procedure pointed to be the system-wide logical SYS$SYLOGIN before it executes the LOGIN-procedure specified for the user's accountin SYSUAF. Those procedures may then call other DCL procedures ...

Volker.

[Robert Gezelter]

Dennis,

As has been noted, the system login file is (by default) SYS$MANAGER$SYLOGIN.COM. It could also have been redirected as has been described.

However, I would recommend extreme caution. The message that you are receiving is not a standard message. It may be constant (as has been observed) or it may be built dynamically. In either event, caution is recommended, particularly if there is no documentation. The path that generates that message could, as you have said, be part of something larger.

I would recommend careful examination of the login sequence for the account(s) in question. The follow-on comment to "step lightly" is heartfelt, as I have untangled several client situations of this type in the past. Some of them were, to put it politely, interesting.

- Bob Gezelter, http://www.rlgsc.com

[DennisKennedy]

This has helped identify a script or program that I need to research STTV5. Not sure if this is a custom application or an installed one. The script is owned by a different user.

Thank you all for your help. I will assign points and leave this open for a day to see if anybody knows about STTV5.

And of course especially with a production system caution is prioriy 1.

[DennisKennedy]

Yes 0 documentation. I was given a login and told it has admin/root privilages. My HPUX servers are stable as an ox so I took on this project. Looks like I have my hands full. =)