DECnet config problem?

[Michael LaRoche]

I don't know if this will help but if you can check on if there were any changes to sylogin.com since the time before you rebooted.

Also look in there and see where if anywhere the if mode .eqs. "interactive" branches to.

[Volker Halle]

Imre,

if I turn on SET AUDIT/ALARM/ENA=ACCESS=ALL and do set SET HOST 0, the sequence of file access is:

RTPAD,LIBOTS,LIBRTL (from current process)
LOGINOUT on RTAn: device

You're missing the LOGINOUT entry, so we can be SURE, that LOGINOUT isn't even touched - all the questions relating to actions to be performed by LOGINOUT are therefore irrelevant...

Could it be something in the TTY system params ? Or some resource problems ?

Volker.

[Antoniov.]

Imre,
if you see Username prompt and you can can type the password I guess you can enter into system then you are logged out immediatly.
It's very weird ...
My check list is:
- File protection in SYS$MANAGER:SYLOGIN.COM
- Parameter RJOBLIM in SYSGEN
- Parameter UAFALTERNATE in SYSGEN ?
- Licence exausted
- Something in SYLOGIN.COM like
SET TERM/INQUIRE or LOGOUT

No any other idea now.

Antonio Vigliotti

[Imre Molnar]

As i wrote:
We can't see/get the Username: prompt...
RJOBLIM is 16, maybe enough good...
TTY params seems to good also...
License are active...

I suspect that the LOGINOUT.EXE doesn't start and catch the login...

As Volker wrote too...

[Antoniov.]

Because trouble started after reboot may be something in system parameters.
May you make a dump of sysgen?

Antonio Vigliotti

[Imre Molnar]

I tried to use an old vmssys.par file without any success...

[Volker Halle · Accepted solution]

Imre,

how do you actually log in to the system after the boot ?

Here is another article, which shows, how you could verify, whether UCB$M_TT_NOLOGIN is set (this bit would prevent LOGINs if set in the terminal UCB in UCB$L_DEVSTS).

http://h18000.www1.hp.com/support/asktima/operating_systems/00993FC4-93382300-33028F.html

The article is for VAX, for Alpha you should try this:

$ ANAL/SYS
SDA> exa @SYS$AR_JOBCTLMB+ucb$l_devsts

While you are in SDA, please also try:

SDA> SHOW DEV LTA0
SDA> EXA UCB+UCB$L_DEVSTS

and the same for TNA0, and RTA0

Volker.

[Imre Molnar]

Volker you are GREAT!

That was the problem, and SET INTERACTIVE/LOGIN=64 solved the problem.

Special thanks for You and the whole community for your priceless help!

[Volker Halle]

Imre,

now you still have to find the error in your startup procedures, which prevents the

$set logins/interactive='startup$interactive_logins'

in VMS$LPBEGIN-050_STARTUP.COM from having been executed.

Volker.

[Jan van den Ende]

Imre, Volker,

Somehow this surprises me!

AFAIK, SET LOGIN/INTER=0 prevents interactive login, UNLESS the used username has OPER priv as a default priv in SYSUAF.
How is that checked if there is no possibility to enter the username?

(...just fantasising now...) does this mean SET LOGINS (even if /inter=0) must have been executed to tell LOGINOUT to present the Username: prompt?

just curious.

Cheers.

Have one on me.

Jan

[Volker Halle]

Jan,

this is a very unusual problem caused by some kind of error during startup. It's not directly related to your SET LOGIN/INTER=0 kind of question.

If the 'initial' SET LOGIN/INTER=xxx command has NOT been issued during the OpenVMS system startup (see one of my previous replies), then the UCB$M_TT_NOLOGINS bit is set in the job controller mailbox (and probably also in the various terminal UCBs, like RTA0, TNA0, LTA0). This will prevent the terminal driver from sending an UNSOLICITED INPUT notification to the job controller, thereby preventing ANY interactive logins (with the symptoms discussed here...).

I finally went to read the Internals and Data Structures manual chapter about the job controller and process creation and the following sentence triggered 'my alarms' ;-)

> If the terminal does not have the SECURE characteristics, IF LOGINS ON IT ARE ALLOWED, and if the character is a standard terminator..., the driver sends a messages to the job controller mailbox, ... and so on.

Please also see the 2 articles referenced in my previous replies and enjoy reading the [TTDRVR]TTYCHARI source listing.

Volker.

[Jan van den Ende]

Thank you Volker!

That is quite an explanation THAT, _and_ WHY, my hunch was correct!

Cheers.

Have one on me (you deserved more than one here! :-)

Jan