SIEMENS MX-300/500 RM400 (intel CPU)

Moin,

Was für eine MX300 bekommst du? NSC oder Intel?
Weitere Infos kann ich ggf. liefern (Einstellanweisung, Speicherausbau,...),
wenn du etwas über die Baugruppen sagen kannst.

die Baugruppen-Sachnummern fangen z.B. mit S26361-... an.

Die MX500 ist auch was feines... (auch hier: NSC od. Intel?). Da
muss ich mein Gedächtnis mal befragen, was es so noch hergibt... :-).
Ich habe aber leider kein Installations-Band für die Maschine...

Einen Teil der Baugruppen, die in einer mx300(i) verwendet werden,
können auch in einer MX500(i) verwendet werden, und umgekehert.

Die RM400 hat eine MIPS CPU, je nach Variante eine R3000 (32Bit)
oder R4000 oder größer (64Bit).

Hast du nähre Infos zu den Maschinen-Varianten?
RM400-20, RM400-440, RM400-C20, oder RM400-E80?

MfG
Norbert Narten
e-Mail: norbert at narten punkt de

fritz chwolka

2018-01-29 22:19:22 UTC

Post by Norbert Narten
Moin,
Was für eine MX300 bekommst du? NSC oder Intel?
Weitere Infos kann ich ggf. liefern (Einstellanweisung, Speicherausbau,...),
wenn du etwas über die Baugruppen sagen kannst.
die Baugruppen-Sachnummern fangen z.B. mit S26361-... an.
Die MX500 ist auch was feines... (auch hier: NSC od. Intel?). Da
muss ich mein Gedächtnis mal befragen, was es so noch hergibt... :-).
Ich habe aber leider kein Installations-Band für die Maschine...
Einen Teil der Baugruppen, die in einer mx300(i) verwendet werden,
können auch in einer MX500(i) verwendet werden, und umgekehert.
Die RM400 hat eine MIPS CPU, je nach Variante eine R3000 (32Bit)
oder R4000 oder größer (64Bit).
Hast du nähre Infos zu den Maschinen-Varianten?
RM400-20, RM400-440, RM400-C20, oder RM400-E80?
MfG
Norbert Narten
e-Mail: norbert at narten punkt de

Hallo,
wie im Header steht sind es wohl Systeme mit intel CPU.
Ich werde aber diese erst in einigen Wochen in Augenschein nehmen können, bin aber für jede Information zu den Gerätetypen und dem Betriebssystem dankbar.

Marco Lorig

2018-02-01 17:13:57 UTC

Post by fritz chwolka
wie im Header steht sind es wohl Systeme mit intel CPU.
Ich werde aber diese erst in einigen Wochen in Augenschein nehmen können, bin aber für jede Information zu den Gerätetypen und dem Betriebssystem dankbar.

Die MX300i sind Intelmaschinen mit IIRC max 50MHZ (486DX50) und max 64MB
RAM (32MB auf dem CPU-Board +32MB auf einem Daughterboard) Ein Ethernet ist

Letzte mögliche SINIX Version ist 5.41

Die Installationsmedien bestehen aus 1 (können auch zwei gewesen sein)
3,5" Diskette und einem QIC Band. Beides habe ich IRGENDWO liegen,
allerdings das letzte mal vor mind. 13 Jahren benutzt. Es ist fraglich
ob ich es finde und in welchem Zustand sich die Medien befinden.

Das Standardterminal ist ein 97801. Es gibt auf der Rückseite nur einen
Port, an dem die Console angeschlossen werden kann, die restlichen sind
für normale Terminals und müssen erst aktiviert werden (post-boot).

Eine MX500i ist der große Bruder, kenne ich eigentlich nur als
eigenständiges Rack mit mehreren CPU Boards (ich glaube max 6 CPUs),
quasi die MP Version der MX300i. Eine sehr schöner Exot!

RM200/300/400 sind "normale" MIPS Maschinen, auf ihnen läuft SINIX-N
bzw. Reliant Unix bis zur Version 5.45 (kommt auf den Maschinentyp an)

ISOs dazu habe ich greifbar in Version 5.41, 5.43 und 5.45.

Die RM600 hat prinizipiell auch MIPS CPUs, allerdings eine gänzlich
andere Architektur als der Rest der RM-Reihe. Hier wird auch eine andere
Boot-CD fällig, IIRC SINIX Y.

Dann gibt das da noch den Super-Exot RM1000, das ist aber eigentlich
eine reine Pyramid-Maschine und meines Wissens nicht großartig verkauft
worden. Ich habe nur einmal eine um die Jahrtausendwende gesehen, im RZ
der Uni-Mannheim.

Die RM400 (-/C/E) gab es mit R3000 bis R12000 MIPS CPUs. Intel CPUs gab
es in der RM-Reihe nicht.

Halte uns mal auf dem Laufenden! Falls etwas übrig bleibt, hätte ich
vielleicht Interesse :)

Gruß Marco

Fritz Chwolka

2018-02-01 17:36:56 UTC

Post by Marco Lorig

Ich werde das Thema hier sicherlich noch etwas fortführen.

Apropo...
Ich kannte mal einen Marco aus (ich denke) Dortmund dem ich meine DEC PDP 11/73 (eventuell Vaxstation II, 3300) vermacht hatte. Ist bestimmt mindestens schon 12 Jahre her aber du wirst es wohl nicht sein.

Falls jemand mir was an Doku zum einscannen oder Datentraeger zukommen lassen möchte bitte ich freundlichst um eine e-mail.

Hier habe ich temporär eine kurze Übersicht der 5.25" Disketten die ich bekommen habe abgelegt. Die Disketten sind ok.

http://oldcomputers.dyndns.org/public/test/sinix_jpg.7z

Marco Lorig

2018-02-13 07:47:48 UTC

Post by Fritz Chwolka
Ich werde das Thema hier sicherlich noch etwas fortführen.
Apropo...
Ich kannte mal einen Marco aus (ich denke) Dortmund dem ich meine DEC PDP 11/73 (eventuell Vaxstation II, 3300) vermacht hatte. Ist bestimmt mindestens schon 12 Jahre her aber du wirst es wohl nicht sein.

Nein, das bin ich nicht aber ich glaube ich habe deine OS/2 Sammlung
geerbt (?).

Ich werde demnächst mal die RM CDs digitalisieren.

Gruß Marco

fritz chwolka

2018-02-13 10:11:03 UTC

Post by Marco Lorig

Nein, das bin ich nicht aber ich glaube ich habe deine OS/2 Sammlung
geerbt (?).
Ich werde demnächst mal die RM CDs digitalisieren.
Gruß Marco

OS/2 huch! Schön wenn es noch vorhanden ist. Zurückblickend hätte ich manches nicht abgegeben.

Danke für deine RM CDs in Voraus, ich hoffe das funktioniert.

MfG.

fritz

Hermann Riemann

2018-02-13 12:10:29 UTC

Post by fritz chwolka
OS/2 huch! Schön wenn es noch vorhanden ist.

OS halbe, o Graus.

Wenn ich in die Vergangenheit reisen könnte und mir
nur einen Rat geben könnte, wäre es:

Überspringe OS/2. Noch besser:
Nach Atari ST nur Linux.

Hermann
der mit Linux zwar auch immer wieder unangenehme Erfahrungen macht
( z.B. mit Installationen )
aber wenn es funktioniert, ist es brauchbar.

--
http://www.hermann-riemann.de

Josef Moellers

2018-02-08 15:45:28 UTC

Post by Marco Lorig
Die RM600 hat prinizipiell auch MIPS CPUs, allerdings eine gänzlich
andere Architektur als der Rest der RM-Reihe. Hier wird auch eine andere
Boot-CD fällig, IIRC SINIX Y.

Sie ist das selbe, nur was anderes ...

Wie ich schon schrub, hat die RM600 auch eine RISC (Reduced Instructions
Set Computer) CPU (oder mehrere), die ist aber *vollständig* anders als
die MIPS Rx000! Die RM600 war eine Entwicklung der Fa. Pyramid Computer
im Silicon Valley (Sunnyvale?), das Nixdorf damals eingekauft hat, weil
das fehlertolerante System 8832 nicht fertig wurde.

Post by Marco Lorig
Dann gibt das da noch den Super-Exot RM1000, das ist aber eigentlich
eine reine Pyramid-Maschine und meines Wissens nicht großartig verkauft
worden. Ich habe nur einmal eine um die Jahrtausendwende gesehen, im RZ
der Uni-Mannheim.

Stimmt, das war eher eine Technologiestudie als ein ausgereiftes Produkt.

Post by Marco Lorig
Die RM400 (-/C/E) gab es mit R3000 bis R12000 MIPS CPUs. Intel CPUs gab
es in der RM-Reihe nicht.

Nei, da *R*M = RISC!

Josef, bei den RM[24]00 dabei, die RM300 wurde in Vianen (NL) entwickelt.

Marco Lorig

2018-02-13 07:53:54 UTC

Mich wundert nus eins: Bei unseren Behörden standen tonnenweise
RM3/4/600 rum, ich habe allerdings in den letzten Jahren kaum Geräte auf
Ebay gesehen. Alle verschrottet oder gibt es da noch ein 2nd Life
irgendwo auf der Welt. Russland? Ich meine da mal ein paar Beiträge
einer russischen Usergroup im Netz gefunden zuhaben.

Grüße Marco

Hanno Foest

2018-02-13 08:36:35 UTC

Post by Marco Lorig
Mich wundert nus eins: Bei unseren Behörden standen tonnenweise
RM3/4/600 rum, ich habe allerdings in den letzten Jahren kaum Geräte auf
Ebay gesehen. Alle verschrottet oder gibt es da noch ein 2nd Life
irgendwo auf der Welt.

Bei Behörden (Bürokratie!) geht oft nichts außer gegen
Entsorgungsnachweis, den nur Entsorgungsunternehmen liefern können, die
sich wiederum verpflichten, alles zu schreddern, damit keine Daten von
den Platten etc. abhandenkommen. So wurde mir das jedenfalls mal erklärt.

Es gibt sicher im Einzelfall Mittel und Wege, aber "unter der Hand" geht
da wenig, weil es formal auf Diebstahl rausliefe, und die meisten Leute
hängen schon irgendwie an ihrem Job.

Man möge mich korrigieren...

Hanno

Christian Potzinger

2018-02-13 09:23:18 UTC

Post by Hanno Foest
Bei Behörden (Bürokratie!) geht oft nichts außer gegen
Entsorgungsnachweis, den nur Entsorgungsunternehmen
liefern können, die sich wiederum verpflichten, alles
zu schreddern, damit keine Daten von den Platten etc.
abhandenkommen. So wurde mir das jedenfalls mal erklärt.
Es gibt sicher im Einzelfall Mittel und Wege, aber "unter
der Hand" geht da wenig, weil es formal auf Diebstahl
rausliefe, und die meisten Leute hängen schon irgendwie
an ihrem Job.
Man möge mich korrigieren...

Ich mag nicht... Vor 4 Jahren habe ich eine Bank demoliert (1).
Ein Techniker hatte, unter anderen, bei ca. 20 PCs (die alle
1A funktionierten) die Card-Reader und die Festplatten ausgebaut.
Auf meiner Frage, ob ich einen oder zwei haben könnte hat er mir
genau dasselbe erklärt. Aber mit dem Hinweis, dass die über Nacht
in einem unbewachten Müllcontainer stehen...

In diesem Fall war es so, dass die PCs auf keinen Fall weiter-
gegeben werden durften. Aber sie wurden an kein Entsorgungs-
unternehmen weitergegeben sondern /nur/ per Müllcontainer
entsorgt. Ich weiss ja nicht, wie das bei Banken gehandhabt
wird/werden muss...

(1) Im Zuge einer Renovierung ;)

--
ryl: G'Kar

Hermann Riemann

2018-02-13 12:16:13 UTC

Post by Christian Potzinger
Ein Techniker hatte, unter anderen, bei ca. 20 PCs (die alle
1A funktionierten) die Card-Reader und die Festplatten ausgebaut.
Auf meiner Frage, ob ich einen oder zwei haben könnte hat er mir
genau dasselbe erklärt. Aber mit dem Hinweis, dass die über Nacht
in einem unbewachten Müllcontainer stehen...
In diesem Fall war es so, dass die PCs auf keinen Fall weiter-
gegeben werden durften. Aber sie wurden an kein Entsorgungs-
unternehmen weitergegeben sondern /nur/ per Müllcontainer
entsorgt. Ich weiss ja nicht, wie das bei Banken gehandhabt
wird/werden muss...

Wegen juristischem Kopierschutz im BIOS?

Hermann
der vermutet, dass sich nicht alle Personen
in Afrika daran halten.
https://www.golem.de/news/behind-the-screen-fuenfjaehrige-kinder-zerlegen-elektronikschrott-in-ghana-1204-91437.html

--
http://www.hermann-riemann.de

Christian Potzinger

2018-02-13 12:28:17 UTC

Post by Christian Potzinger
In diesem Fall war es so, dass die PCs auf keinen Fall weiter-
gegeben werden durften. Aber sie wurden an kein Entsorgungs-
unternehmen weitergegeben sondern /nur/ per Müllcontainer
entsorgt. Ich weiss ja nicht, wie das bei Banken gehandhabt
wird/werden muss...

Wegen juristischem Kopierschutz im BIOS?

Die hatten nicht mal ein Passwort für das BIOS.
Vielleicht hat der Techniker die auch nur entfernt
weil jemand (ich) nach diesen PCs gefragt hatte..?

--
ryl: G'Kar

Michael Kraemer @ home

2018-02-15 09:56:25 UTC

Post by Hanno Foest
Bei Behörden (Bürokratie!) geht oft nichts außer gegen
Entsorgungsnachweis, den nur Entsorgungsunternehmen liefern können, die
sich wiederum verpflichten, alles zu schreddern, damit keine Daten von
den Platten etc. abhandenkommen. So wurde mir das jedenfalls mal erklärt.
Es gibt sicher im Einzelfall Mittel und Wege, aber "unter der Hand" geht
da wenig, weil es formal auf Diebstahl rausliefe, und die meisten Leute
hängen schon irgendwie an ihrem Job.
Man möge mich korrigieren...

wie so oft: kommt drauf an.
Das Datenschutzproblem koennte man auch durch Ausbauen und Schreddern
der Platten loesen.

Vielleicht ist es auch einfach so, dass die Letztbenutzer ein Interesse
daran haben muessen, den alten Kram zu retten.
Vielleicht ist diese Mentalitaet bei Behoerden weniger stark ausgepraegt
als zB in Academia.
Zumal man klobige Server schlecht irgendwo zwischenparken kann,
bis sich vielleicht mal ein Interessent findet. Das duerfte bei
Plattformen mit starkem Workstation-Segment etwas einfacher sein.

Markus Elsken

2018-02-15 14:49:07 UTC

Moin!

Post by Michael Kraemer @ home
Zumal man klobige Server schlecht irgendwo zwischenparken kann,

Ich kenne hier an der Uni etliche Räume (teils bis ca. vierfache
Klassenraumgrösse), die mit Altmaterial vollgestellt sind. Und wenn man
die richtigen Leute kennt ist es auch kein Problem, sich da etwas
aussuchen zu dürfen...

mfg Markus

Martin Ebert

2018-02-15 20:36:49 UTC

Post by Hanno Foest

Post by Marco Lorig
Mich wundert nus eins: Bei unseren Behörden standen tonnenweise
RM3/4/600 rum, ich habe allerdings in den letzten Jahren kaum
Geräte auf Ebay gesehen. Alle verschrottet oder gibt es da noch ein
2nd Life irgendwo auf der Welt.

So ist es.

Genauer: Es gab eine Zeit, da war die Behördenwelt wohlsortiert:
Die einen IBM, die anderen Siemens - gern da, wo deren Standorte
waren. Die MX500 war in Kommunalverwaltungen bis Kreisver-
waltungen gut beheimatet. Und nicht eben billig.

Schon damals achtete der behördliche Datenschützer penibel auf
einige Dinge. Für Entsorgung kamen und kommen nur zertifizierte
Entsorger in Betracht, keine Zweitverwendung.

Wurde schon gesagt, dass die genannten Maschinen die Besonder-
heit der zwei Welten haben? Sinix und Unix, umschaltbar über
Shell.

Mt

Guido Grohmann

2018-02-15 21:21:15 UTC

Post by Martin Ebert
Wurde schon gesagt, dass die genannten Maschinen die Besonder-
heit der zwei Welten haben? Sinix und Unix, umschaltbar über
Shell.

DAS Unix gabs nicht, was war denn das für eine Umschaltung?

Guido

Norbert Narten

2018-02-15 22:11:05 UTC

Die MX300 (NSC) hatten drei Universen:

* sie für das Siemens Universum (System III basiert)
* ucb für BSD (4.x Basiert?)
* att für AT&T SVR3

Die MX300i dagegen war ein reinrassiges System V R4 (Letzte Version: 5.41D20).
Es gab zwar Kompatibilitäts-Pakete, aber keine Umschaltung mehr.

--
Norbert Narten

e-Mail: norbert at narten punkt de

Juergen Nickelsen

2018-03-02 11:27:20 UTC

Post by Martin Ebert
Wurde schon gesagt, dass die genannten Maschinen die Besonder-
heit der zwei Welten haben? Sinix und Unix, umschaltbar über
Shell.

So ein Umschalten war zu Zeiten der "offenen Systeme" (80er/90er)
recht üblich. Ich habe das mindestens bei Control Datas EP/IX (BSD,
System V) und Apollo gesehen (Domain OS, BSD, System V) gesehen. Ich
glaube aber, auch bei anderen, an die ich mich nicht mehr konkret
erinnere.

--
There are 10^11 stars in the galaxy. That used to be a huge number.
But it's only a hundred billion. It's less than the national
deficit! We used to call them astronomical numbers. Now we should
call them economical numbers. -- Richard P. Feynman

Hanno Foest

2018-03-02 12:56:34 UTC

Post by Juergen Nickelsen

Post by Martin Ebert
Wurde schon gesagt, dass die genannten Maschinen die Besonder-
heit der zwei Welten haben? Sinix und Unix, umschaltbar über
Shell.

Was passierte da beim Umschalten eigentlich technisch?

Hanno

Juergen Nickelsen

2018-03-06 14:01:36 UTC

[...]

Post by Hanno Foest

Post by Juergen Nickelsen
So ein Umschalten war zu Zeiten der "offenen Systeme" (80er/90er)
recht üblich. Ich habe das mindestens bei Control Datas EP/IX (BSD,
System V) und Apollo gesehen (Domain OS, BSD, System V) gesehen. Ich
glaube aber, auch bei anderen, an die ich mich nicht mehr konkret
erinnere.

Was passierte da beim Umschalten eigentlich technisch?

Am schönsten ging das bei Apollos Domain OS -- da gabe es Symlinks
mit Auflösung abhängig von Environment-Variablen. Da stand dann
etwas in dieser Art in / :

lrwxrwxrwx 1 system system 14 Mar 16 1987 bin -> $(SYSTYPE)/bin
lrwxrwxrwx 1 system system 14 Mar 14 1987 lib -> $(SYSTYPE)/lib
[etc.]

Je nach Wert der Environment-Variablen (zum Beispiel "bsd43" oder
"sysv32") war /bin/ dann tatsächlich /bsd43/bin/ oder /sysv32/bin/.
Wenn man versuchte, sich auf dem System zurechtzufinden und die
möglichen Werte der Environment-Variablen nicht kannte, war das
natürlich maximal unübersichtlich, aber wenn doch, eigentlich ganz
schön.

Für Domain OS selbst brauchte es diese Symlinks nicht, denn da waren
die Pfadnamen ohnehin ganz andere (zum Beispiel /COM statt /bin,
glaube ich). Der Kernel hat dann "einfach" Domain-OS- und Unix-ABIs
gleichzeitig implementiert.

(Das ist jetzt aus vager Erinnerung rekonstruiert, die Details mögen
anders gewesen sein.)

Bei Unixen mit Persönlichkeitsumschaltung ging das wohl nur allein
Environment-Variablen, weil es dieses hübsche Mittel der variablen
Symlinks nicht gab. Mit PATH etc. lässt sich dann einiges machen.

--
The more I use C, the more I like Ada.
-- Mark Atwood

fritz chwolka

2018-03-06 15:30:12 UTC

[...]

Aus der README Diskette:
http://oldcomputers.dyndns.org/public/pub/rechner/siemens/mx-rm/readmefiles.zip

2.2 Software-Konfiguration

Mit der Installation von SINIX Version 5.22 stehen auf Ih-
rem System drei Ablauf-Umgebungen zur Verfuegung:

Kommandos in der att-Ablaufumgebung:
Das att-Universum bietet Ihnen eine zu X/OPEN Portability
Guide III kompatible Ablaufumgebung. Dies ist weitgehend
die Programmierumgebung nach der "UNIX System V Interface
Definition" (UNIX ist ein eingetragenes Warenzeichen von
AT&T).

Kommandos in der sie-Ablaufumgebung:
Dies ist die SINIX V2.1-Umgebung.
Vorsicht: Die sie-Ablaufumgebung enthaelt keine Entwick-
lungsumgebung mehr und muss separat von der bei-
liegenden Magnetbandkassette SIE2.1 installiert
werden!

Kommandos zur Systemadministration:
Die Systemverwalterkommandos sind systemspezifisch und un-
terscheiden sich z.T. von denen anderer SINIX-Versionen.
Alle System5 Verwalterkommandos finden Sie im Systemver-
walterhandbuch beschrieben. Meldungen dieser Kommandos
werden in englischer Sprache ausgegeben.

Alle weiteren Kommandos oder Systemdateien, die weder im
Systemverwalterhandbuch beschrieben sind noch zu den Kom-
mandos des sie- bzw. att-Universums gehoeren, sind als Zu-
satz zum SINIX V5.22 Betriebssystem zu betrachten, fuer den
keine Wartung uebernommen wird.

Das C-Entwicklungssystem fuer das att-Universum ist in die
Liefereinheit SINIX Version 5.22 integriert. Das C-Ent-
wicklungssystem der SINIX V2.1 (sie-Universum) entfaellt.
Durch Einsatz des Softwareprodukts DFS werden verteilte
Dateisysteme unterstuetzt. DFS erfordert den Einsatz eines
neuen SCED-Boards. Genaue Information hierueber erhalten
Sie bei Ihrer zustaendigen Vertriebsgesellschaft.

SINIX V5.22 unterstuetzt in Verbindung mit dem Softwarepro-
dukt COLLAGE Grafik auf Grafik- und Alpha-Bildschirmen.
Das COLLAGE-Laufzeitsystem ist Bestandteil der SINIX
V5.22.

Juergen Nickelsen

2018-02-13 16:20:51 UTC

Post by Marco Lorig
Eine MX500i ist der große Bruder, kenne ich eigentlich nur als
eigenständiges Rack mit mehreren CPU Boards (ich glaube max 6 CPUs),
quasi die MP Version der MX300i. Eine sehr schöner Exot!

Uh-huh. Ob mit oder ohne i, Unido (als Unido noch Unido war) hatte
so eine irgendwann mal als News-Server neu. Aber nicht lange, denn
die Maschine hatte eine unschöne Angewohntheit. So ein News-Server
hat natürlich ganz viele Filedeskriptoren offen, und wenn die Last
mal hoch war, schrieb die Maschine in *irgendwelche* davon.

Sicher kein Problem der Hardware, aber wenn ich mich recht entsinne,
wurde sie recht bald wieder abgelöst. (Schrieb einer der Betreiber
mal irgendwo hier in der Nachbarschaft.)

--
In computer science, we stand on each other's feet.
-- Brian K. Reid

Martin Peters

2018-01-30 01:42:52 UTC

fritzchwolka schrieb:
(...)

Post by fritzchwolka
ich könnte obige Teile bekommen, ohne Disketten und Bänder. Zustand unbekannt.
Hat hier jemand Informationen dazu und die notwendigen Disketten um das System neu aufzusetzen?
System Sinix / Reliant Unix

Wir haben auch noch eine MX300 im Lager des Museums stehen, die gerne
wieder in Betrieb genommen wuerde. Leider fehlt uns noch ein passendes
Terminal, etwa das T100 VM20. Ein Pegelwandler von SS97 zu V.24 steht
aus diesem Grund auch schon seit bald vier Jahren auf der Todo-Liste,
aber mit sehr niedriger Prio.

Wenn ich mich recht erinnere, gab es nur acht SS97-Schnittstellen an dem
Rechner und dass das Low-Level-Aufzeichnungsformat der ESDI-Platte mit
dem eines PC-Controllers uebereinstimmt, erachteten wir als eher
unwahrscheinlich.

Holm Tiffe

2018-01-30 06:00:56 UTC

Post by Martin Peters
(...)

IMHO hießen die Terminals 97801. Ich habe Anfang der 90er mit den Mühlen
ab und an mal zu tun gehabt.

Gruß,
Holm

Holm Tiffe

2018-01-30 06:01:57 UTC

Post by fritzchwolka
Hallo,
ich könnte obige Teile bekommen, ohne Disketten und Bänder. Zustand unbekannt.
Hat hier jemand Informationen dazu und die notwendigen Disketten um das System neu aufzusetzen?
System Sinix / Reliant Unix
MfG
Fritz

Ich habe im Lager einen Karton mit Bändern stehen, da ist entweder
irgendwelcher Nixdorf oder Siemens Kram (oder Beides :-) ) drin, ich muß
nachschauen was das genau ist.

Gruß,

Holm

fritz chwolka

2018-01-30 23:25:12 UTC

Post by Holm Tiffe

Ich habe im Lager einen Karton mit Bändern stehen, da ist entweder
irgendwelcher Nixdorf oder Siemens Kram (oder Beides :-) ) drin, ich muß
nachschauen was das genau ist.
Gruß,
Holm

Wäre nett wenn du das machst. Ich habe auch noch einen Bekannten mit MX-300 NSC dem Bänder zu Systeminstallation fehlen.

Josef Moellers

2018-01-30 08:25:40 UTC

Wimre waren die RM200/300/400 ausschließlich mit MIPS R3k- und
R4k-Prozessren bestückt, das "R" in "RM" steht für RISC.Und die MXen gab
es wohl als MX...i und MX...n.

Josef

PS Es gab mal die Idee, die Workstations "WX" zu nennen und dann ein "R"
für MIPS-basierte und ein "I" für Intel/CISC-basierte. Der Name hat sich
aus verständlichen Gründen nicht durchgesetzt ... "WXR-200" ;-)

Norbert Narten

2018-01-30 19:23:08 UTC

Es war nicht nur eine Idee die Workstation "WX" zu nennen, es gab sie auch.
ich habe hier 2 WX200 stehen. Eine Prototypen-Maschine, eine reguläre WX200.
Beide sind im großen und ganzen recht ähnlich ausgestattet:

Gehäuse: WX200 Tower (sieht der RM400-20 mit MIPS R3000 vom her Gehäuse ähnlich)
Prozessor: i486 Slot-CPU
Speicher: 8MB (Maschine 1) / 32MB (Maschine 2) 30 Pin-SIMM
Grafik: ET4000 Huckepack auf der CPU-Karte
SCSI: Adaptec 1540
Disketten-LW: 3 1/2"
Magnetband: Tandberg 3660 SCSI
OS: Sinix-Z 5.42

Im Unixforum (http://www.unixforum.net/index.php?topic=2438.0)
ist ein Link zu einer WX200 zu sehen: Loading Image...

--
Norbert Narten

e-Mail: norbert at narten punkt de

Michael Kraemer @ home

2018-01-31 08:05:11 UTC

Post by Norbert Narten
Es war nicht nur eine Idee die Workstation "WX" zu nennen, es gab sie auch.
ich habe hier 2 WX200 stehen. Eine Prototypen-Maschine, eine reguläre WX200.

Ich habe eine RM-200 rumstehen.
Das waere dann eigentlich eine WXR-200?

Norbert Narten

2018-01-31 15:49:19 UTC

Post by Michael Kraemer @ home
Ich habe eine RM-200 rumstehen.
Das waere dann eigentlich eine WXR-200?

Nein, eine RM200 ist eine RM200. Sie gibt es nur im Desktop Gehäuse,
und im 19"-Gehäuse. Die ersten RM400 mit MIPS R3000 hatten einen
ähnlichen Tower wie die WX200.

--
Norbert Narten
e-Mail: norbert at narten punkt de

Josef Moellers

2018-02-01 07:18:48 UTC

Post by Michael Kraemer @ home
Ich habe eine RM-200 rumstehen.
Das waere dann eigentlich eine WXR-200?

Nein, eine RM200 ist eine RM200. Sie gibt es nur im Desktop Gehäuse,
und im 19"-Gehäuse. Die ersten RM400 mit MIPS R3000 hatten einen

Hach ja ... die MIPS R3k/R4k mit dem Delay-Slot. Das hat mich mal zu
folgendem Gedanken hinreißen lassen, kein Scherz (damals waren unsere
Kinder noch klein):
Wenn ich einem Kind sage, es soll etwas sein lassen und es tut das doch,
dann war die Tat im Delay-Slot!

Josef

PS Für die Nicht-MIPS-Kenner:
https://de.wikipedia.org/wiki/Branch_Delay_Slot

Hermann Riemann

2018-01-31 07:54:01 UTC

Post by fritzchwolka
ich könnte obige Teile bekommen, ohne Disketten und Bänder. Zustand unbekannt.

Was willst Du damit.

Ich hatte auch mal eine MX300? Kiste.
Disketten und Bänder habe ich nicht gebraucht.
Darauf war ein K&R C ( nicht mal ANSI )
Ich hatte vor damit den NS320XX code zu programmieren
https://de.wikipedia.org/wiki/NS320xx
weil mir der Befehlssatz gefiel.

Ich habe damit nur wenig herumprobiert.
Und das Riesen Ding,
dessen Schnittstellen zu anderen Rechner unhandlich waren,
irgendwann zum Wertstoffhof entsorgt.

Hermann
der etliche verschiedene CPUs, Betriebssysteme
und Programmiersprachen nie praktisch eingesetzt hat.

--
http://www.hermann-riemann.de

Michael Kraemer @ home

2018-01-31 08:03:28 UTC

Post by fritzchwolka
ich könnte obige Teile bekommen, ohne Disketten und Bänder. Zustand unbekannt.

Was willst Du damit.

diese Frage ist hier unzulaessig.
geradezu ketzerisch.

Hermann Riemann

2018-01-31 10:07:17 UTC

Post by Michael Kraemer @ home

Post by Hermann Riemann
Was willst Du damit.

diese Frage ist hier unzulaessig.

Wo ist hier der TÜV, bzw. die hierzu gehörende Regel?

Post by Michael Kraemer @ home
geradezu ketzerisch.

Dann bin ich halt (auch hier) ein Ketzer.

Hermann
der des öfteren mit Gewohnheiten bricht.
( siehe mein_* Bilder über meiner homepage)

--
http://www.hermann-riemann.de

Josef Moellers

2018-02-01 07:19:33 UTC

Post by Michael Kraemer @ home

Post by Hermann Riemann
Was willst Du damit.

diese Frage ist hier unzulaessig.

Wo ist hier der TÜV, bzw. die hierzu gehörende Regel?

Ich glaube nicht, daß das ernst gemeint war.

Josef

fritz chwolka

2018-01-31 08:52:10 UTC

Post by fritzchwolka
ich könnte obige Teile bekommen, ohne Disketten und Bänder. Zustand unbekannt.

Was willst Du damit.
Hermann
der etliche verschiedene CPUs, Betriebssysteme
und Programmiersprachen nie praktisch eingesetzt hat.

Spielen, was Sonst ? ;-)

Hermann Riemann

2018-01-31 10:03:56 UTC

Post by Hermann Riemann
Was willst Du damit.

Spielen, was Sonst ? ;-)

Für die MX* gibt es ein Spiel namens enterprise
( irgendwas mit Eierbecher) und das Spiel Wurm.

Hermann
der die Spiel auf MX* mal gespielt hat,
sie aber nicht besorgt hat.

--
http://www.hermann-riemann.de

fritz chwolka

2018-01-31 10:19:19 UTC

Post by Hermann Riemann
Was willst Du damit.

Spielen, was Sonst ? ;-)

Für die MX* gibt es ein Spiel namens enterprise
( irgendwas mit Eierbecher) und das Spiel Wurm.
Hermann
der die Spiel auf MX* mal gespielt hat,
sie aber nicht besorgt hat.

Na da ist ja schon mal was, für mich ist aber der Umgang mit der alten Hard.- und Software schon Spielfreude genug.

Fritz
der auch eine aufgeblasene Honda Monkey bewegt wenn die Sonne scheint.

Hermann Riemann

2018-01-31 15:45:05 UTC

Post by Hermann Riemann
der die Spiel auf MX* mal gespielt hat,
sie aber nicht besorgt hat.

Na da ist ja schon mal was,
für mich ist aber der Umgang mit der alten Hard.-
und Software schon Spielfreude genug.

Für mach war das schönste Erlebnis als ich die Regelsysteme von
"Grenzen des Wachstums" auf einer Siemens 2002 noch weiter fortsetzte.

Bei alter hardware zum theoretischen Spielen
denke ich an computer mit TTL 74XX Bauteile
( ich codiere da zeitweise Ablaufsteuerung in Python3)

und zum direkten Basteln eher an Z80, 6502, 68*.
Mal später sehen wie sich das mit Raspi und Arduino verträgt.
Zumindest ist diese alte hardware
( Platinensysteme meist mit selbst hex codierden EPROMs )
von malware kaum erreichbar.

Post by fritz chwolka
Fritz
der auch eine aufgeblasene Honda Monkey bewegt wenn die Sonne scheint.

Hermann
der eigentlich seinen Garten pflegen müsste:
Loading Image...

statt mit hardware Probleme ..
Loading Image...

--
http://www.hermann-riemann.de

Norbert Narten

2018-01-31 16:18:36 UTC

Post by Hermann Riemann
Für die MX* gibt es ein Spiel namens enterprise
( irgendwas mit Eierbecher) und das Spiel Wurm.

Das sind keine Eierbecher... ;-) ... das sind Sanduhr-Symbole...
Die Spiele habe ich auch im C-Source. Sie waren im Ursprung für den PC-X
geschrieben unter Sinix 1.0 / 1.2. aber mit ein paar kleinen Änderungen
ließen sie sich auf die mx300i portieren. Wenn ich einen passenden C-Compiler
für meine RMs (CDS++ V2.00C) mal bekommen sollte, werde ich die Spiele auch
mal auf eine RM[2346]00 compilieren... :-)

Außerdem gibt es eine Tetris-Variante (TETRIX) vom Stefan Bion für die mx300.
Tetrix läuft sowohl auf der Text-Konsole (Grafik-Karte) als auch auf einem
seriellen Terminal (TC20 & 97801) mit 38400 Bit/s unter Sinix-Z 5.42. Das Spiel
macht echt Spaß auf dem Terminal...

Er hat mir Tetrix im Quellcode überlassen. Ich muss ihn mal fragen, ob ich
die Dateien weiter geben darf...

--
Norbert Narten

e-Mail: norbert at narten punkt de

Josef Moellers

2018-02-01 07:23:43 UTC

Post by Hermann Riemann
Für die MX* gibt es ein Spiel namens enterprise
( irgendwas mit Eierbecher) und das Spiel Wurm.

Achtung: die RM600 war/ist NICHT mit RM[234]00 kompatibel!
Die RM600 war eine Pyramid-Maschine mit "Kuchenblechen" und proprietärer
Pyramid-CPU (fast diskret aus TTL-ICs aufgebaut) während die RM[234]00
mit MIPS-R[34]000 aufgebaut waren. Zwar auch RISC, aber eben ... anders.

Josef

Norbert Narten

2018-02-01 16:53:19 UTC

Post by Josef Moellers
Achtung: die RM600 war/ist NICHT mit RM[234]00 kompatibel!
Die RM600 war eine Pyramid-Maschine mit "Kuchenblechen" und proprietärer
Pyramid-CPU (fast diskret aus TTL-ICs aufgebaut) während die RM[234]00
mit MIPS-R[34]000 aufgebaut waren. Zwar auch RISC, aber eben ... anders.
Josef

Achtung???

Nein, eben nicht... Die RM600 (z.B. RM600-420) unterscheidet sich darin, das
sie Multibus II, und die anderen Maschinen ISA (z.B. RM400-05), EISA und PCI-Bus
haben. Spätere RM600 der E-Variante haben auch den PCI-Bus und MIPS R10000-CPUs.
Auf Prozessor-Ebene verwenden alle den MIPS-Prozessor. Selbst die RM1000 hat schon
MIPS-CPUs, von der es heißt, das Pyramid bei ihr schon am entwickeln war, als
Siemens Pyramid übernommen hat.

Ich vermute, das du da ein paar Maschinen miteinander verwechselst, die das gleiche
Gehäuse hatten, oder die RM600 damit mal ursprünglich geplant war, aber so nie
gebaut wurde.

Hier noch ein Zitat aus dem Handbuch der RM600-E-Reihe,
RM600 E (Reliant UNIX) / U25044-J-Z816-5,
Seite 23:

"3.2 Central Processing Unit (CPU) und
Bussysteme
Basis des Systems RM600 E sind – je nach Aufbau – ein oder mehrere RISC-
Mikroprozessoren mit folgenden Eigenschaften:
– Prozessor R10000
– Taktfrequenz 200 MHz bzw. 250 MHz
– integrierter Gleitkommaprozessor (Co-Prozessor)
– zweimal 32 Kbyte Primär-Cache und 4/8 Mbyte Sekundär-Cache
Maximal können 24 CPUs betrieben werden.
Der Hauptspeicher ist in NUMA-Architektur (N..."

--
Norbert Narten

e-Mail: norbert at narten punkt de

Josef Moellers

2018-02-08 15:53:36 UTC

Siemens hat Pyramid nicht übernommen, so weit ich weiß.

Post by Norbert Narten
Ich vermute, das du da ein paar Maschinen miteinander verwechselst, die das gleiche
Gehäuse hatten, oder die RM600 damit mal ursprünglich geplant war, aber so nie
gebaut wurde.

Ich gebe zu, es ist ein paar Jährchen her ...

Post by Norbert Narten
Hier noch ein Zitat aus dem Handbuch der RM600-E-Reihe,
RM600 E (Reliant UNIX) / U25044-J-Z816-5,
"3.2 Central Processing Unit (CPU) und
Bussysteme
Basis des Systems RM600 E sind – je nach Aufbau – ein oder mehrere RISC-
– Prozessor R10000
– Taktfrequenz 200 MHz bzw. 250 MHz
– integrierter Gleitkommaprozessor (Co-Prozessor)
– zweimal 32 Kbyte Primär-Cache und 4/8 Mbyte Sekundär-Cache
Maximal können 24 CPUs betrieben werden.
Der Hauptspeicher ist in NUMA-Architektur (N..."

Mag jetzt sein, daß die "E" tatsächlich was anderes war als die anderen
RM600.

Definitiv hatten die ersten RM600 eine Pyramid-eigene RISC-Architektur
u.a. mit Register-Windows, d.h. es gab ein Fenster mit 2x8(16?)
Registern: 8(16?) für die Parameter und 8(16?) für die lokalen
Variablen. Bei einem Funktionsaufruf wurde das Fenster dann um 8(16?)
nach unten verschoben und die lokalen Variablen wurden zu den Parametern
für die nächste Funktion. Die MIPS-Prozessoren hatten dagegen feste
Register, die gerettet werden mußten, u.a. war eines als
Rücksprungadresse vorgesehen, so daß beim Eintritt in eine Funktion, die
keine weitere Funktion aufrief, dieses Register auch nicht gerettet
werden mußte, sondern der Rücksprung einfach als "b (ra)" (den Opcode
sehe ich irgendwo hinter einem grauen Schleier) realisiert wurde.

Ich bin mir auch nicht sicher, ob die Pyramids das Delay-Slot der
MIPS-CPUen hatten.

Josef

Norbert Narten

2018-02-08 23:27:48 UTC

Oder meinst du die Targon /35? Die hatte ich einmal gesehen, und ein Kollege
sagte mir, da würde Pyramid-Technik drin stecken. Sie hatte ein mit der RM600
zu verwechselndes Gehäuse. Ich könnte mir gut vorstellen, das die Targon /35
der Entwicklungsstechnische Vorläufer war. Die RM-Reihe könnte der logische
Nachfolger der Targon-Reihe sein, so wie sie auf jeden Fall die Nachfolgerin
der MX-Reihe ist. Zusammenfassen von Rechner-Systemen, die die gleiche Zielgruppe
hat. Die RM1000 soll auch Pyramid-Anleihen haben, aber die Prozessoren der
RM1000 waren definitiv MIPS-CPUs. Das war 1991. Da bin ich gerade nach ende
der Lehre bei Siemens zu Siemens-Nixdorf gekommen.

Ich habe gerade mal ein wenig die Suchmaschine bemüht. Siemens-Nixdorf hat 1995
Pyramid Technology ganz übernommen. Nixdorf hat die Targon /35 wohl von Pyramid
Technology ab 1985 bauen lassen, wenn ich die Suchergebnisse richtig deute...

--
Norbert Narten

e-Mail: norbert at narten punkt de

Josef Moellers

2018-02-09 10:51:27 UTC

Oder meinst du die Targon /35? Die hatte ich einmal gesehen, und ein Kollege

Jetzt wo Du's sagst/schreibst ... Die Maschine war ja, wie ich schon
schrub, als Ersatz für die Targon/32 (aka 8832) eingeführt.

Post by Norbert Narten
sagte mir, da würde Pyramid-Technik drin stecken. Sie hatte ein mit der RM600
zu verwechselndes Gehäuse. Ich könnte mir gut vorstellen, das die Targon /35
der Entwicklungsstechnische Vorläufer war. Die RM-Reihe könnte der logische
Nachfolger der Targon-Reihe sein, so wie sie auf jeden Fall die Nachfolgerin
der MX-Reihe ist. Zusammenfassen von Rechner-Systemen, die die gleiche Zielgruppe
hat. Die RM1000 soll auch Pyramid-Anleihen haben, aber die Prozessoren der
RM1000 waren definitiv MIPS-CPUs. Das war 1991. Da bin ich gerade nach ende
der Lehre bei Siemens zu Siemens-Nixdorf gekommen.

Stimmt, die RM1000 war irgendwas ... anderes, und wimre eben nicht viel
mehr als eine Art Technologiestudie.

Post by Norbert Narten
Ich habe gerade mal ein wenig die Suchmaschine bemüht. Siemens-Nixdorf hat 1995
Pyramid Technology ganz übernommen.

Hm, dran kann ich mich jetzt gar nicht erinnern :-(

Post by Norbert Narten
Nixdorf hat die Targon /35 wohl von Pyramid
Technology ab 1985 bauen lassen, wenn ich die Suchergebnisse richtig deute...

Das pikante daran war, daß die /32 von einem amerikanischen Startup
entwickelt worden war (Anfangs hießen die Parallel Computer Systems,
nach irgendeiner großen Messe, wo eine andere PCS massive Problem hatte,
umbenannt in "Auragen" (*)). Das ursprüngliche Design sah "Kuchenbleche"
vor, das war aber ein absolutes Nogo bei Nixdorf, also mußten die Boards
durchgeschnitten und als Doppel-Boards in zwei Einschübe, mit allen
dazugehörigen Problemen. Als sich die Entwicklung hinzog (auch die SW
war nicht ohne (**)), entschied man sich, den Kunden statt dessen erst
mal einen /35 hinzustellen, die ... Tara! ... Kuchenbleche hatte!

Jetzt, wo ich weiter 'drüber nachdenke, gab's eben auch die Targon/31,
DIE wurde in Vianen(NL) entwickelt. Ob die Jungs dann auch an den RMs
beteiligt waren, kann ich mich gerade nicht 'dran erinnern.

Josef

(*) Ein Kollege schwafelte mal am Telefon davon, daß es was mit "Aura"
und "generieren" zu tun habe, dabei war es einfach nur das Wort
"origin", etwas kreativ geschrieben ;-)

(**) Die Hardware war Multi-Prozessor-Multi-Computer: Mehere Nodes über
zwei parallele Busse verbunden, jeder Node hatte zwei Message
Prozessoren für die Inter-Computer-Kommunikation, einen oder mehrere
Application Prozessoren und einen oder mehrere Communication
Prozessoren. Die Software basierte auf dem Prinzip, daß der aktuelle
Zustand eines Prozesses genau von einem vorherigen Zustand UND den
eingehenden Daten abhängt und war message-basiert: Jeder Prozess hatte
einen (passiven) Backup-Prozess auf einem anderen Node und jede
Kommunikation eines Prozesses wurde als Message ausgetauscht und wurde
beim Backup ge-queue-t. Ab und an wurde der Backup auf den Zustand des
Primaries gebracht und die Queue gelöscht.

Juergen Nickelsen

2018-03-01 15:38:02 UTC

Post by Josef Moellers
Jetzt, wo ich weiter 'drüber nachdenke, gab's eben auch die Targon/31,
DIE wurde in Vianen(NL) entwickelt. Ob die Jungs dann auch an den RMs
beteiligt waren, kann ich mich gerade nicht 'dran erinnern.

Die Targon/31 war nach meiner Erfahrung der Grund für das Retronym
"Tausend Anwender Rufen Gemeinsam 'Oh Nixdorf!'".

Das TCP/IP-Zeugs war auf der Maschine zu Zeiten (1988 oder '89) noch
sehr buggy. Wenn man sich per Telnet einloggte, hatte man kein
vernünftiges Environment. Der Telnetd räumte beim Logout die
Prozesse nicht ordentlich ab, so dass nach einer bestimmte Zahl von
Telnet-Logins die Maschine zu war. Reboot half. :-(

Emacs hab ich noch drauf zum Laufen bekommen, gcc nicht. Die
mitgelieferten Compiler (ein cc und ein m20cc oder so) verschluckten
sich jeweils an *verschiedenen* Teilen der teilweise recht
umfangreichen Makros im gcc-Sourcecode. Aber selbst wenn das kein
Problem gewesen wäre, hätte man vermutlich einiges am Backend machen
müssen, um passenden Output zu erzeugen.

Bei Nixdorf in Paderborn sollte es jemand gegeben haben, der gcc zum
Laufen gebracht hatte, aber es gelang mir damals nicht, Kontakt zu
dem aufzunehmen. Sooo wichtig war's aber auch nicht.

--
There is hardly anything in the world that someone cannot make a
little worse and sell a little cheaper, and the people who consider
price alone are that person's lawful prey. -- John Ruskin

Josef Moellers

2018-03-02 11:04:42 UTC

Post by Juergen Nickelsen

Hehe, das erinnert mich an den schönsten Fehler, den ich mal bearbeiten
durfte:
Die RM400 wurde immer langsamer, bis sie irgendann stehen blieb. Reboot
... OK ... langsamer ... stehenbleiben.
Die Analyse des Kernel-Cores zeigte, daß der ganze Speicher voll mit
Datenstrukturen mit dem selben Layout war. Eine Suche durch die
.h-Dateien (so viele waren's damals nich nicht ;-) ) ergab, daß es
Strukturen waren, die irgendwelche Netzwerk-Verbindungen (VPN?) beschrieben.
Ich habe den Kollegen in München angerufen und der meinte, das könne ja
gar nicht sein, die würden nach einiger Zeit aufgeräumt und überhaupt
sei der Source-Code identisch(!) mit dem von Solaris (IIRC) und dort
trat das Problem nicht auf.
Also ... weiter analysiert. Den Quellcode des Moduls hatten wir in
Paderborn nicht, also ... Modul disassemblieren und gucken. Ja,
tatsächlich: da gab es eine Funktion, die diese Datenstrukturen wieder
frei gab. Und ... NEIN! diese Funktion wurde nirgends aufgerufen!
Wieder in München angerufen ... wieder die Antwort: das können nicht
sein und überhaupt ...
Nach eine Viertelstunde rief der Kollege zurück: Hmm, ja, peinlich: um
den Aufruf diese Funktion stand ... "# ifndef SINIX_N" :-)
<VBG>

Post by Juergen Nickelsen
Emacs hab ich noch drauf zum Laufen bekommen, gcc nicht. Die
mitgelieferten Compiler (ein cc und ein m20cc oder so) verschluckten
sich jeweils an *verschiedenen* Teilen der teilweise recht
umfangreichen Makros im gcc-Sourcecode. Aber selbst wenn das kein
Problem gewesen wäre, hätte man vermutlich einiges am Backend machen
müssen, um passenden Output zu erzeugen.
Bei Nixdorf in Paderborn sollte es jemand gegeben haben, der gcc zum
Laufen gebracht hatte, aber es gelang mir damals nicht, Kontakt zu
dem aufzunehmen. Sooo wichtig war's aber auch nicht.

Ich war's nicht. Aber damals hatten wir noch mehr Kollegen, die was
anderes konnten als Excel. Nunja, Geschichte: Heute gibt's nicht mal die
mehr.

Josef, heute grüne Chamäleons fütternd

Josef

Juergen Nickelsen

2018-03-06 13:47:42 UTC

Post by Josef Moellers

Post by Juergen Nickelsen
Bei Nixdorf in Paderborn sollte es jemand gegeben haben, der gcc zum
Laufen gebracht hatte, aber es gelang mir damals nicht, Kontakt zu
dem aufzunehmen. Sooo wichtig war's aber auch nicht.

Ich war's nicht. Aber damals hatten wir noch mehr Kollegen, die was
anderes konnten als Excel. Nunja, Geschichte: Heute gibt's nicht mal die
mehr.

Irgendjemand mit Vornamen Michael vielleicht... meine Emails aus den
Zeiten habe ich leider nicht gerettet.

--
Any program will, given enough time, grow large enough to be able to
send mail. Except Microsoft Exchange.

Hermann Riemann

2018-03-03 05:47:36 UTC

Emacs hab ich noch drauf zum Laufen bekommen.

Auf den Sinix Kisten gab es doch das gute Maxed.

Hermann
der das auf den NS Kisten benutzen durfte.

--
http://www.hermann-riemann.de

Josef Moellers

2018-05-08 12:27:29 UTC

Post by Josef Moellers
Definitiv hatten die ersten RM600 eine Pyramid-eigene RISC-Architektur
u.a. mit Register-Windows, d.h. es gab ein Fenster mit 2x8(16?)
Registern: 8(16?) für die Parameter und 8(16?) für die lokalen
Variablen. Bei einem Funktionsaufruf wurde das Fenster dann um 8(16?)
nach unten verschoben und die lokalen Variablen wurden zu den Parametern
für die nächste Funktion.

Nur der Vollständigkeit halber, weil ich mich gerade durch meine Ordner
mit Kopien scan-ne und 'drüber gestolpert bin:

Es gab
* 16 globale Register gr0..gr15
* 16 Parameter-Register pr0..pr15
* 16 lokale Register lr0..lr15 und
* 16 temporäre Register tr0..tr15
Die letzten drei Gruppen waren eben als "sliding window" organisiert:
+----------+
| |
: prx :
| |
+----------+
| |
: lrx :
| |
+----------+ +----------+
| | | |
: trx : : prx :
| | | |
+----------+ +----------+
| |
: lrx :
| |
+----------+
| |
: trx :
| |
+----------+
D.h. die Funktionsargumente wurden, soweit möglich, in tr0... abgelegt
und durch den Funktionsaufruf automagisch zu pr0...

das PSW wurde bei einem Funktionsaufruf nach pr14 gerettet,
der PC nach PR15.

Post by Josef Moellers
Ich bin mir auch nicht sicher, ob die Pyramids das Delay-Slot der
MIPS-CPUen hatten.

Davon sehe ich nichts, gehe also davon aus, daß die Pyramid-Systeme das
nicht hatten.

Josef

Martin Peters

2018-02-02 00:02:46 UTC

Post by Hermann Riemann
Was willst Du damit.

Spielen, was Sonst ? ;-)

Für die MX* gibt es ein Spiel namens enterprise
( irgendwas mit Eierbecher) und das Spiel Wurm.

Da gibt's doch dieses riesige Textadventure, das praktisch auf jedes
UNIX portiert wurde. Ich glaube es hiess /bin/sh

:p

Hermann Riemann

2018-02-02 12:06:28 UTC

Post by Martin Peters
Da gibt's doch dieses riesige Textadventure, das praktisch auf jedes
UNIX portiert wurde. Ich glaube es hiess /bin/sh

Eine Variante von su rm -r / ?

Hermann
der von Vertipper der Art
rm * ~
statt
rm *~
nicht begeistert ist.

--
http://www.hermann-riemann.de

Gerrit Heitsch

2018-02-02 15:24:46 UTC

Post by Martin Peters
Da gibt's doch dieses riesige Textadventure, das praktisch auf jedes
UNIX portiert wurde. Ich glaube es hiess /bin/sh

Eine Variante von su rm -r /   ?
Hermann
   der von Vertipper der Art
   rm * ~
   statt
   rm *~
   nicht begeistert ist.

Auch gemein ist es wenn man

crontab -r

statt

crontab -e

tippt und es erst nach dem <ENTER> merkt.

Gerrit

Hermann Riemann

2018-02-02 16:57:15 UTC

Post by Gerrit Heitsch
Auch gemein ist es wenn man
crontab -r
statt
crontab -e
tippt und es erst nach dem <ENTER> merkt.

e und r liegen auf der Tastatur ja passend nebeneinander.

Ich habe noch nie crontab verwendet.
Ich habe eben
crontab -e eingegeben.
Anscheinend bin ich im vi mit der Datei /tmp/crontab.kz7uaa
gelandet.
Da /tmp bei mir auf tmpfs liegt,
habe ich danach bei jedem Herunterfahren automatisch ein
crontab -r

Wenn ich crontab lernen würde,
gäbe es dies vielleicht wegen Systemd nicht mehr.

Hermann
der eher an eigene Programme
mit time und sleep Aufrufe denkt.

--
http://www.hermann-riemann.de

Gerrit Heitsch

2018-02-02 17:05:10 UTC

Post by Gerrit Heitsch
Auch gemein ist es wenn man
crontab -r
statt
crontab -e
tippt und es erst nach dem <ENTER> merkt.

Nein, hast du nicht. crontab -e erzeugt eine temporäre Datei in /tmp,
die editierst und wenn du den editor verlässt wird die Datei an den
richtigen Ort kopiert und dem crond Bescheid gesagt, daß sich was
geändert hat.

crontab -r hingegen löscht einfach die echte crontab.

Post by Hermann Riemann
Wenn ich crontab lernen würde,
gäbe es dies vielleicht wegen Systemd nicht mehr.

Es zwingt dich keiner den Unsinn der systemd-Timer zu verwenden, einen
crond kann man sich immer noch installieren.

Gerrit

Bernd Laengerich

2018-02-02 19:29:20 UTC

Post by Gerrit Heitsch
Auch gemein ist es wenn man
crontab -r

:)

Mein Ex-Chef hat uns seinerzeit[TM] immer eingetrichtert, niemals als
root zu arbeiten, immer nur wenn nötig einzelne Kommandos privilegiert...
Und dann hat er auf der Leihstellungs-Apollo rm -rf /* statt .*
ausgeführt. Latürnich als root. Er tippte dann eine Zeitlang auf dem
-aktuell ja noch laufenden, aber ohne ein einziges ausführbares Kommando
relativ wertlose- System herum, grybelte und meinte dann zu mir, ob mir
dazu noch etwas einfiele. Ich habe dann gefragt, ob das unter uns
bleiben soll. Er stockte kurz und hob dann mit breitem Grinsen an, es
lautstark dem Rest zu verkünden :-D Danach holte er die Bänder aus dem
Safe...

Bernd

Gerrit Heitsch

2018-02-02 21:08:49 UTC

Post by Bernd Laengerich

Post by Gerrit Heitsch
Auch gemein ist es wenn man
crontab -r

rm -rf .* kann, je nach Alter des Unix, auch schwer ins Auge gehen weil
eben .* auch zu .. expandiert. Damit ist dann das Directory über dem
aktuellen und alle darunter auch weg. Mach das in einem Directory bei
dem 'cd ..' äquivalent zu 'cd /' ist und das System ist tot.

Gerrit

Hermann Riemann

2018-02-03 09:04:45 UTC

Post by Gerrit Heitsch
rm -rf .* kann, je nach Alter des Unix, auch schwer ins Auge gehen weil
eben .* auch zu .. expandiert. Damit ist dann das Directory über dem
aktuellen und alle darunter auch weg. Mach das in einem Directory bei
dem 'cd ..' äquivalent zu 'cd /' ist und das System ist tot.

Wenn cd .. auf $HOME führt, und $HOME keine persönlich hinzugefügte
Dateien enthält, ist das nicht so tragisch.

Hermann
der einige Zeit gut mit gelöschtem $HOME weitergemacht hat.

--
http://www.hermann-riemann.de

Josef Moellers

2018-02-08 15:57:09 UTC

Post by Martin Peters
Da gibt's doch dieses riesige Textadventure, das praktisch auf jedes
UNIX portiert wurde. Ich glaube es hiess /bin/sh

Eine Variante von su rm -r /   ?
Hermann
   der von Vertipper der Art
   rm * ~
   statt
   rm *~
   nicht begeistert ist.

Schön auch folgender:

Auf einer amerikanischen Tastataur liegt der Stern ja über der "8" und
das Größerzeichen über dem Punkt.
Wenn man jetzt bei "rm *.o" die "Shift"-Taste nicht schnell genug los
ließ, hatte man hinter nur noch eine leere Datei "o" ;-)

Josef

Juergen Nickelsen

2018-02-13 16:27:02 UTC

Post by Hermann Riemann
Was willst Du damit.

Spielen, was Sonst ? ;-)

Für die MX* gibt es ein Spiel namens enterprise
( irgendwas mit Eierbecher) und das Spiel Wurm.

Ich hab auch mal ein Hack (noch vor Nethack) auf einer MX-2 mit
Sinix 2.1 zum Laufen gebracht. War nur begrenzt schwierig. Auf
neueren System sollte das wohl eher einfacher sein.

--
Var49052=Füllen Sie bitte oben FTP-Tor

Michael Kraemer @ home

2018-01-31 08:09:11 UTC

Ich habe einen Stapel CDs wo u.a. draufsteht:

Reliant UNIX 5.4? RM200, RM300, RM400-xx, -xxx, -Cxx

Keine Ahnung ob das passt. Die RM400 ist mW normal Mips.
Ich weiss auch nicht, ob man dafuer License Keys oder so braucht.
Habe meine RM200 noch nicht ausprobiert.

Norbert Narten

2018-01-31 16:27:32 UTC

Post by Michael Kraemer @ home
Keine Ahnung ob das passt. Die RM400 ist mW normal Mips.
Ich weiss auch nicht, ob man dafuer License Keys oder so braucht.
Habe meine RM200 noch nicht ausprobiert.

RMs laufen alle mit MIPS-Prozessoren.
Einen License Key brauchst du nur dann, wenn du mehrere Benutzer ( > 2 )
über Terminal (Serielle Schnittstelle) und der physischen Grafik-Konsole
gleichzeitig anmelden möchtest. Über Telnet / SSH ist mir bislang keine
Beschränkung aufgefallen.

--
Norbert Narten

e-Mail: norbert at narten punkt de

Holm Tiffe

2018-01-31 21:05:29 UTC

Post by Michael Kraemer @ home
Keine Ahnung ob das passt. Die RM400 ist mW normal Mips.
Ich weiss auch nicht, ob man dafuer License Keys oder so braucht.
Habe meine RM200 noch nicht ausprobiert.

.... :-)

Es gibt ne Kernelvariable die man zur Laufzeit im Hauptspeicher patchen
kann, die findet man schon anhand des namens des Symbols.

Es wäre nicht das erste SVR4 das ich auf diese weise "entnervt" gehabt
hätte..

Gruß,

Holm

Josef Moellers

2018-02-01 07:30:45 UTC

Post by Holm Tiffe

Post by Michael Kraemer @ home
Keine Ahnung ob das passt. Die RM400 ist mW normal Mips.
Ich weiss auch nicht, ob man dafuer License Keys oder so braucht.
Habe meine RM200 noch nicht ausprobiert.

.... :-)
Es gibt ne Kernelvariable die man zur Laufzeit im Hauptspeicher patchen
kann, die findet man schon anhand des namens des Symbols.

Ich habe hier noch irgendwo eine "Torch Tripe X" stehen, ein ehemaliges
Evaluations-System. Als ich da ein serielles Terminal angeschlossen
hatte, wunderte ich mich, daß ich mich zwar einloggen konnte und im "vi"
zwar etwas ge-echo-t bekam, im Normalfall (shell, ...) aber nix sah. Ich
habe dann mal Kontakt mit Torch (in der Abwicklung :-( ) aufgenommen und
man sagte mir, ich habe da wohl eine Einzelbenutzer-Lizenz, da sei das
echo auf der seriellen Leitung abgeschaltet. Es ht nur eine kurze Suche
mit dem "adb" gedauert und ich hatte die Stelle im "stty" gefunden, wo
das ECHO-Bit ausgeknipst wurde.
Flink in ein rc-Startup-Skript ein "adb" auf /dev/mem mit entsprechenden
Kommandos eingebaut und ... Echo-cho-cho-cho!

Josef

Josef Moellers

2018-02-01 07:24:38 UTC

Post by Michael Kraemer @ home

Post by fritzchwolka
Hallo,
ich könnte obige Teile bekommen, ohne Disketten und Bänder. Zustand unbekannt.
Hat hier jemand Informationen dazu und die notwendigen Disketten um
das System neu aufzusetzen?
System Sinix / Reliant Unix

Reliant UNIX 5.4? RM200, RM300, RM400-xx, -xxx, -Cxx
Keine Ahnung ob das passt. Die RM400 ist mW normal Mips.

RM[234]00 sind MIPS, RM600 ist andere RISC-Architektur.

Josef

Norbert Narten

2018-02-01 17:14:13 UTC

Post by Josef Moellers
RM[234]00 sind MIPS, RM600 ist andere RISC-Architektur.
Josef

Die RM600 hat MIPS-CPUs, siehe vorheriges Posting von mir...

--
Norbert

e-Mail: norbert at narten punkt de

fritz chwolka

2018-02-01 08:28:06 UTC

Bei den ganzen Beiträgen bin ich nun wirklich neugierig was ich da bekommen kann.
Leider finde ich zur Hardware keine näheren Information bzw. Dokumentationen.
Teilinhalt aus einer README MX300/500 (NSC) einer gerade zum Image eingelesenen 5.25" Floppydisk:

#####################################################################

UNIVERSE=ucb
PRODUCT="README"
VERSION="V5.22"
RELEASE="21.05.1990"

#################
## Readme Text - hier habe ich die Seitennummrrn und Leerzeilen entfernt damit
## der Text im Editor besser zu lesen ist.
## Da ich die Datei aus einem Floppyimage erstellt habe sind eventuelle
## Fehler bei der haendischen Konvertierung möglich.
#################

1 Allgemeines

Hiermit wird das Betriebssystem SINIX V5.22 fuer den MX500
freigegeben.
SINIX V5.22 ist auf allen Modellen des MX500 ablauffaehig.

Die Freigabemitteilung gibt eine gedraengte Zusammenstel-
lung aller wesentlichen Informationen zur vorliegenden
Version 5.22 von SINIX. Mit SINIX V5.22 ist die Kompatibi-
litaet zum X/OPEN Portability Guide III erreicht.

Der Inhalt dieser Freigabemitteilung entspricht dem Frei-
gabestant
Es stehen folgende Software-Liefereinheiten zur Verfuegung:

SINIX-UP-F1 Update von V5.21 auf V5.22 (1-16 Benutzer)
SINIX-UP-F3 Update von V5.21 auf V5.22 (1-32 Benutzer)
SINIX-UP-F5 Update von V5.21 auf V5.22 (1-64 Benutzer)
SINIX-F1 SINIX-Basissystem V5.22 (1-16 Benutzer)
SINIX-F2 SINIX-Hochruestsatz fuer 17 bis 32 Benutzer
SINIX-F3 SINIX-Basissystem V5.22 (1-32 Benutzer)
SINIX-F4 SINIX-Hochruestsatz fuer 33 bis 64 Benutzer
SINIX

SINIX-Basissystem V5.22 (1-64 Benutzer)
SINIX-F6 SINIX-Hochruestsatz fuer 65 bis 128 Benutzer
SINIX-F7 SINIX-Basissystem V5.22 (1-128 Benutzer)

Zusaetzlich zur gewuenschten Software-Liefereinheit muss ein
Dokumentationspaket bestellt werden. Die Auflistung der
verfuegbaren Liefereinheiten und der darin enthaltenen Ma-
nuale finden Sie im Kapitel 1.3.

1.1 Bestellung

SINIX Version 5.22 kann ueber Ihre zustaendige Vertriebsge-
sellschaft be†zogen werden.

Es muss die Softwareliefereinheit plus Dokumentationspaket
bestellt werden.

Es gelten die allgemeinen Bedingungen zum Vertrag ueber die
Nutzung und Betreuung von Softwareprodukten.

Die Liefereinheit ist ein Lizenzprodukt. Die Lizenznummer
wird durch Installation der Diskette K.DISK (KEY-Diskette)
ins System uebernommen. Dieses Produkt darf nur auf dem Ge-
raet eingesetzt werden, fuer das es gekauft wurde.

1.2 Auslieferung

Das Betriebssystem SINIX Version 5.22 wird auf 3 Magnet-
bandkassetten (SINIX3, SINIX5 und SIE2.1) plus KEY-Disket-
te (K.DISK) ausgeliefert. Bei Update-Versionen entfaellt
die KEY-Diskette, da sie von der Vorgaengerversion ûebernom-
men werden kann.

Lieferumfang:

Kassetten SINIX3/SINIX5:
System V Environment (X/OPEN Umgebung von SINIX V5.22)
CES Environment (C-Entwicklungs-System V5.22)
COLLAGE (COLLAGE-Laufzeitsystem V3.0)
COLFACE (COLLAGE-Bediensystem)
Games (Spiele mit englischer Oberflaeche)
SDT (System-Development-Toolkit)

Kassette SIE2.1:
SINIX 2.1 Environment (SINIX V2.1 Umgebung von SINIX V5.22)

1.3 Dokumentation

Zur Installation und zum Betrieb von SINIX V5.22 ist das
Dokumentationspaket erforderlich.

Es stehen zwei Liefereinheiten zur Verfuegung:

SINIX-DOC-D V5.22 deutsche Dokumentation
SINIX-DOC-GB V5.22 englische Dokumentation

Folgende Manuale gehoeren zum Lieferumfang des Dokumenta-
tionspakets:

Bestellnummer

Betriebsanleitung MX500 U5006-J-Z95-2
SINIX Systemverwaltung V5.22 U3904-J-Z95-4
SINIX V5.22 Kommandos, Teil 1 U5453-J1-Z95-2
SINIX V5.22 Kommandos, Teil 2 U5454-J1-Z95-2
SINIX V5.22 Kommandos, Teil 3 U5455-J1-Z95-2
C-Entwicklungssystem, Teil 1 U3899-J-Z95-3
C-Entwicklungssystem, Teil 2 U3900-J-Z95-3
SINIX-SPOOL Benutzerhandbuch U5650-J-Z95-1
COLLAGE Bediensystem Benutzerhandbuch U5995-J-Z95-1
inkl. Kurzbeschreibung U6007-J-Z95-1
COLLAGE Bedienen, Verwalten, Programmieren U3004-J-Z95-4
Nachtrag zu COLLAGE Bedienen U3004-J1-Z95-5
SINIX-Systemsicherheit U5069-J-Z95-1
SINIX Buch1 U3201-J-Z95-1
SINIX Buch2 U3202-J-Z95-1
Nachtrag zu SINIX Buch2 U3202-J1-Z95-2

Das Kapitel Systemverwaltung im SINIX Buch2 ist nicht mehr
gueltig; es wurde ersetzt durch das Kapitel Bediensystem im
Systemverwalterhandbuch!
Fuer den Einsatz von Peripherie-Geraeten sind die entspre-
chenden Hardware-Manuale erforderlich.

2 Technische Hinweise

Auf SINIX Version 5.22 koennen unter Beachtung bestimmter
Einschraenkungen die auf anderen SINIX-Versionen erstellten
Programme im Binaerformat portiert werden (vgl. 2.6).

Neue und erweiterte Software-Funktionen werden im Kapitel
3 dargestellt.

2.1 Hardwareausbau

MX500-75:

Minimalausbau:
- Konsol- und Diagnoseprozessor (SC¦ED)
- Dualprozessor mit 2 x CPU NS32532 mit integrierter MMU,
einschliesslich FPU und 64 KByte Cache pro Prozessor
- 1 Multibus
- 1 Speichercontroller mit 16 MB
- 5 1/4 Zoll Diskettenlaufwerk mit Steuerung
- 5 1/4 Zoll Magntbandkassettenlaufwerk mit Steuerung,
Kapazitaet 155 MB
- 1 Festplatte 5 1/4 Zoll, Kapazitaet 380 MB oder 760 MB
- 1 E/A-Prozessor oder
- 1 serieller Inhouse-Multiplexer (SIM)

Erweiterungen:
- bis zu 5 Festplatten 5 1/4 Zoll, Kapazitaet 760 MB
- bis zu 3 Dualprozessoren
- 1 Speichercontroller mit 16 MB
- bis zu 2 Speichererweiterungen mit je 16 MB
- ein zusaetzlicher Multibus
- bis zu 7 E/A-Prozessoren oder
- bis zu 7 serielle Inhouse-Multiplexer (SIM)
- bis zu 5 ladbare DFUe-Prozessoren
- 1 Magnetbandgeraet 1/2 Zoll
- 1 Magnetbandkassettenlaufwerk Video-8, Kapazitaet 2,3 GB
- 1 Ethernet-Anschluss fuer TCP/IP Protokolle
- bis zu 2 Ethernet-Prozessoren fuer ISO Protokolle
- AFP-Anschlusszusaetze fuer maximal 44 Anschluesse ueber AFP
- 1 Erweiterungsschrank mit 1 Multibus zum Einbau von
- bis zu 6 Festplatten 5 1/4 Zoll, Kapazitaet 760 MB
- bis zu 8 E/A-Prozessoren oder
- bis zu 8 seriellen Inhouse-Multiplexern (SIM)
- bis zu 4 DFUe-Prozessoren
- 1 Ethernet-Prozessor fuer ISO Protokolle
- AFP-Anschlusszusaetzen fuer max. 48 Anschluesse ueber AFP
- zusaetzlichen Peripherie-Steuerungen

Vorsicht: Nicht alle Erweiterungen sind gleichzeitig ein-
setzbar!

Hauptspeicherbedarf von SINIX V5.22:

Der Hauptspeicherbedarf des Betriebssystems SINIX V5.22
ist abhaengig vom Hauptspeicherausbau und laesst sich berech-
nen aus der Differenz der Groessen real mem minus avail mem,
die beim Hochfahren des Systems ausgegeben werden.

2.2 Software-Konfiguration

Mit der Installation von SINIX Version 5.22 stehen auf Ih-
rem System drei Ablauf-Umgebungen zur Verfuegung:

Kommandos in der att-Ablaufumgebung:
Das att-Universum bietet Ihnen eine zu X/OPEN Portability
Guide III kompatible Ablaufumgebung. Dies ist weitgehend
die Programmierumgebung nach der "UNIX System V Interface
Definition" (UNIX ist ein eingetragenes Warenzeichen von
AT&T).

Kommandos in der sie-Ablaufumgebung:
Dies ist die SINIX V2.1-Umgebung.
Vorsicht: Die sie-Ablaufumgebung enthaelt keine Entwick-
lungsumgebung mehr und muss separat von der bei-
liegenden Magnetbandkassette SIE2.1 installiert
werden!

Kommandos zur Systemadministration:
Die Systemverwalterkommandos sind systemspezifisch und un-
terscheiden sich z.T. von denen anderer SINIX-Versionen.
Alle System5 Verwalterkommandos finden Sie im Systemver-
walterhandbuch beschrieben. Meldungen dieser Kommandos
werden in englischer Sprache ausgegeben.

Alle weiteren Kommandos oder Systemdateien, die weder im
Systemverwalterhandbuch beschrieben sind noch zu den Kom-
mandos des sie- bzw. att-Universums gehoeren, sind als Zu-
satz zum SINIX V5.22 Betriebssystem zu betrachten, fuer den
keine Wartung uebernommen wird.

Das C-Entwicklungssystem fuer das att-Universum ist in die
Liefereinheit SINIX Version 5.22 integriert. Das C-Ent-
wicklungssystem der SINIX V2.1 (sie-Universum) entfaellt.
Durch Einsatz des Softwareprodukts DFS werden verteilte
Dateisysteme unterstuetzt. DFS erfordert den Einsatz eines
neuen SCED-Boards. Genaue Information hierueber erhalten
Sie bei Ihrer zustaendigen Vertriebsgesellschaft.

SINIX V5.22 unterstuetzt in Verbindung mit dem Softwarepro-
dukt COLLAGE Grafik auf Grafik- und Alpha-Bildschirmen.
Das COLLAGE-Laufzeitsystem ist Bestandteil der SINIX
V5.22.

2.3 Produkt-Installation

2.3.1 Allgemeine Hinweise

SINIX V5.22 kann nur auf einer der ersten 8 Festplatten
installiert werden!
Prozessoren, mit denen Ihre MX500 ausgestattet ist. Fuer
die Prozessoren NS32532 verwenden Sie dann zur Installa-
tion von SINIX V5.22 das Band SINIX5. Fuer die Prozessoren
Saemtliche, die Konfiguration von Bildschirmen und Druckern
betreffenden Dateien duerfen nicht von aelteren SINIX-Ver-
sionen uebernommen werden, da sich die Verwaltung der kon-
figurierten Geraete grundlegend geaendert hat. Es muessen in
jedem Fall alle Geraete neu konfiguriert werden.

Die Dateien /etc/passwd und /etc/group duerfen ebenfalls
nicht von alten Sicherungsstaenden ueberschrieben werden,
Fall, dass alte Benutzerkennungen uebernommen werden sollen,
duerfen diese nur von Hand in die neue /etc/passwd kopiert
werden; analog muss bei den Gruppeneintraegen vorgegangen
werden. Aus Kompatibilitaetsgruenden werden auch noch die
Dateien login.dat und deauth.dat im Dateiverzeichnis
/usr/sie_root/usr/menus/app/develop und das Dateiverzeich-
nis /usr/admin/.benutzer gepflegt; diese Dateien mues
dann also von der vorherigen Installation uebernommen
werden.

Die Datei /etc/rc.local darf nicht von einer aelteren SI-
NIX-Version uebernommen werden, da sich deren Inhalt geaen-
dert hat.

Sie sollten den vom System benutzten usr-Bereich und den
von den Benutzerdaten belegten Bereich moeglichst auf ver-
schiedenen Dateisystemen auf getrennten Platten halten.
Ausserdem sollten root- und usr-Bereich auf getrennten
Platten liegen.
Die Groesse des gesamten Swap-Bereichs sollte zwischen 2 und
5 mal so gross gewaehlt werden wie die Groesse des Hauptspei-
chers. Die guenstigste Groesse des Swap-Bereichs ist die ca.
4-fache Groesse des Hauptspeichers.
Der Swap-Bereich, der zur Aufnahme des Hauptspeicherabzugs
im Falle eines Systemabsturzes benutzt wird, muss minde-
stens die Groesse des Hauptspeichers plus 4 MB haben. Fuer
den Fall, dass dies nicht moeglich ist, kann man das bsu-
Kommando dump mit entsprechenden Schaltern veranlassen,
einen Hauptspeicherabzug auf mehrere Geraete zu verteilen
(vgl. Systemverwalterhandbuch).

Wichtiger Hinweis zum Einrichten von Dateisystemen:
Standardmaessig wûird beim Einrichten eines Dateisystems
mittels /etc/newfs pro 2 KB ein Inode eingerichtet,
d.h., die maximale Anzahl der Inodes in einem Dateisystem
richtet sich nach der Groesse des Dateisystems. Das Problem
hierbei ist, dass der Systemkern in der sie-Ablaufumgebung
nur maximal 65535 Inodes pro Dateisystem verwalten kann,
die Anzahl der von /etc/newfs angelegten Inodes jedoch bei
Verwendung eines sehr grossen Plattenbereichs diesen Wert
uebersteigt. An dieser Stelle muss der Anwender selber dafuer
sorgen, dass es nicht zu Problemen kommt; dazu ist der
/etc/newfs mit dem Schalter -i aufzurufen, der angibt, fuer
wieviele KB jeweils ein Inode angelegt werden soll.

Beispiel:
/etc/newfs /dev/xp5c liefert u.a. :

549400 sectors in 820 cylinders of 10 tracks, 67 sectors
281.3Mb in 52 cyl groups (16 c/g, 5.49Mb/g, 2048 i/g)

Multipliziert man die Anzahl der Zylindergruppen mit der
Anzahl der Inodes pro Zylindergruppe, so erhaelt man die
Anzahl der angelegten Inodes (hier: 52 * 2048 = 106496).
Da dieser Wert zu gross ist (>65535), waehlt man dann z.B. 5
KB fuer einen Inode:

/etc/newfs -i 5120 /dev/xp5c

549400 sectors in 820 cylinders of 10 tracks, 67 sectors
281.3Mb in 52 cyl groups (16 c/g, 5.49Mb/g, 1024 i/g)

Jetzt liefert die Multiplikation 52 * 1024 = 53248; da
dieser Wert kleiner ist als 65535, wird die Anzahl der ma-
ximal moeglichen Inodes fuer den Kern im sie-Universum nicht
mehr ueberschritten.

#############################################################
Die README hat 9758 Zeilen weshalb ich hier abgebrochen habe.

fritz chwolka

2018-02-09 13:33:25 UTC

Ich möchte Euch daran erinnern das ich zu MX und RM alles an Informationen und Sonstiges suche.
Wenn Ihr also etwas übrig habt und abgeben wollt - eine kurze Mail an mich wäre nett.
Porto etc. übernehme natürlich ich.

MfG

Fritz

Fritz Chwolka

2018-11-05 11:37:18 UTC

Kurzer Zwischenstand:

Die MX-300/75i möchte noch nicht von da booten wo ich meine das sie booten sollte.

https://forum.classic-computing.de/forum/index.php?thread/14407-siemens-mx300-i-wiederinbetriebnahme/&postID=161885#post161885

Ich habe noch 2 x MX-300/45i (486-25) bekommen die auf Zuwendung warten.

1 x bleibt beim Initialisieren mit '0C' Index stehen
1 x initialisiert bis zum Monitor da keine HD angeschlossen war. HDs als ESDI Ausführung.

https://forum.classic-computing.de/forum/index.php?thread/14407-siemens-mx300-i-wiederinbetriebnahme/&postID=161928#post161928

Beide Maschinen werde ich über die Winterzeit dokumentieren. Es war keinerlei weiter Doku und Software dabei.

--
--

Fritz Chwolka

2018-11-12 12:07:07 UTC

Zwischenstand: es sind nicht 2 x MX300 Intel sondern 1 x intel 1 x National Semiconductor

Die MX-300-45 (intel) ist hardwareseitig in Ordnung, hat aber kein lauffähiges Sytem.

National Semiconductor:
http://oldcomputers-ddns.org/public/pub/rechner/siemens/mx-rm/mx300nsc/mx300-10/index.html

Die MX300-10N läuft und startet SINIX-H. Ich sehe ein schönes Loginbild auf der Console - leider habe ich keinen Logindaten.
Die MX300-10 hat leider eine ESDI Festplatte, da nützt mir jetzt der MFM Emulator nichts

(ich hoffe der Link funktioniert)
https://forum.classic-computing.de/forum/index.php?thread/15054-siemens-mx300-10-national-semiconductor-wiederinbetriebnahme/&postID=162783#post162783

Meine Überlegung wäre einen ESDI Kontroller in ein PC Board zu stecken und mir BSD, Linux, SCO oder was auch immer einen Abzug der ESDI Festplatte zu machen.
(ganz lose mal angedacht)

Post by Fritz Chwolka
Die MX-300/75i möchte noch nicht von da booten wo ich meine das sie booten sollte.
https://forum.classic-computing.de/forum/index.php?thread/14407-siemens-mx300-i-wiederinbetriebnahme/&postID=161885#post161885
Ich habe noch 2 x MX-300/45i (486-25) bekommen die auf Zuwendung warten.
1 x bleibt beim Initialisieren mit '0C' Index stehen
1 x initialisiert bis zum Monitor da keine HD angeschlossen war. HDs als ESDI Ausführung.
https://forum.classic-computing.de/forum/index.php?thread/14407-siemens-mx300-i-wiederinbetriebnahme/&postID=161928#post161928
Beide Maschinen werde ich über die Winterzeit dokumentieren. Es war keinerlei weiter Doku und Software dabei.

Gert Doering

2018-11-12 18:56:59 UTC