Your remote access has expired

[H.W. van Ommen]

Since 1 jan 2010 we've received the following message, when connected through telnet to our system. (after we filled out username and password)

"Your remote access has expired."

We've inspected Uaf settings- and licenses on the system, but we found nothing wrong with it.

All Vms accounts have the some problem, the only thing that works is the console.

On the console, telnet to other systems works fine.

Our customer is not able to view the console for more system-info, because he isn't in the office; but maybe is this an known issue ??

[Steven Schweda · Accepted solution]

As usual, the output from a command like
TCPIP SHOW VERSION
(or equivalent for a third-party IP software
package) might be useful.

> "Your remote access has expired."

To me, that does not look like a message from
any part of the VMS OS or any likely IP
software package. If that's really the whole
message, then I'd be looking at some general
command procedure, like, say,
"SYS$MANAGER:SYLOGIN.COM" ("SYS$SYLOGIN"), to
see if there's some user-written code which
might be emitting it.

If it's not really the whole message, then it
might be better to see the actual message.

[Duncan Morris]

Hi,

this does not sem to be a VMS message! What version are you running - and on what hardware vax/alpha/itanium?

I would suspect that this is a user message. Have a look at SYLOGIN.COM for clues. Possibly add SET VERIFY temporarily to help you trace the login process.

You can also try logging in with

username/nocommand

to bypass the local LOGIN.COM

Duncan

[Robert Gezelter]

HW,

I would also add a check for any proxy gateways in the path.

A good check for this is to telnet to localhost (127.0.0.1) from the console and see if the problem still manifests.

Another way to identify the source of the message is to scan the disk for the message string.

Generally, it is best (or at least fastest) to pursue several of these avenues.

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

[H.W. van Ommen]

I'm sorry.

This isn't a "real" Vms system, it's running in an emulator mode

Proliant server: ML 150
VMS versie: VMS 5.5 â 2H4

UCX: Digital TCP/IP Services for OpenVMS VAX Version V4.2 - ECO 3 on a VAX 4000-105A running OpenVMS V5.5-2H4

The manufactor of the emulator told us, that we must set the time- and date back to
1-jan-2009, probely the problem will then be solved; but we don't do that !!

Als the manucator of the emulator point does not cover this problem, he said that it is indeed a VMS problem; but i never saw this message before in VMS.

Also on internet, i can't find anything like this message.

[Volker Halle]

H.W.,

whatever 'emulator' you're using (and there aren't that many around), it will emulate a 'VAX' and not 'VMS' and it has no knowledge at all about TELNET and such.

Does TELNET localhost from the console fail as well ?

You can use a brute-force search to find out, which image this message is coming from:

$ SEARCH SYS$SYSDEVICE:[*...]*.EXE "Your remote access has exipred"

Please consider to post the error message you're seeing in verbatim mode, character by character.

Volker.

[Colin Butcher]

Network access to an OS running under an emulator (whether it be SIMH or Charon or Camiel's ES40 or whatever) needs to go through a virtual network adapter to reach the 'inside of the emulator' - and the first thing you hit from the outside is the host platform OS, followed by the outer layer of the virtual network adapter used by the emulator.

If the emulator code is capable of reading the time & date (and it should be) and access to it from the outside through the virtual network adapter is controlled by some licencing software that checks time & date (just like the PAK / LMF mechanisms allows you to do) then it's quite possible for this to happen. Indeed it fits why you're being told to roll the date back.

It could be an emulator licence issue of some kind, or it could be a year 2010 problem with the emulator's time & date / licence cheking code.

The message is almost certainly coming from the 'outer layer' of the emulator as you try to access the virtual network adapter and your connection attempt is rejected.

Cheers, Colin (http://www.xdelta.co.uk).

[Volker Halle]

Colin,

from the original description, it sounds like this error happens AFTER the Username/Password have been entered in OpenVMS, i.e. AFTER the TELNET session has been established. How could the emulator intercept this TELNET session and issue a 'message' ?

Volker.

[Colin Butcher]

Yes Volker, that's a good point. I missed that - beware making assumptions based on previous experiences!

I wonder what happens with other connections to the emulated VAX locally from the PC hosting the emulator, or using other protocols over the network (LAT maybe?).

It's worth raking through the entire chain of establishing a remote session to the emulated VAX/VMS system, all the way from the external connection to the DCL prompt (or command file / menu / image / whatver if it's a captive accout).

It'll be interesting to know what actually happened. Any news?

Cheers, Colin (http://www.xdelta.co.uk).

[The Brit]

It looks like something in the Login Process is producing this error. Could it be something using

f$getjpi("","tt_phydevnam") .NES. "_OPA0:" then Send Message and Logout

(or an equivalent System Service)

I think that I would be picking through the login process.

Dave.