Re: Doch noch mal ne grundsätzliche Frage dazu
- From: "Martin Vorlaender" <mv@xxxxxxxxxxxxxx>
- Date: Mon, 09 Apr 2007 18:42:14 +0200
Ulrich Bellgardt <UliBellgardtsSpamSink@xxxxxxxxx> wrote:
Michael Berger wrote:
ich habe doch noch mal ne grundsätzliche Frage zu dem Verfahren. Habe
das jetzt sowohl unter Linux, mit puTTY, als auch unter Windows mit KEA!
ausprobiert.
Es funktioniert in beiden Fällen - beim ersten login. Wenn ich mich mit
logout abmelde, und danach wieder eine neue Verbindung herstellen will,
kommt die Ausschrift
Connected to the VAX simulator
aber danach ist Schluß, kein Login Prompt erscheint. Ist da nur eine der
vielen Einstellungen für die Verbindung falsch voreingestellt, oder ist
das ein unvermeidliches Problem?
ich habe es bei mir reproduzieren koennen. Nach Telnet auf (bei mir)
Port 10000, login, und sofortigem Logout ist erst mal Feierabend. Nach
gefuehlten 2 Minuten kommt die folgende OPCOM - Meldung, danach kann man
wieder einloggen.
[OPCOM-Meldung "Local interactive login failure" mit
"%LOGIN-F-CMDINPUT, error reading command"]
In der Zwischenzeit haelt ein Prozess mit dem Namen "_TTA0:" das
(emulierte) TTA0 fest, das ist aber zu dem Zeitpunkt nicht mit der
Telnet-Sitzung verbunden.
Ich halte das fuer eine Macke im Telnet-Server von SIMH, der nach
erfolgtem Logout den Telnet-Benutzer abhaengt, dem emulierten
Terminal-Anschluss der Vax aber noch ein <CR> oder so was schickt,
sodass der Login-Prompt der VAX im Nichts endet und bis zum Timeout auf
den Usernamen wartet.
Das Ganze sieht insgesamt ja so aus, wie wenn man an einem VT220
<Return> drueckt, dann beim Login-Prompt aber keinen Usernamen eingibt,
und wartet, was passiert. Nur dass dabei dann der Username: prompt auf
dem VT220 sichtbar ist, ebenso wie "Error reading command input" nach
Ablauf der Frist.
Mir faellt kein wirklich guter Weg ein, darum herum zu kommen.
Man koennte das Ganze verkuerzen, indem man die Timeout-Konstante
verkuerzt (System-Parameter LGI_RETRY_TMO verkleinern), oder sich die
Wartezeit vertreibt, indem man z.B. mit SHO USER/FULL die PID des
blockierenden Prozesses herausfindet, und diesen dann kraft seiner
Privilegien abschiesst. Aber wie gesagt, ich halte das beides fuer
Notloesungen und nicht wirklich fuer "gut".
Ich hab's gerade auch mal ausprobiert: die Telnet-Verbindung bleibt nach
einem Logout offen, und der Prozess _TTA0: entsteht erst nach einem erneuten
<RETURN> im Telnet-Fenster, d.h. der Connect zu VMS ist wieder da, aber
irgendwas im internen Status der DZ-Line verhindert die Ausgabe des Login-
Prompts.
Ich hab' bisher nur rudimentär in den SimH-Quellen geforscht (warum z.B.
unter OpenVMS Alpha der automatische Lade-Mechanismus für INI-Dateien
nicht funktioniert), aber wenn ich Zeit habe, schau' ich mal rein.
cu,
Martin
--
One OS to rule them all | Martin Vorlaender | OpenVMS rules!
One OS to find them | work: mv@xxxxxxxxxxxxxx
One OS to bring them all | http://www.pdv-systeme.de/users/martinv/
And in the Darkness bind them.| home: martin@xxxxxxxxxxxxxxxxx
.
- References:
- Terminal-Emulationen
- From: Michael Berger
- Re: Terminal-Emulationen
- From: Michael Unger
- Doch noch mal ne grundsätzliche Frage dazu
- From: Michael Berger
- Re: Doch noch mal ne grundsätzliche Frage dazu
- From: Ulrich Bellgardt
- Terminal-Emulationen
- Prev by Date: Re: Doch noch mal ne grundsätzliche Frage dazu
- Next by Date: Re: Terminal-Emulationen
- Previous by thread: Re: Doch noch mal ne grundsätzliche Frage dazu
- Next by thread: Re: Doch noch mal ne grundsätzliche Frage dazu
- Index(es):
Relevant Pages
|
