Message-ID: <425A8CA2.9070903@Gymel.com>
Date: Mon, 11 Apr 2005 16:41:38 +0200
From: Thomas Berger <ThB@gymel.com>
To: hanslist@sun01.sub.uni-hamburg.de
Subject: Netzwerk- Nichtinstallationen
Einige HANS-Anwenderbibliotheken haben - aus unterschiedlichen Gründen - eine administrativ komplizierte Netzwerktopologie, die dazu führt, dass HANS zunächst auf einer lokalen Platte installiert bzw. aktualisiert wird und dann die Änderungen irgendwie ins Netz geschafft werden.
Grundsätzlich ist zu sagen, dass jede HANS-Installation mehrere Datenbanken (auch zu unterschiedlichen Parametervarianten) beherbergen kann, und dass auf jedem Netzwerk oder Rechner auch mehrere HANS- Installationen koexistieren können.[2]
Eine irgendwohin kopierte HANS-Installation ist für sich noch
keine eigenständige HANS-Installation, das wissen alle, die nach dem
Kopieren in .bat- und anderen Dateien Pfade etc. anpassen mussten. Alle
Konfigurationsinformationen sind in config\hansconf.xml (nicht mit
notepad™ bearbeitbar wegen
Zeilenumbruchproblemen, aber etwa mit
wordpad™) zusammengefasst, aus diesen werden
dann durch HANS-Tools die Startdateien etc. generiert. Wird eine
Installation einfach kopiert, wird insbesondere der Inhalt des
config-Verzeichnisses kopiert, so werden die Steuerdateien für die
originale HANS-Installation erzeugt und nicht die, die die Kopie
benutzen würden. Aber auch, wenn man das Verzeichnis config nicht
mitkopiert, kann es Probleme geben, denn die Installationsprozedur
verändert ab und zu die in config liegenden Dateien (z.B.
reconfig.xml mit dem Verzeichnis der
Parametervarianten, aber auch hansconf.xml selbst
wird ab und zu schreibend verarbeitet). Die Empfehlung ist, wenn irgend
möglich die Installation nicht zu kopieren, sondern ständig als separate
Installation aufzufassen und separat zu aktualisieren.
Wenn das nicht möglich sein sollte, Sie also aus welchen Gründen auch immer unbedingt eine aktualisierte Installation durch die Gegend kopieren wollen, sollten Sie so vorgehen: [Achten Sie darauf, dass Ihre Produktions-Datenbank(en) nicht unterhalb der HANS-Installationswurzel liegen, sonst kopieren Sie die irgendwann aus Versehen auch noch, d.h. ersetzen den aktuellen Stand durch einen ziemlich alten...]
hansconf.xml sollte Informationen zu allen Datenbanken aus beiden Installationen enthalten, "default" sollte irgendeine (z.B. die "leere" \h2k\daten) aus der lokalen Installation sein.
(Im folgenden sei "netz" der Name
fuer die echte Produktionsdatenbank im Netz)
Nach dem Kopieren muss in config\hansconf.xml dann nur in <section name="general"> die Pfadinformation in den Parametern
AppDir
und
ProgDir
angepasst werden
Öffnen Sie eine neue DOS-Box und wechseln
in das Wurzelverzeichnis der kopierten Installation (etwa
q:\otto\h2k), geben Sie
nicht inihans ein. Dort löschen Sie dann
vorsichtshalber inihans.bat und tippen folgende
Kommandos:
set
-H2k=q:\otto\h2kset -P=%-H2k%\prg.\util\dogen --const(Es werden hansdemo.bat und die
notwendigen Hilfsdateien hansdrv.bat,
hanswrap.bat,
shlinks.bat erzeugt)
.\util\dogen --inst --name
netz(Es werden dann im aktuellen Verzeichnis die Dateien
cphans.bat,
cphans.opt,
hans.bat,
hansopa.bat und
inihans.bat erzeugt, und zwar auf die
Datenbank "netz" eingestellt, nicht auf die
Default-Datenbank)
Im Unterverzeichnis desktop liegen durch das Kopieren immer noch (als Kopiervorlage) Verknüpfungen für Datenbank und Windows-OPAC mit dem a99.exe der Originalinstallation, diese können ebenfalls aktualisiert werden (sie werden aber nicht benutzt, weil es nur Kopiervorlagen sind):
.\util\linkdb --all
Außerdem liegen in desktop (wiederum nur als Kopiervorlage)
Verknüpfungen mit hans.bat und
cphans.bat, die können wie folgt aktualisiert
werden:
%-H2k%\shlinks %-H2k%\desktop
Zusammenfassung: Die Sache ist deswegen etwas umständlich, weil Sie in der Netzinstallation kein Installations-Update und kein Auto-Update vornehmen wollen, sondern alles zu Fuß machen wollen. Mit anderen Worten: Sie haben es nicht anders gewollt...
Essentiell ist
eine geeignet vorbereitete hansconf.xml der Lokalen Installation, die auch die wichtigen Netzdatenbanken kennt
die Anpassung bzw. Rekonstruktion der beiden Pfadsetzungen
in der kopierten hansconf.xml
sowie das anschliessende Absetzen der folgenden vier
Kommandos aus dem Wurzelverzeichnis
q:\otto heraus, die hier noch einmal
zusammengefasst seien:
set
-H2k=q:\otto\h2k
set -P=%-H2k%\prg
.\util\dogen --const
.\util\dogen --inst --name
netz
Sie haben nun eine Situation, in der zwei HANS-Installationen, die tatsächlich voneinander getrennt sind (es wird aber jeweils dasselbe lokale Arbeitsverzeichnis c:\hansw2k genutzt) für jeweils einen Satz identischer Datenbanken zuständig sind. Weil aber die jeweiligen hansconf.xml durch Kopieren und nur punktuelle Modifikation weitestgehend synchron gehalten werden, ist das oben geschilderte Irritationspotenzial möglicherweise innerhalb der Grenzen des Erträglichen.
Wenn nun in hansconf.xml unter dem Namen
"lokal" ein Verzeichnis einkonfiguriert ist,
das eine lokale Kopie der Produktionsdatenbank vorhält, können Sie nun
alle möglichen riskanten, aber in Ihrem Setting notwendigen Aktionen
durchführen, etwa:
Datenbank "netz" sperren
Löschen der Datenbank
"lokal"
Kopieren von "netz" nach
"lokal"
%-P%\rfrdb --name
lokal
Löschen von "netz" (Scheitert
ganz prächtig, wenn da jemand noch die Datenbank im Zugriff
hat)
Kopieren von "lokal" nach
"netz"
Datenbank "netz" freigeben
(Bitte Datenbanken stets nur in leere Verzeichnisse kopieren, das Risiko wäre zu gross, dass irgendeine .hld-Datei im Ziel liegt, die nicht aus der Quelle stammt, dann mitindexiert wird und zurück ins Quellverzeichnis wandert: Deren Daten sitzen dann im Index, gehören aber [noch] nicht zur Datenbank, alle Bearbeiter reklamieren, dann wird gründlich reindexiert, danach dann sitzen die Daten als echte Dubletten in der Datenbank und sind fast unmöglich maschinell wieder herauszuoperieren)
[2] Jede einzelne HANS-Datenbank sollte nach Möglichkeit maximal einer HANS-Installation zugeordnet werden, ich selber halte mich nicht immer an diesen Rat und bin daher häufig irritiert, weil ein und dieselbe Datenbank manchmal die Parameter fuer den WWW-OPAC hat und manchmal nicht, je nachdem, ob ich sie über Installation A oder Installation B das letzte Mal regeneriert hatte...