[Allegro] if-Befehl bei Flex

Bernhard Eversberg ev at biblio.tu-bs.de
Do Dez 18 08:26:30 CET 2014


Am 17.12.2014 16:27, schrieb Anando Eger:
>
> "if usr" versucht die ?.tbl-Datei in RRRR.rrr umzubenennen.
> Wenn das gelingt, wird diese wieder zurück-umbenannt und die
> gewünschte Aktion ausgeführt (bzw. logisch negiert bei if not usr)
>
> Bekannte Nebenwirkungen:
> ...
>
> Meine Empfehlung: Diesen Befehl im Netzwerk nicht nutzen, sondern
> eine eigene Erkennung bauen - etwa so:
> ...

Wir begrüßen konstruktive Vorschläge und setzen sie um, wenn
sich das irgend machen läßt und sachliche Gegengründe fehlen.
Die Idee einer solchen Lösung, mit außenliegender Hilfsdatei, hatten
wir seinerzeit auch schon gehabt, nur wieder verworfen wegen
höherer Komplexität und Wartungsanforderung, und nach Abschätzung des
Gefahrenpotentials von "if usr" als "recht gering".

Aber weil es noch Diskussionsbedarf geben könnte, etwa wegen Bergers
Einwurf, hier noch ein paar Dinge zum Hintergrund.

Der Befehl "if usr" ist nur geschaffen worden, um eine Hilfe zu bieten
für die ORG-Prozeduren. Die können nur laufen, wenn eine Datenbank
gerade nicht in Benutzung ist. Nur in den FLEXen org.flx und
_restore.flx wird er deshalb verwendet. Das Menü (h org) kriegt nur
zu sehen, wer mindestens Berechtigung 5 innehat.
Wer eine größere Datenbank in einer Vielbenutzer-Umgebung zu betreuen
hat, wird aus naheliegenden Gründen solche Prozeduren mit einigem
Bedacht einsetzen: zu betriebsschwachen Zeiten, mit Vorankündigung
und/oder mit Nutzung der "Totalsperre".

Was passiert aber, wenn man eine ORG-Routine startet, *obwohl* gerade
noch jemand die Datenbank benutzt, also z.B. cat.tbl geöffnet ist?
Nichts Schlimmes, keine Datei wird verändert oder gelöscht, es kommen
nur ein paar nicht aufschlußreiche, zugegeben, Meldungen, aber man
ersieht daraus, und aus dem schnellen Ende, daß was nicht geklappt hat.
(Ein Programm wie index.exe kann keine geöffneten Dateien löschen.)

Falls sich Belege von Schäden finden, die auf Miß- oder Falschgebrauch
oder Fehlfunktion des Befehls "if usr" zurückzuführen sind, oder wenn
sich nun eine begründete Mehrheitsmeinung bildet, der Befehl "if usr"
sei wohl doch zu gefahrenträchtig, dann ziehen wir ihn und das Menü ORG
aus dem Verkehr und verstärken die Appelle an das Verantwortungs-
bewußtsein der Systemverwaltenden, die im Bedarfsfall eine
Reorganisation vorzunehmen haben oder andere Arbeiten, die unter
Ausschluß jeder Datenbankbenutzung auszuführen sind.

In dem Admin-Job al.job, der ja auch unter Linux nutzbar ist, haben
wir zwar auch ORG-Prozeduren im Angebot, diese jedoch starten nicht
sofort die Funktion und nutzen "if usr" nicht, sondern bringen die
Meldung:
"Script org.bat was created. Now enter command 'org.bat' to run it!"
was der Admin sich dann immer noch gut überlegen kann und sollte.
(Während al.job läuft, ist die Datenbank geöffnet, deshalb beendet es
sich, nachdem die Meldung gegeben wurde, um die Prozedur ausführbar zu
machen.)
Wir könnten dies auch für a99 so einrichten, haben aber den Eindruck,
daß es durchaus mündige Nutzer gibt, die gerade die Möglichkeiten
zum schnellen Ausführen solcher Prozeduren, etwa bes. zu Testzwecken,
sehr schätzen.

Fazit:
Elementar relevant ist "if usr" für einen geordneten und sicheren
Datenbankbetrieb nicht.

Unbetroffen sind OPL-Anwender und solche, die nur einen Arbeitsplatz
mit Schreibberechtigung haben. Oder zwei, falls die beiden sich nicht
spinnefeind sind.

Wer jedoch Unheil stiften will, sucht und findet andere Wege als
sich in FLEX einzufuchsen und dann mit "if usr" was anzurichten.
D.h. Sabotageakte unter Nutzung von "if usr" kann man ausschließen.


B.Eversberg




Mehr Informationen über die Mailingliste Allegro