Problem telnet to Alpha/OpenVMS v8.2

[marchunan]

Hi all,

Recently one of our QA engineer used this Alpha/OpenVMS v8.2 server to test one of our application which verifies/reports many of the SYSGEN login (LGI) parameters.I have given him system account credentials as he needs to change/test the system paramater values. He said he changed LGI_BRK_LIM values from 5 to 8, but I don't know whether he changed any other paramters. Now I am not able to do TELNET login. When I tried telnet from DOS prompt and other VMS node, I get the following error, and I am unable to login to the server which is in other city. As I don't have access to console, I need to reboot this server, I have another OpenVMS v7.3-2 on this server for dual boot purpose.

C:\> telnet devpw1

" No logical name match

Connection to host lost"

C:\>

From another VMS node

$ telnet devpw1

%TELNET-I-TRYING, Trying ... 10.160.88.79

%TELNET-I-SESSION, Session 01, host devpw1, port 23

-TELNET-I-ESCAPE, Escape character is ^]

No logical name match

%TELNET-S-REMCLOSED, Remote connection closed

-TELNET-I-SESSION, Session 01, host devpw1, port 23

$ rsh devpw1 /password=deivanai116 @SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN NO YES LATER YES NONE

%RSH-E-FAILED, INTERnet ACP AUXS error during process exit  Status = %SYSTEM-F-NOLOGNAM

(from remote)

Any idea/suggestion please...

Thanks

Archunan

[Volker Halle]

Archunan,

you should ask your QA engineer, what he/she has done. The system is probably not useable anymore. If  an importatnt LGI parameter has been changed, LOGINOUT may not work anymore ! With some luck, you may be able to log in on the console (OPA0:). Otherwise, you would have to manually restart the system using the last good set of system parameters (probably using SYSBOOT> USE AUTOGEN.PAR).

Volker,.

[Hoff]

Have you eliminated your product as the culprit?  Checked the server logs?

Given your question and given what the QA engineer has reported (and given the obvious inference that you might suspect your QA engineer may have caused this, sans any specific proof), I'd consider your product as the immediate and chief suspect.  That the product is heavily privileged and that it inspects low-level sections of the OpenVMS environment is known.  If the product similarly also makes low-level changes - which would not be unheard of, particular with products that are operating with privileges and investigating parameters for compliance or for backup - then those changes and those activities (and whether intentional or otherwise) can destabilize OpenVMS and TCP/IP Services.

Based on a quick search, the organization that appears to be your employer trades in security compliance and backup tools among other offerings, and these are areas which are common triggers for unstable environments, particularly when the products introduce low-level errors into the system environments.  I don't know exactly what you're working on here, but I'm well aware of a history of problems with products that work in this area; both compliance tools and disk BACKUP tools.

Do your due diligence, log into the OpenVMS box from the console port or from some other local serial connection (or potentially via DECnet, if that's both running and still operational here), and check the system environment and the TCP/IP environment, and particularly check the logs.  Make sure TCP/IP Services is running.  Make sure your product has not defined a logical name which conflicts with a system logical name.  And similar.  See what your product has done, at a low level.

Secondary to that, construct yourself disk images (BACKUP /IMAGE savesets or physical images or otherwise) of your test environments, and load those onto InfoServer disk volumes.  This allows establishing or resetting the QA environment quickly.  The ability to DIFFERENCES or SHA1 the files and directories involved can also be useful, as you can more quickly zero in on exactly what's changed between the initial and post-instalation environments.

And tertiary, look at PuTTY or other similiar and more modern terminal emulation clients, and move away from the Windows DOS box client, and definitely avoid the integrated HyperTerm client.    (I'd also suggest an upgrade to Windows 7, if you're still using Windows XP, as 7 is vastly superior to the morass that is XP.  Microsoft has removed HyperTerm from recent Windows.  The current HyperTerm is also superior to the old HyperTerm client that was integrated into old Windows versions.)

I'm presuming you have specific reasons for using and testing with V8.2 here, though testing with V8.3 and V8.4 would also be expected, if you're working on products that are targeting OpenVMS.

Beyond these, I'd recommend you and your management acquiring an escalation path or support organization - somebody that you can direct these questions and issues to, and obtain guidance from.  Your current and potential customers and potential partners do read these and the various other forums, after all.