[Allegro] if-Befehl bei Flex

Thomas Berger ThB at Gymel.com
Do Dez 18 08:53:09 CET 2014


Lieber Herr Eversberg,

> 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".

vielen Dank fuer die Klaerung. In der Praxis ist das Feature gerade
bei Reindexierungen ungemein nuetzlich, falsche Alarme gibt es
eigentlich nicht, typischerweise hat der indexierende Power-User
zwar alle Kollegen aus der Datenbank herauskomplimentiert, selber
aber vergessen, dass er noch einige a99-Fenster in der Task-Leiste
versenkt hatte...

Im Rahmen einer Datenbank-Wartung halte ich es fuer legitim, Dateien
umzubenennen, auch automatisch. Das ganze steht und faellt allerdings
mit der Eigentuemlichkeit von Windows-Dateisystemen, dass geoeffnete
Dateien gegen Loeschungen und Umbenennungen geschuetzt sind, das
ist unter Linux keinesfalls so und je nach Netzwerkprotokoll (lokal
wohl unproblematisch, SMB/CIFS, NFS, ...) sollte man sich auch nicht
darauf verlassen.

Diese Art der Anbindung ist nicht nur fuer "if usr" moeglicherweise
relevant, sondern definitiv fuer den laufenden Betrieb im Netz, wenn
es um das hier vieldiskutierte Locking geht. Z.B. hatte ich neulich
den Fall eines per NFS gemounteten Linux-Volumes, das selber dann
wiederum ueber SAMBA den allegro-Arbeitsplaetzen bereitgestellt wird:
Das ist nicht nur langsam, sondern funktioniert auch nicht (im
Mehrplatzbetrieb). Auch hier halte ich es fuer legitim, wenn allegro
eine reine Windows-Infrastruktur unterstellt, d.h. Clients und
Server mit aktuell unter Support befindlichen M$-Betriebssystemen.
Ob und wie das dann bei alternativen Loesungen zu Performance-
und anderen, noch schwerwiegenderen Problemen fuehrt, liegt dann
in der Verantwortung der jeweiligen Administratoren ("normale" SAMBA-
Loesungen, d.h. das bereitgestellte Volume ist ein lokales des
jeweiligen Servers, funktionieren z.B. durchaus, normalerweise
nur langsamer, und "Novell", gibt es das noch?, ist sogar offiziell
von Microsoft unterstuetzt).

viele Gruesse
Thomas Berger






Mehr Informationen über die Mailingliste Allegro