Hallo,

ich mal wieder ;)

hätte drei Fragen, die die Installation eines VMS-Systems betreffen:

1) Einrichtung eines Users mit allen Rechten zwecks Installation:

Von der offiziellen "VMS Hobbyist Program" Seite aus findet sich
ziemlich direkt die Seite von Phil Wherry, mit seiner Variante eines VMS
Installations-Kochbuchs:

http://www.wherry.com/gadgets/retrocomputing/vax-simh.html

Darin wird nach Installation des Grundsystems sobald wie möglich ein
User mit ALLEN Rechten angelegt. In folgenden Schritten der Installation
muß dann immer anstelle von SYSTEM dieser User ran. Gibt es für so eine
Vorgehensweise einen guten Grund? Ich verstehe es nicht so recht, finde
es einfacher, wenn man alles vom SYSTEM Account aus einrichtet.

2) Entpacken der Hilfe-Dateien:

Nachdem das VMS System eingerichtet ist, empfiehlt Phil folgende Sache:

I also recommend decompressing the system libraries for performance
reasons. Use the command:
$ *SYS$UPDATE:LIBDECOMP.COM

Da geht es offenbar um Hilfe-Dateien(?) die normalerweise "on the fly"
dekomprimiert würden, hier aber einmalig ausgepackt werden. Oder???
Kann bzw. sollte man diese Aktion später, z.B. nach Installation
weiterer Sprachen, wiederholen?

3) Speichersituation nach Installation von DECwindows auf der VAXstation
VLC:

Ich habe jetzt mal (ohne Anleitung) DECwindows auf meiner VAXstation VLC
eingerichtet. Bezüglich des PAGEFILEs gibt mir der negative Parameter zu
denken. Kann das eventuell jemand interpretieren bzw. kommentieren?

System Memory Resources on 4-AUG-2007 20:07:30.09

Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (24.00Mb) 49152 10437 36198
2517

Virtual I/O Cache Usage (pages): Total Free In Use Maximum
Cache Memory 6077 10 6067
28836

Slot Usage (slots): Total Free Resident Swapped
Process Entry Slots 70 47 23
0
Balance Set Slots 63 42 21
0

Dynamic Memory Usage (bytes): Total Free In Use Largest
Nonpaged Dynamic Memory 2028544 696896 1331648
602624
Paged Dynamic Memory 1145856 811712 334144
810592

Paging File Usage (pages): Free Reservable Total
DISK$MINISYS:[SYS0.SYSEXE]SWAPFILE.SYS 10496 10496
10496
DISK$MINISYS:[SYS0.SYSEXE]PAGEFILE.SYS 25671 -20442
30000

Of the physical pages in use, 12910 pages are permanently allocated to
OpenVMS.



Viele Grüße

Michael

In article <f92j2s$ncl$1*online.de>, Michael Berger <michaberger*online.de> writes:
>1) Einrichtung eines Users mit allen Rechten zwecks Installation:

Ich habe zwar meinem User alle Rechte (und Resourcen) gegeben,
trotzdem verwende ich *für Installationen* den SYSTEM User (und nur dann).

Falls Dir mal einer empfiehlt, den SYSTEM User aus Sicherheitsgründen
gleich zu disablen, laß Dir das genau erklären, wie er das meint (zB. DISUSER
wäre nämlich eine blöde Idee, weil ua. das VMS Startup unter SYSTEM ...)

>2) Entpacken der Hilfe-Dateien:

Es sind nicht nur HLB, sondern auch OLB dabei.
Und "on-the-fly" Auspacken muß dann jeder und eben immer wieder.
Wenn Du also Platz auf der Disk hast, dann gönn Dir das LIBDECOMP.

Ich weiß übrigens gar nicht, ob es Layered Products gibt, die ihre
Libraries (soferne sie welche mitbringen, das sind ja nur wenige) im
DCX compressed Format mitbringen (bzw. nach irgendwelchen Überlegungen
dann doch entkomprimieren). Ich glaube nicht...

btw. Auf I64 sind immer alle Libs entkomprimiert (also auch kein LIBDECOMP)

>3) Speichersituation nach Installation von DECwindows auf der VAXstation VLC:

Wenn Du Platz auf der Disk hast, dann erhöhe das Pagefile (kräftig).
Negativwerte heißt, daß die Applikationen mehr reserviert haben als da ist,
aber meist verwenden sie gar nicht so viel wie sie reservieren und das
System kann prima laufen, aber wenn die dann doch alle einmal mehr wollen,
wird der Pagefilespace schnell critical (und dann steht die Mühle)...

--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail peter*langstoeger.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

Peter 'EPLAN' LANGSTOeGER schrieb:

> Ich habe zwar meinem User alle Rechte (und Resourcen) gegeben,
> trotzdem verwende ich *für Installationen* den SYSTEM User (und nur dann).
>
> Falls Dir mal einer empfiehlt, den SYSTEM User aus Sicherheitsgründen
> gleich zu disablen, laß Dir das genau erklären, wie er das meint (zB. DISUSER
> wäre nämlich eine blöde Idee, weil ua. das VMS Startup unter SYSTEM ...)

Hab ich mir fast gedacht - hinter der Idee, SYSTEM möglichst garnicht zu
verwenden, steckt bestimmt eine ziemlich beeinflusste Schlußfolgerung
von Unix/Linux aus. Da gibt es ja neuerdings Distributionen, wo aus
gutem Grund Ruth gesperrt ist, und anstelle von Ruth jemand anders die
Geschäftsführung wahrnimmt.
Vermutlich ist so was unter VMS nicht nötig - schon allein aufgrund der
genial einfachen Idee, nach einem misslungenen Einlog-Versuch nicht
anzusagen, ob es am Namen oder am Passwort gescheitert ist...

Michael

Hallo Michael,

Michael Berger <michaberger*online.de> wrote:

> hätte drei Fragen, die die Installation eines VMS-Systems betreffen:
>
> 1) Einrichtung eines Users mit allen Rechten zwecks Installation:
>
> Von der offiziellen "VMS Hobbyist Program" Seite aus findet sich
> ziemlich direkt die Seite von Phil Wherry, mit seiner Variante eines
> VMS Installations-Kochbuchs:
>
> http://www.wherry.com/gadgets/retrocomputing/vax-simh.html
>
> Darin wird nach Installation des Grundsystems sobald wie möglich ein
> User mit ALLEN Rechten angelegt. In folgenden Schritten der
> Installation muß dann immer anstelle von SYSTEM dieser User ran. Gibt
> es für so eine Vorgehensweise einen guten Grund? Ich verstehe es nicht
> so recht, finde es einfacher, wenn man alles vom SYSTEM Account aus
> einrichtet.

Solang das dein Rechner ist und sonst niemand (administrativ) dran
werkelt, ist es relativ egal, ob du als SYSTEM oder als MICHAEL
arbeitest. In einer Firma mit mehreren Administratoren würde ich darauf
drängen, dass jeder von seinem eigenen Account arbeitet - schlicht und
einfach weil dann leichter nachvollziehbar ist, wer was gemacht hat. Wenn
fünf Leute das SYSTEM Passwort haben, ist das viel schwerer.

(Natürlich hat ein privilegierter Benutzer und Standard-Security-
Einstellungen jede Menge Möglichkeiten, seine Aktivitäten zu
verschleiern, aber von Böswilligkeit rede ich jetzt gar nicht).

> 2) Entpacken der Hilfe-Dateien:
>
> Nachdem das VMS System eingerichtet ist, empfiehlt Phil folgende Sache:
>
> I also recommend decompressing the system libraries for performance
> reasons. Use the command:
> $ *SYS$UPDATE:LIBDECOMP.COM
>
> Da geht es offenbar um Hilfe-Dateien(?) die normalerweise "on the fly"
> dekomprimiert würden, hier aber einmalig ausgepackt werden. Oder???
> Kann bzw. sollte man diese Aktion später, z.B. nach Installation
> weiterer Sprachen, wiederholen?

Wie Peter schon gesagt hat, geht es nicht nur um Help-Libraries, sondern
auch um Object- (und Macro-)Libraries. Gerade auf schwachbrüstigen
Rechnern ist es schon ein Vorteil, wenn diese Libraries nicht jedesmal
fliegend dekomprimiert werden müssen.

Wenn eine Library einmal dekomprimiert ist, werden auch neue Module
unkomprimiert eingefügt - eine Wiederholung dieser Aktion ist daher nicht
nötig.

> 3) Speichersituation nach Installation von DECwindows auf der
> VAXstation VLC:
>
> Ich habe jetzt mal (ohne Anleitung) DECwindows auf meiner VAXstation
> VLC eingerichtet. Bezüglich des PAGEFILEs gibt mir der negative
> Parameter zu denken. Kann das eventuell jemand interpretieren bzw.
> kommentieren?
>
> System Memory Resources on 4-AUG-2007 20:07:30.09
>
> Physical Memory Usage (pages): Total Free In Use
> Modified
> Main Memory (24.00Mb) 49152 10437 36198
> 2517
<schnipp>
> Paging File Usage (pages): Free Reservable
> Total
> DISK$MINISYS:[SYS0.SYSEXE]SWAPFILE.SYS 10496 10496
> 10496
> DISK$MINISYS:[SYS0.SYSEXE]PAGEFILE.SYS 25671 -20442
> 30000

Auch hier hat Peter schon alles gesagt.

Von 30000 Seiten im Pagefile sind noch mehr als 25000 frei, vom
physischen Memory rund 10000 (20% des vorhandenen Speichers). Die -20442
Seiten könnten *potentiell* von den derzeit aktiven Prozessen beansprucht
werden, wenn alle zugleich ihren Workingset maximal in den Pagefile
verschieben möchten, was recht unwahrscheinlich ist - außer du startest
noch einige zusätzliche speicherhungrige Programme oder die derzeit
aktiven beanspruchen dynamisch noch große Mengen Memory.

Aber wenn Platz auf der Platte ist, ist ein großes Pagefile nie ein
Fehler.

Hans.

In article <f92j2s$ncl$1*online.de>, Michael Berger
<michaberger*online.de> writes:

> Darin wird nach Installation des Grundsystems sobald wie möglich ein
> User mit ALLEN Rechten angelegt. In folgenden Schritten der Installation
> muß dann immer anstelle von SYSTEM dieser User ran. Gibt es für so eine
> Vorgehensweise einen guten Grund? Ich verstehe es nicht so recht, finde
> es einfacher, wenn man alles vom SYSTEM Account aus einrichtet.

Ich glaube nicht, dass es nötig ist.

Später, wenn alles läuft, lasse SYSTEM unverändert und richte einen
neuen USER ein, der defaultmäßig nur READONLY als Zusatz hat, aber auch
SETPRV.

> 2) Entpacken der Hilfe-Dateien:
>
> Nachdem das VMS System eingerichtet ist, empfiehlt Phil folgende Sache:
>
> I also recommend decompressing the system libraries for performance
> reasons. Use the command:
> $ *SYS$UPDATE:LIBDECOMP.COM
>
> Da geht es offenbar um Hilfe-Dateien(?) die normalerweise "on the fly"
> dekomprimiert würden, hier aber einmalig ausgepackt werden. Oder???
> Kann bzw. sollte man diese Aktion später, z.B. nach Installation
> weiterer Sprachen, wiederholen?

Kann man später machen. Heutzutage, mit billigem Plattenplatz, gibt es
keinen Grund, dies nicht zu machen.

> 3) Speichersituation nach Installation von DECwindows auf der VAXstation
> VLC:
>
> Ich habe jetzt mal (ohne Anleitung) DECwindows auf meiner VAXstation VLC
> eingerichtet. Bezüglich des PAGEFILEs gibt mir der negative Parameter zu
> denken. Kann das eventuell jemand interpretieren bzw. kommentieren?

Suche in den Archiven von comp.os.vms. Es ist wie eine Bank, die nicht
genug Geld hat, wenn alle Leute ihr Guthaben auf einmal auszahlen lassen
wollen---ist aber nicht schlimm, weil dies sehr unwahrscheinlich ist.

Phillip Helbig:

> Suche in den Archiven von comp.os.vms. Es ist wie eine Bank, die nicht
> genug Geld hat, wenn alle Leute ihr Guthaben auf einmal auszahlen lassen
> wollen---ist aber nicht schlimm, weil dies sehr unwahrscheinlich ist.

Das ist der beste Vergleich, den ich bisher darüber gehört habe.

Tatsächlich gibt der "Reservable"-Wert an, wieviele Blocks im jeweiligen
Pagefile noch frei bleiben würden, wenn alle Prozesse, die diesen Pagefile
benützen, alle beschreibbaren Pages, die keiner Image-Section angehören,
in den Pagefile auslagern würden. Ein negativer Wert meint, dass der
Pagefile dafür um die ausgewiesene Anzahl an Blöcken zu klein wäre.
Je mehr Prozesse daher auf einem Rechner laufen, desto höher ist die
Wahrscheinlichkeit, dass dieser Wert gegen 0 geht oder negativ wird.

Wenn es Digital jemals geschafft hat, Benutzer zu verwirren, dann mit
der Einführung des "Reservable" Wertes mit VMS V5 (vorher stand
dort "Used Blocks", d.h., die Differenz aus "Total Size" - "Free").

Hat eigentlich jemand die exakte Formel, nach der dieser Wert
berechnet wird? Ist die plattform- bzw. versionsabhängig?

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol*adv.magwien.gv.at

On Mon, 13 Aug 2007 19:10:01 +0000 (UTC),
helbig*astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to
reply) wrote:

>In article <f92j2s$ncl$1*online.de>, Michael Berger
><michaberger*online.de> writes:
>
>>
>> Ich habe jetzt mal (ohne Anleitung) DECwindows auf meiner VAXstation VLC
>> eingerichtet. Bezüglich des PAGEFILEs gibt mir der negative Parameter zu
>> denken. Kann das eventuell jemand interpretieren bzw. kommentieren?
>
>Suche in den Archiven von comp.os.vms. Es ist wie eine Bank, die nicht
>genug Geld hat, wenn alle Leute ihr Guthaben auf einmal auszahlen lassen
>wollen---ist aber nicht schlimm, weil dies sehr unwahrscheinlich ist.

Beim aktuellen Störfall AK Krümmel (Trafobrand) gab es die Situation
dass aufgrund begrenzter Resourcen eines VMS Doppelrechnersystems wohl
Daten verlorengegangen sind. Bei aussergewöhnlichen Belastungen ist es
eine Situation mit der man doch rechnen sollte. Im Bericht ist das
Scenarium etwas unsauber beschrieben indem von dem VMS als
Prozessrechner gesprochen wird und wir eigentlich wissen dass VMS
strenge Anforderungen an Prozessrechner nicht erfüllt und auch DEC das
Produkt nicht in dieser Weise vermarktet hat.

Gruss
KH Wienecke-Höltje
--

On Sat, 04 Aug 2007 21:12:27 +0200, Michael Berger
<michaberger*online.de> wrote:

>>I also recommend decompressing the system libraries for performance
>reasons. Use the command:
>$ *SYS$UPDATE:LIBDECOMP.COM
>
>Da geht es offenbar um Hilfe-Dateien(?) die normalerweise "on the fly"
>dekomprimiert würden, hier aber einmalig ausgepackt werden. Oder???
>Kann bzw. sollte man diese Aktion später, z.B. nach Installation
>weiterer Sprachen, wiederholen?
>
Wenn der Platz kritisch ist lässt sich das auch selektiv machen.
In der Dokumentation bzw. direkt in der "LIBDECOMP.COM" gibt es Info
wie die Auswahl zu machen ist.

Gruss
KH Wienecke-Höltje
--

K-H Wienecke-Höltje schrieb:
>
> Beim aktuellen Störfall AK Krümmel (Trafobrand) gab es die Situation
> dass aufgrund begrenzter Resourcen eines VMS Doppelrechnersystems wohl
> Daten verlorengegangen sind.

hmm, wenn VMS nicht genug Speicher hat, dann brennt der Trafo durch ?

"K-H Wienecke-Höltje":

> Beim aktuellen Störfall AK Krümmel (Trafobrand) gab es die Situation
> dass aufgrund begrenzter Resourcen eines VMS Doppelrechnersystems wohl
> Daten verlorengegangen sind.

Wegen eines vollen Pagefiles gehen keine Daten verloren.

> Bei aussergewöhnlichen Belastungen ist es
> eine Situation mit der man doch rechnen sollte.

Regelmäßig AUTOGENs fahren kann helfen, die Pagefilegröße
dem aktuellen Bedarf anzupassen.

> Im Bericht ist das
> Scenarium etwas unsauber beschrieben indem von dem VMS als
> Prozessrechner gesprochen wird

Wäre mir neu, dass VMS ein Prozessrechner ist. "Unsauber"
ist da noch sehr höflich formuliert.

> und wir eigentlich wissen dass VMS
> strenge Anforderungen an Prozessrechner nicht erfüllt

Ist auch etwas viel verlangt, von einem Betriebssystem zu
verlangen, dass es Hardware-Anforderungen erfüllt.

SCNR ;-))

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol*adv.magwien.gv.at

On Tue, 14 Aug 2007 17:36:43 +0200, "Ferry Bolhar"
<bol*adv.magwien.gv.at> wrote:

>"K-H Wienecke-Höltje":
>
>> Beim aktuellen Störfall AK Krümmel (Trafobrand) gab es die Situation
>> dass aufgrund begrenzter Resourcen eines VMS Doppelrechnersystems wohl
>> Daten verlorengegangen sind.
>
>Wegen eines vollen Pagefiles gehen keine Daten verloren.
Der aktuelle Fall ist in einem Bericht zu finden der öffentlich
verfügbar ist:

http://www.vattenfall.de/kernkraft unter :
Pressemitteilungen, Fakten und Hintergründe
>
>Regelmäßig AUTOGENs fahren kann helfen, die Pagefilegröße
>dem aktuellen Bedarf anzupassen.

Bei Ereignissen die sehr selten auftreten (Störfälle in AKWs) ist das
wohl keine zielführende Methode.
>
>> Im Bericht ist das
>> Scenarium etwas unsauber beschrieben indem von dem VMS als
>> Prozessrechner gesprochen wird
>
>Wäre mir neu, dass VMS ein Prozessrechner ist. "Unsauber"
>ist da noch sehr höflich formuliert.
>
>> und wir eigentlich wissen dass VMS
>> strenge Anforderungen an Prozessrechner nicht erfüllt
>
>Ist auch etwas viel verlangt, von einem Betriebssystem zu
>verlangen, dass es Hardware-Anforderungen erfüllt.
So abwegig ist das nicht, denn genau deshalb gab es VAXeln als
Laufzeitumgebung für ADA auf VAX Hardware.
>
MfG
Kalli
--

K-H Wienecke-Höltje:

>>Regelmäßig AUTOGENs fahren kann helfen, die Pagefilegröße
>>dem aktuellen Bedarf anzupassen.
>
> Bei Ereignissen die sehr selten auftreten (Störfälle in AKWs) ist das
> wohl keine zielführende Methode.

Doch, natürlich. Jede Tätigkeit, die helfen kann, Ausfälle
zu verringern bzw. die Wahrscheinlichkeit ihres Auftretens
zu minimieren, ist zielführend. Je weniger Ausfälle, desto
besser.

Ich kenne den Zusammehang zwischen dem erwähnten
Trafobrand und den involvierten VMS-Systemen (welche
zu knappe Resource an den Systemen war für das Entstehen
des Brandes verantwortlich?) nicht, aber wenn tatsächlich
eine Resource zu knapp und für den Brandausbruch
verantwortlich war, hat der betrefffende System Manager
seine Arbeit nicht ordentlich gemacht.

Auf einem VMS-System ist das regelmäßige Fahren von
AUTOGEN's zur Anpassung von System-Parametern
unerläßlich!

>> Ist auch etwas viel verlangt, von einem Betriebssystem zu
>> verlangen, dass es Hardware-Anforderungen erfüllt.
>
> So abwegig ist das nicht, denn genau deshalb gab es VAXeln als
> Laufzeitumgebung für ADA auf VAX Hardware.

Du schreibst ja selbst von einer "etwas unsauberen Beschreibung"
"VMS als Prozessrechner". VMS ist ein Betriebssystem und kein
Prozessrechner, daher stimmt die Semantik dieses Satzes nicht.
Hätte der Autor "VAX als Prozessrechner" geschrieben, hätte es
gepasst. Daher kann VMS auch nicht die "Anforderungen an
einen Prozessrechner" erfüllen, sondern allenfalls die VAX kann
es (oder auch nicht), VMS hingegen kann nur die Anforderungen
an ein Real-Time-OS erfüllen (oder nicht). Das wollte ich mit dem
obigen Satz deutlich machen.

Eine ordentlich getunte Alpha oder Itanium kann das übrigens
IMHO ohne weiteres, was die Reaktionsgeschwindigkeit auf
externe Ereignisse betrifft, sodass die Definition "erfüllt nicht die
Anforderungen an ein RT-OS" auf VMS zumindest teilweise
nicht mehr zutrifft.

Und ich denke, dass VAXeln als sog. "Real-Time-Betriebssystem",
das kein Paging/Swapping kennt (aber dafür eben mehr physika-
lischen Speicher benötigt) auch nicht viel schneller sein wird, wenn
es auf einem langsamen VAX-Prozessor läuft, als ein VMS mit
Paging auf einer flotten Alpha. Von I64 ganz zu schweigen. Die
Definition, dass ein RT-System kein Paging/Swapping machen
darf (was man durch genügend Speicher ohnehin fast zur Gänze
ausschließen kann), die letztlich dazu geführt hat, VMS nicht als
solches einzustufen, stimmt heute nicht mehr.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol*adv.magwien.gv.at

K-H Wienecke-Höltje <news001*julas.de> wrote:

> On Mon, 13 Aug 2007 19:10:01 +0000 (UTC),
> helbig*astro.multiCLOTHESvax.de (Phillip Helbig) wrote:
>
>>In article <f92j2s$ncl$1*online.de>, Michael Berger
>><michaberger*online.de> writes:
<schnipp>
>>> ... Bezüglich des PAGEFILEs gibt mir der negative
>>> Parameter zu denken. Kann das eventuell jemand interpretieren bzw.
>>> kommentieren?
>>
>>Suche in den Archiven von comp.os.vms. Es ist wie eine Bank, die nicht
>>genug Geld hat, wenn alle Leute ihr Guthaben auf einmal auszahlen
>>lassen wollen---ist aber nicht schlimm, weil dies sehr
>>unwahrscheinlich ist.
>
> Beim aktuellen Störfall AK Krümmel (Trafobrand) gab es die Situation
> dass aufgrund begrenzter Resourcen eines VMS Doppelrechnersystems wohl
> Daten verlorengegangen sind. Bei aussergewöhnlichen Belastungen ist es
> eine Situation mit der man doch rechnen sollte.
<schnipp>

Leider lässt sich der Bericht nicht näher über die Art der zu kanppen
Resource aus, ein zu kleiner Pagefile ist jedenfalls nicht explizit
genannt. Aufgrund der Erwähnung von unterschiedlichen Prioritäten könnte
die knappe Resource durchaus auch die CPU-Rechenleistung sein.

So wie ich den Bericht verstehe, sind zwar Zeitstempel zu bestimmten
Datensätzen verloren gegangen, nicht aber die Daten selbst (was aber
natürlich trotzdem einen Datenverlust im weiteren Sinn darstellt). Nun
ist dieser Datenverlust nicht die Ursache des Trafobrandes, sondern
scheint lediglich die nachträgliche Analyse der Situation zu erschweren.

Trotzdem würde ich bei einem System im AKW-Umfeld als System Manager
nicht mit negativen "Reservable"-Werten leben wollen. Auch wenn es
unwahrscheinlich ist, dass die angemeldeten Pagefile-Reservierungen alle
zugleich schlagend werden, sind die möglichen Folgen eines Systemausfalls
zu dramatisch.

Jedenfalls wäre es interessant, näheres zu dieser Resourcen-Knappheit und
dem Grund für die Umschaltung des Slaves zum Master zu erfahren. Ich
fürchtte aber, dass da wohl nicht mehr an die Öffentlichkeit getragen
wird.

Hans.