LOG2ALG

[Bernhard Eversberg]

Dem Vorschlag von Herrn Berger:
> 
> Entweder die Logdatei mit update -fp oder die .ALG-Datei mit
> update -fm11 in eine *ganz neue* Datenbank einmischen, diese
> dann mit srch -f6 -ei-1/... in eine .alg-Datei exportieren.
> 
(was waere denn das "oder"?)
kann man sich nicht ganz vollinhaltlich anschliessen. Denn die geloeschten
Saetze fallen dann unter den Tisch.

LOG2ALG arbeitet sequentiell, und wenn ein Satz zum zweiten mal kommt, ist 
der erste schon weggeschrieben und das Programm weiss nichts mehr davon.
Daher koennte man es nicht dazu bringen, jeweils nur die letzte Version eines
Satzes wegzuschreiben.

Absteigendes Sortieren nach IdNummer und Datum/Uhrzeit waere ein korrekter 
Denkansatz, aber es klappt nicht mit den neuen Saetzen. Die haben, wenn
sie zum ersten mal auftauchen, vorne eine Kategorie  #u1 #####n  mit der
Dateinummer n, wo der Satz hineinkommt. Wenn es wichtig ist, dass die Saetze 
in dieselbe Datei kommen, muss diese #u1 fuer das spaetere UPDATE erhalten
bleiben! Auch die #u1 @@@@@ fuer das Loeschen muss erhalten bleiben. Die 
Vorbereitung fuer das Sortieren und dann hinterher die Nachbereitung fuer 
das UPDATE sind also nicht ganz trivial. Man muss diese #u1 in 
Hilfskategorien aufbewahren, denn zum Sortieren muss man ja eine neue #u1
erzeugen, und hinterher vor dem UPDATE restaurieren.

Also: es muessen Parameter fuer die Sortiervorbereitung geschrieben werden, 
mit diesen Vorgaben, und Parameter fuer das Restaurieren, nach der EBOX-
Behandlung.

Der SRCH-Lauf nach dem Sortieren, vor der EBOX-Behandlung, muesste mit den 
Parametern  I-DUPL.APR  gemacht werden.

Good luck

B.E.


Bernhard Eversberg
Universitaetsbibliothek, Postf. 3329, 
D-38023 Braunschweig, Germany
Tel.  +49 531 391-5026 , -5011 , FAX  -5836
e-mail  B.Eversberg at tu-bs.de