DEC Alpha 3000-300 mit openVMS - Anfängerecke

wo? Auf der Alpha?

Auf dem Server (Windows mit Xming) habe ich sowas nicht. Ich habe connect von allen IP Adressen erlaubt.

Wie ich schon schrieb, der Server (hier Xming unter Windows), hat "access control = off" - entspricht wohl "xhost +". Andere Rechner (nicht aber die Alpha) können auch ungefragt Fenster erzeugen. Andere Schalter gibt es da nicht.

Auf welcher Version die Alpha aufbaut, weiss ich nicht. Nur, dass manches das Netzwerk betreffend doch anders ist als man so von unix/Linux gewohnt ist.

Unter Linux sage ich ja "export DISPLAY=192.168.1.131:0.0" und alles ist gut.

Leider hilft Dr. Google bei openVMS oft überhaupt nicht weiter.

1. Screen ist 0 und auch so erfasst. Siehe Post eiter oben

2. sh/ssh geht doch am Thema vorbei. Ich will den (völlig unsicheren) Transport TCP/IP-Port 6000, wie das andere Systeme auch können (unter linux: export DISPLAY= <ip-addr>:0.0 ; xeyes&). Dann wird doch nix über SSH getunnelt...?

Nochmals: ich kann kreuz und quer zwischen den vorhandenen Linux Systemen und Windows mit TCP Port 6000 X-Client-Server Verbindungen aufbauen (überall natürlich das Equivalent von "xhost +" eingestellt)

Ich will auch kein Remote Login machen, sondern nur ein banales Fenster eines Programmes, welches auf der Alpha läuft, auf einem anderen Rechner erscheinen lassen!

Ich vermute nun eher, dass es auf der Alpha/VMS noch irgendwelcher Kunstgriffe bedarf, bis eine X11-Verbindung über Port 6000 klappt.

Zitat von osf1g

Hast du mal versucht, einen X-Server unter Linux von der Alpha aus anzusprechen?

Klar, das war auch mein erster Versuch. Erst danach habe ich Xming unter Windows probiert.

Gerade nochmals weiter probiert: selbst eine nicht vorhandene IP-Adresse produziert sofort die gleiche Fehlermeldung. Soviel zum Thema "der Server ist das Problem". Ich vermute mal, die Alpha probiert erst gar keine abgehende Verbindung, sondern dieser Fehler wirk lokal produziert.

Wenn ich X11 über Port 6000 mache, gibt es keine "Authoirities". Das ist völlig ungesichert!

Server-Logs gibts nicht.

Wäre zu klären, ob es ein Client Log gibt, in dem dann mehr als das lapidare "%DECW-E-CANT_OPEN_DISPL, Can't open display" drin steht...

Gerade noch etwas getestet:

$ telnet 192.168.1.131 6000
%TELNET-I-TRYING, Trying ... 192.168.1.131
%TELNET-I-SESSION, Session 01, host 192.168.1.131, port 6000
-TELNET-I-ESCAPE, Escape character is ^]
fghxfgh
fg
%TELNET-S-REMCLOSED, Remote connection closed

geht. D.h. die Verbindung zum X11-Server auf dem PC ist grundsätzlich möglich.

Ich sehe dann auch die beendete Verbindung im "netstat" als "Wartend" - was korrekt ist.

Mache ich das

create/terminal/detach
-oder-
MC DECW$STARTLOGIN

kommt auf dem PC überhaupt keine Verbindung an. Im "netstat" ist nichts zu sehen, es müsste ja sonst zumindest wieder "Wartend" zu sehen sein, hätte der X11-Server des PCs die Verbindung bekommen und sogleich getrennt.

Zitat von Toshi

Reinhard : Hast Du mal von Alpha zu Alpha probiert? Vielleicht erst mal in einem Universum probieren, bevor sie Systemschranke überschritten wird?

Ich habe keine zweite Alpha...

Ich bin so naiv, dass ich glaubte, mit XWindows gäbe es keine Systemschranken

Es würde mit TCPIP nicht funktionieren, da der XDM nicht auf Port 6000 am "Hören" ist:

$ netstat
Active Internet connections
Proto Recv-Q Send-Q  Local Address             Foreign Address           (state)
tcp        0      0  192.168.1.147.22          192.168.1.131.52725       ESTABLISHED
tcp        0      0  *.5151                    *.*                       LISTEN
tcp        0      0  *.2049                    *.*                       LISTEN
tcp        0      0  *.79                      *.*                       LISTEN
tcp        0      0  *.111                     *.*                       LISTEN
udp        0      0  *.2049                    *.*
udp        0      0  *.5151                    *.*
udp        0      0  *.68                      *.*
udp        0      0  *.69                      *.*
udp        0      0  *.111                     *.*
udp        0      0  192.168.1.147.123         *.*
udp        0      0  LOCALHOST.123             *.*
udp        0      0  *.123                     *.*
udp        0      0  *.177                     *.*
udp        0      0  LOCALHOST.4999            *.*
Active SCTP associations
Proto Type  Local Address          Foreign Address        (state)
sctp  1to1   192.168.1.147.111                               LISTEN
             LOCALHOST.111

Auf Port 177 ist zumindest das X Display Manager Control Protocol (XDMCP) aktiv.

Alle anderen Ports kann ich auch als "gewollt" nachvollziehen...

5151 wäre nach offizieller Tabelle ESRI SDE Instance - ist aber wohl PCNFS

Aber: dies wäre eine 2. Baustelle (die Alpha als X Server zu nutzen) - es sei denn, das fehlende Listen auf Port 6000 wäre ein gemeinsames Symptom davon, dass immer noch keine abgehenden Verbindungen von Clients auf der Alpha auf X Server an anderen Rechner gemacht werden können.

Zitat von Schroeder

https://comp.os.vms.narkive.co…ls-help-with-x-over-tcpip

Da geht es explizit darum, DECWindows TCP/IP beizubringen. Evtl. des Lesens wert?

Danke für all diese Links, ich habe jeden einzelnen durchgesehen, und vieles ausprobiert, nichts davon hat geholfen.

Viele davon haben das "Can't open Display" Problem, enthalten aber auch keine (bei mir funktionierende) Lösung dafür.

Es muss sich um ein grundsätzliches Problem handeln.

Ich habe aber nun genug Zeit hinein gesteckt und glaube nicht mehr, dass ich das lokal hier hinbekomme.

Ich werde die Alpha irgendwann in die Nähe des PCs bringen (derzeit 20m weg) und dann die Ausgaben meiner X Programme lokal auf der Alpha ansehen können. Ich editiere diese in einer SSH Sitzung auf dem PC, und wollte die eben starten können und auf dem PC das Ergebnis sehen.

Ich könnte natürlich die Alpha über SSH von aussen erreichbar gestalten, falls einer von euch mal reinschauen möchte...

Meine 2. Alpha ist gestern angekommen:

* Systemgehäuse komplett ohne Festplatten, dafür aber 96MB RAM und zweite Grafik.

* Kabel RGB auf BNC Stecker.

* Tastatur - beschädigt wegen unzureichender Verpackung

* Rechteckige Maus

Was mir nun noch fehlt:

* Kabel 15-pol zu Tastatur/Maus.

Das ist doch sicher nur Kabel, keine Elektronik drin, oder?

Hat das jemand schon mal durchgeklingelt? Sonst mache ich das und baue es nach.

Die teildefekte Tastatur kann ich notdürftig reparieren, mit Tastenkappen der Funktionstasten auf die wichtigeren Positionen umgesteckt.

Schön ist, dass da drin zwei Festplatten Montagerahmen sind.

PS: jetzt werde ich wohl doch mal DECNET aktivieren und "Clustern"...

So, zwei Nachmittage damit verbracht mein 1985er Raytrace Programm (damals auf PC unter TURBO C!) auf die ALPHA zu Portieren.

Leider hat die AXP 3000-X nur 8 Bit/Pixel mit Lookup Tabelle. Insofern geht der ganze RGB888 Farbraum nur per Dithering auf RGB222.

Auf dem PC brauchte damals so ein Bild Stunden, jetzt geht es in Sekunden/Minuten.

(640x480)

(1280x1024)

(Die Textur der Erde ist irgendwie nicht ganz richtig, das muss ich noch klären)

Ich bräuchte jetzt Tipps, wie ich von einem C-Programm aus die serielle Schnittstelle anspeche.

Original geht darauf alternativ zur Grafik auch die Konsole, laut Symbol am Gehäuse ist diese aber auch für Druckeranschluss gedacht.

Ich möchte aber nicht über einen Druckerspooler gehen sondern das vom Programm aus ansprechen.

Unter linux wäre das ja ungefähr so:

open ("/dev/tty.."), ioctl(für Baudrate usw.) dann read() und write()

Ach.. und eine ganz banale Frage: wie fahre ich das openVMS runter OHNE mich dazu zunächst einzuloggen?

Zitat von Schroeder

Zitat von DL5UY

Ach.. und eine ganz banale Frage: wie fahre ich das openVMS runter OHNE mich dazu zunächst einzuloggen?

Gar nicht

Diese Antwort würde ich ja gerne "Disliken" aber solch einen Knopf gibt's ja nicht

Dafür geht jetzt der erste Plotter, aber leider nicht an der ALPHA.

Ah, Vielen Dank für den Link. Ich weiss nun schon einmal, dass die Schnittstelle "TTA1" ist und Default auch auf 9600 Baud steht, denn mit

$ show device/full tta


Terminal TTA1:, device type unknown, is online, record-oriented device, carriage
control.


Error count                    0    Operations completed                  0
Owner process                 ""    Owner UIC                      [SYSTEM]
Owner process ID        00000000    Dev Prot              S:RWPL,O:RWPL,G,W
Reference count                0    Default buffer size                  80


Device TTA0:, device type DECwindows input device, is online, record-oriented
device, carriage control.


Error count                    0    Operations completed                  0
Owner process                 ""    Owner UIC                      [SYSTEM]
Owner process ID        00000000    Dev Prot              S:RWPL,O:RWPL,G,W
Reference count                0    Default buffer size                  80

und gleich dem ersten Versuch mit

$ copy earth.c tta1:

kommt der Dateiinhalt richtig auf der seriellen Schnittstelle heraus.

Allerdings läuft dort auch ein Login, sobald ich dort Return eingebe, kommt der Login prompt. Das muss natürlich noch weg...

Zitat von Bernhard

$SET TERMINAL /NOINTERACTIVE /PERM (???)

sollte sich der Login Process vom Terminal fernhalten lassen.

leider nicht. Diese ganzen Terminal Einstellungen hatte ich schon gefunden, aber die verstellen wohl nur das Verhalten der Schnittstelle, nicht aber, ob ein Return zum Start eines Login Prozesses führt. Bis auf....

Durch Suchen fand ich dass:

SET TERMINAL/NOTYPEAHEAD/PERMANENT <Schnittstelle>

helfen soll und das tut es auch.

Die Logik dahinter?

Zitat von Schroeder

QIO und QIOWait bin ich fit. Ich bin dabei

Vielleicht hast mal ein kleines Beispiel dazu?

Sozusagen das Equivalent der UNIX Aufrufe open(), ioctl(), read(), write(), close()

Wie bekomme ich den Channel?

Zitat

I/O channel assigned to the device to which the request is directed. The chan argument is a word value containing the number of the I/O channel; however, $QIO uses only the low-order word.