Universitätsbibliothek der Technischen Universität Braunschweig, Universitätsplatz 1, D-38106 Braunschweig, Tel. (0531)391- 5011, -5026, FAX -5836
Am 5. Juli 1995 wird die TU Braunschweig 250 Jahre alt
Die erstere stellt man sich vor für die Dateneingabe, die letztere für Karten- und Listendruck. Es gibt doch Textprogramme mit solchen Funktionen, warum also kann das nicht auch allegro? Zu bedenken ist, daß Textprogramme diese Dinge immer nur für eine bestimmte Sprache leisten können, nicht für mehrsprachige Texte. Rechtschreibprüfung erfordert nämlich im Hintergrund eine Art Wörterbuch, und dieses ist in aller Regel einsprachig. Es mag zwar mehrere geben, aber zu einem Zeitpunkt kann immer nur eins benutzt werden. Auch die Algorithmen eines Silbentrennungsmoduls sind stets sprachspezifisch: wenn man auf Englisch geschaltet hat, kann deutscher Text nicht korrekt getrennt werden und umgekehrt. In Katalogdaten können jedoch nicht nur unterschiedliche Sprachen nebeneinander, sondern sogar innerhalb eines Datensatzes auftreten. Weitere Probleme, durch die sich Titeldaten auszeichnen, sind Namen, Abkürzungen, ausgefallene Spezialbegriffe, abweichende Schreibweisen. Aber noch etwas hindert uns, allegro mit den genannten Funktionen zu überfrachten und langsamer zu machen: Katalogisierung verlangt nicht primär Rechtschreibkenntnisse, sondern präzises Abschreiben. Und Silbentrennung kann man einem nachgeschalteten Textprogramm überlassen, wenn dies für einen Listendruck sein muß. Doch auch dabei tritt das erwähnte Sprachproblem auf.
Keine tolle Idee wurde so oft geboren wie diese. Nur stellt sich immer wieder heraus: es ist eine Seifenblase. Neuere Texterkennungs- Software mag fähig sein, unterschiedliche Maschinenschriften durcheinander zu bearbeiten, schwache, schräge, verschmierte und verschmutzte Schrift zu verdauen, Sonderzeichen und Akzente zu erkennen. Aber handschriftliche Zusätze, Stempel, farbige Textteile, Unterstreichungen, Angaben auf der Kartenrückseite, Aufdrucke, eigenwillig plazierte oder aufgeklebte Signaturen und dergleichen mehr dürften jedem Programmierer noch immer Bauchschmerzen machen. Aber schlimmer noch: auf den Karten sind die Angaben veraltet und zu wenig normiert: Namen von weiteren Verfassern stehen mitten im Text und sind nicht invertiert, d.h. von der Software nicht als Namen erkennbar, die Reihenfolge der Elemente im Kartentext ist nicht genügend normiert (besonders bei PI-Karten), es wurde oftmals mit Abkürzungen operiert, um keinen Folgezettel machen zu müssen, Sacherschließungsangaben stehen oft auf den zu konvertierenden Karten nicht mit drauf, usw. usf. Die Folge wäre ein beträchtlicher Aufwand für die manuelle Nachbearbeitung.
Fazit: diese Idee lieber ganz schnell vergessen und sich um leicht nutzbare Fremddaten bemühen. Diese erfordern auch immer weniger Nachbearbeitung und enthalten immer öfter schon normierte Elemente und Sacherschließungsdaten.
Nicht immer, aber immer öfter wird angenommen, daß es so etwas schon gibt. Nicht immer ausgesprochen, aber meistens doch erwartet wird, daß diese Version nicht teurer, vielleicht sogar billiger sein könne als die DOS-Version. Solche Vermutungen liegen meilenweit daneben. Wie kann etwas spottbillig sein, wenn es einen horrenden Entwicklungsaufwand voraussetzt, aber kein Massenprodukt ist? Im Bereich des Möglichen liegt nur, daß innerhalb 1995 ein Windows-OPAC-Programm herauskommen kann. Erwartet wird, wenn man nachfragt, aber noch viel mehr: die gesamte Konfigurierung und Parametrierung soll menügesteuert und selbsterklärend ablaufen, damit das Erlernen der diversen Sprachen entfällt. Das ist Utopie. Es gibt z.B. auch kein solches System zum Entwickeln von Pascal- oder C-Programmen, obwohl der Markt dafür um ein Vielfaches größer wäre. Mit andern Worten: Parametrierung wird schwierig bleiben.
Und noch etwas: ein Windows-Programm, das in etwa dasselbe leisten würde wie das CockPit, hätte von vornherein einen Nachteil: es wäre spürbar langsamer. Nun ja, man kauft sich halt einen Pentium, wenn man noch keinen hat.
Aber wie auch immer - leisten wir uns doch mal für eine Minute den Tagtraum, es gäbe die hochkomfortable Windows- Version mit Rechtschreibprüfung und Silbentrennung. Jeder kann auf Anhieb alles nutzen. Und alte Katalogkarten können unbesehen eingefüttert werden. Sie kostet deutlich mehr - doch das läßt sich schnell wieder einsparen! Denn wozu braucht man noch ausgebildetes Bibliothekspersonal, wenn jede Hilfskraft und jeder Professor das Programm bedienen kann?
Mit dieser Bezeichnung soll das immer erneut heiß diskutierte Problem nicht herabgewürdigt werden, man braucht nur endlich eine griffige Bezeichnung dafür. Es geht um dieses: Wenn wir die Schlagwörter "Erbse" und "Zählung" haben und dafür Stammsätze mit den Identnummern 123 bzw. 456 vorliegen, kann man daraus die RSWK-Schlagwortkette "Erbse / Zählung" bilden. Jedoch war es bisher nicht möglich, in der Erfassung dann _123 / _456 zu schreiben und zu erwarten, daß man im Index dann hinterher "erbse / zaehlung" findet. Bei PRESTO funktionierte das zwar, beim V14-INDEX konnte aber nur "erbse / _456" herauskommen! Dies zu korrigieren ist zwar für V14a noch gelungen, wenn auch um den Preis einer deutlich längeren Laufzeit der Indexierung. (Im Abschnitt "Kategorischer Kompromiß" unter INDEX wird das Verfahren beschrieben.) Grundsätzlich UNMÖGLICH ist es aber, daß PRESTO dann später, wenn im Stammsatz "Zählung" in "Zählen" geändert wird, im Register automatisch die Eintragung "erbse / zaehlung" in "erbse / zaehlen" ändert. Dazu müßte PRESTO den gesamten Index durcharbeiten und alle Einträge daraufhin überprüfen, ob "zaehlung" darin vorkommt, um dieses dann durch "zaehlen" zu ersetzen. Man bedenke dabei: die Zeichenkette "zaehlung" im Innern von Schlüsseln kann ja auch anders zustandekommen, etwa im Wort "volkszaehlung"!
An dieser Stelle sei auf eine weitere Neuerung im Bereich V14-Ersetzungen hingewiesen: es können jetzt mehrere Pseudoschlüssel je Datensatz definiert werden, d.h. PRESTO kann bei einer Stammsatz-Änderung an mehreren Stellen unter- schiedliche betroffene Einträge ändern. Siehe dazu den Abschnitt über INDEX.
Wieder einmal ist Dank abzustatten an zahlreiche allegrologInnen, die mit Fragen, Anregungen, konstruktiver Kritik und genau dokumentierten Fehlermeldungen dazu beigetragen haben, V14a zu einem Produkt zu machen, das man umgehend installieren sollte. Mindestens aber das Programm UPDATE sollten Sie wegen seiner erhöhten Sicherheit sofort einsetzen, wenn Sie ein Mehrplatzsystem betreiben.
Für eine Erstinstallation geben Sie z.B. den Befehl a:install a c (ohne Doppelpunkte hinter a und c!),
um von Laufwerk A: nach Laufwerk C: zu installieren.
Wenn Sie schon irgendeine ältere Version installiert haben, wählen Sie auf dem Menü "Routinen" des CockPit den Punkt "Neue Version installieren" und dann den Unterpunkt "u : Update- Installation". Alles weitere passiert automatisch.
Weitere Installationsfragen werden im Handbuch (Kap.0.10) und in der Datei README behandelt.
Im folgenden ist immer in eckigen Klammern angegeben, welche Dateien betroffen sind und/oder wo im Handbuch evtl. etwas zu ändern ist. Seitenzahlen beziehen sich auf die Ausgabe V14.
[UIFC...]
Bei jedem Neustart des CockPit präsentiert es sich mit den Grundeinstellungen, die es aus der Vorgabendatei entnimmt, standardmäßig CP.OPT. Oft will man jedoch mit derselben Datenbank weitermachen, an der man zuletzt gearbeitet hatte. Deshalb merkt sich CockPit jetzt die dafür nötigen Einstellungen in einer neuen Datei mit dem Typ .PRE, also standardmäßig CP.PRE. Das heißt, die Fußzeilen sehen beim Neustart so aus, wie man das CockPit zuletzt verlassen hatte. Da dieses mit Sicherheit nicht immer erwünscht ist, kann man mit einem Knopfdruck auf die Normaleinstellung zurückschalten: man drückt einfach 'z'. Das steht auch auf dem "Routinen"-Menü als neuer Punkt "Zurückschalten". (Achtung: neue Zeilen 135 bis 137 in UIFCGER und UIFCENG). Nochmaliges 'z' schaltet erneut um. Wir denken, damit allen Erwartungen entgegenzukommen. Die Vorstellung jedoch, CockPit möge immer mit den Optionen starten, die dem aktuellen Vorhaben entsprechen, gehört in den Bereich der Einleitung...
Schauen Sie sich nach dem Verlassen des CockPit die Datei CP.PRE an. Wenn Sie die neue
Funktion absolut nicht wollen, bauen Sie in Ihre CP.BAT den Befehl del cp.pre oberhalb des
acp-Aufrufs ein.
[UIFC..., Kap.6.2, S.128 u. 0.11.5, S.37]
Unter "Routinen / Volltextsuche, Listen" sind jetzt zusätzlich die vier Punkte zu finden, die bisher etwas versteckt unter "Optionen" stehen, also "1 : Sortierung" usw. Das logisch Zusammengehörige ist jetzt also auf einem Untermenü vereint. Es wird empfohlen, die Zeilen 190 bis 194 der Datei UIFCxxx zu verändern: Ziffern 1 bis 5 durch Buchstaben a bis e ersetzen.
[Kap.0.11.2, S.33]
wird das CockPit durch den neuen Menüpunkt "X : EXTERN" unter "Routinen". Dieser löst den Start einer Stapeldatei namens EXTERN.BAT aus, die sich jeder Anwender selbst zusammenstellen kann. Das kann z.B. eine abgewandelte Version des CP.BAT sein, wobei eine andere Vorgabendatei benutzt wird. Im Prinzip konnte man dasselbe mit den bisherigen "eigenen Routinen" auch erreichen, aber nun gibt es einen standardmäßigen, zusätzlichen Ausstiegspunkt mit einem definierten Verhalten.
Auf dem Menü "Funktionen / QRIX" sind zwei neue Zeilen zu finden, "Begin" und "End", die den Optionen -s und -S ent- sprechen. Eine weitere Zeile "Dateiname" ermöglicht es, die Ergebnisse des QRIX-Laufs in eine Datei umlenken zu lassen. Der gewählte Name wird mit '>' an den Aufruf angehängt. Damit ist QRIX jetzt noch besser per CockPit steuerbar.
[CP.OPT]
Bei einem Teil der V13 stand in der Vorgabendatei CP.OPT der Befehl p p2 . Man erhält dann keine
korrekte Titelanzeige. Entfernen Sie diesen Befehl. Ein p-Befehl ist nur dann nötig, wenn man nicht standardmäßig
die Datei D-1.APR für die Titelanzeige benutzt.
[Anh.A.1.3, S.265]
wie etwa Pica3 mit über 1200 (in Worten "zwölfhundert") verschiedenen Kategorien können nun ebenfalls
implementiert werden. Gebraucht wurde und genutzt wird dies in Göttingen, wo eine Konfiguration für Pica3 entwickelt
wurde und gepflegt wird. Einziger, aber eben entscheidender Vorteil: Verbundteilnehmer, die
allegro als lokales System betreiben, können dann mit dem von der Katalogisierung im
Zentralsystem gewohnten Format auch lokal arbeiten. Wer jedoch ein erheblich leichteres Modell fährt (wie z.B. das A-Schema)
kann von diesem internen Umbau gleichfalls profitieren, nämlich Arbeitsspeicher freimachen! Denn es gibt zwei neue
m-Befehle in der .CFG :
md Anzahl der Deskriptorzeilen in der .CFG
Standard: md800, für A.CFG reicht md400
mK Größe des Kategoriespeichers (Aufnahmespeichers) in Bytes
Standard: mK48000, für A.CFG reicht mK24000
Der Wert md darf keinesfalls kleiner, braucht aber auch nicht größer zu sein als die tatsächliche
Zahl der #-Zeilen (Deskriptorzeilen) in der .CFG-Datei. Ist der Wert zu klein, kommt eine Fehlermeldung.
Bei mK muß man berücksichtigen, daß die Deskriptorzeilen ebenfalls im Aufnahmespeicher
untergebracht werden, und da bezahlt man für ein System der S-Klasse denn doch einen gewissen Preis, zumal zwangsläufig
auch die Parameterdateien umfangreich werden (Konfigurationsbefehl mX). Einsparmöglichkeit: in den
Deskriptorzeilen die Klartextbezeichnungen in "..." weglassen oder ganz knapp halten, denn sie sind für das Funktionieren
unnötig.
Empfehlung: Zuerst mK auf Standard lassen, mit <Alt>+F7 prüfen, wie groß der freie
Aufnahmespeicher ist, dann mK so setzen, daß der größte zu erwartende Datensatz,
großzügig geschätzt, zweimal reingeht. Achtung: ein hierarschischer Satz muß als Ganzes hineingehen. Ist der
Wert zu klein, kommt keine Fehlermeldung, denn beim Start weiß das Programm nicht, wie groß der größte
vorhandene Satz ist. Für eine vorhandene Datenbank läßt sich dieser Wert jedoch ermitteln: man macht eine
Volltextsuche mit srch -f4 -s0 -ei-1/nul -m1 ..., dann erfährt man am Ende, wie lang der
längste Datensatz ist. Auch SNIFFER stellt diesen Wert fest, wenn man eine .ALD-Datei prüfen läßt.
[Anh.A.1.3]
Wenn nur bestimmte Satztypen automatisch numeriert werden sollen, z.B. nur Stammsätze, aber keine Titelsätze, kann man
einen Trick anwenden. Soll keine Nummer vergeben werden, besetzt man diejenige Kategorie, die mit dem Befehl cg
angegeben ist, also z.B. #00, mit einem Wert wie z.B. ¦9#xxx?3 (am besten automatisch per Abfrageliste). Das Programm
ermittelt dann die nächste dreistellige Nummer im Register 9 und versucht sie als Kategorie #xxx einzuordnen. Das mißlingt,
weil #xxx ungültig ist, aber #00 wird dennoch beseitigt.
[Anh.A.2]
Bei Abfrageschleifen kam bisher für die zweite und weitere Kategorien immer das Zeichen ú als Steuerzeichen hinter der Kategorienummer zum Vorschein. Das war erstens irritierend, zweitens klappte es doch nicht immer, wie es sollte. Statt des ominösen ú kommt jetzt ASCII-Code 250 und bewirkt, daß der nächste freie Code genommen wird, der in der CFG für die betreffende Kategorie definiert ist.
Was die Abfrageliste betrifft, das muß zugegeben werden, sind Wünsche offengeblieben. Besonders der Umgang mit Teilfeldern läßt sich nicht zu aller Zufriedenheit regeln. Einfachheit und Schnelligkeit sind gerade hier besonders schwierig zu kombinieren. Irgendwann wird man hier wohl doch eine ganz andere Lösung suchen müssen.
mit ESC, Alt+x oder sonstwie gibt es, wenn man APAC mit der neuen Option -m startet. Wenn man also in
Netzwerken bestimmte Geräte ausschließlich als OPAC-Terminals einsetzen will, lasse man diese so hochfahren, daß
sie APAC mit dieser Option aufrufen.
Auf Seite 1/2 wurde das "Erbsenzähl"-Problem als ein unlösbares dargestellt. Unlösbar ist nur die automatische Ersetzung innerhalb PRESTO, wenn der Stammsatz des zweiten Kettengliedes ("Zählung") geändert wird. Lösbar ist und gelöst wurde das Problem der Indexierung, d.h. die vollständige Ersetzung der Nummern durch Stammformen durch das Programm INDEX. Hier stellen wir dar, wie man dazu verfahren muß. Damit es funktioniert, muß allerdings INDEX anders arbeiten als vorher: es muß in einem Vorlauf die Primärschlüssel erzeugen, die ja bei Stammsätzen zugleich als Ersetzungsschlüssel fungieren (Handbuch 10.2.6.8). Im Hauptdurchlauf werden dann alle anderen Schlüssel erzeugt, wobei dann über den vorher erstellten Index die Nummern durch Klartexte ersetzt werden können.
Fazit: um das unlösbare Erbsenzähl-Problem zu entschärfen, ist ein Kompromiß mötig: man muß kategorisch jede Änderung an den Ansetzungskategorien der Stammsätze verbieten. Zwar kann man jederzeit neue Verweisungsformen einbringen, aber die Hauptform muß unangetastet bleiben. Also auf keinen Fall das Stammschlagwort "Zählung" in "Zählen" ändern, sondern "Zählen" als Verweisungsform hinzufügen. Für kleine Datenbanken ist es möglich, kurzfristig den Index zu erneuern, bei sehr großen Datenbanken jedoch wird das zeitlich immer seltener durchführbar sein - der Kompromiß wird dann immer öfter als ein unbequemer empfunden werden.
Aber sei's drum - so wird's gemacht:
Vorlauf:
index -@1 -fx. ... (x = 7, i, oder n, sonstige Optionen wie üblich)
Es wird nur der Primaerschlüssel für jeden Satz erzeugt.
Voraussetzung: man hat ak=zz+@ als ersten ak-Befehl und bei der reservierten Sprungmarke
#-@ wird für jeden Satz ein sinnvoller Schlüssel erzeugt. Die Primärschluessel der
Stammsätze müssen alle im selben Register liegen und die Form
IdNr=¦MErsetzungsform haben, wie es V14 erfordert. (M steht für eine Sprungmarke
#-M, nicht für ein Register: unter #-M erfolgt die Umcodierung der
Ersetzungsform.)
Hauptdurchlauf:
index -@2 -fi1 ...
Hier muß es -fi1 heißen, denn der Index ist ja schon vorhanden und
muß jetzt vervollständigt werden.
Alles weitere läuft so ab wie gewohnt. QRIX startet auch noch den sog. zweiten Durchlauf mit -fa,
der aber keine Änderungen mehr bewirken sollte und daher sehr schnell geht, wenn alles vorher korrekt war.
Diese Methodik ist noch nicht über CockPit automatisch eingebunden. Man sollte sich also eine Stapeldatei für die eigenen
Zwecke machen oder diese zwei Durchläufe mit der Hand starten.
[Kap.10.2.6.8, S.200]
Zur neuen Methodik der Stammsatzverknüpfungen von V14 (siehe auch news 36) gehört auch der "Pseudoschlüssel". Nur Stammsätze brauchen einen Pseudoschlüssel. Er dient dazu, den Programmen PRESTO und UPDATE anzuzeigen, in welchem Register welche Einträge auszutauschen sind, wenn an einem Stammsatz eine Änderung vorgenommen wird. V14a ermöglicht mehrere solche Schlüssel je Stammsatz. So wird es z.B. möglich, denselben Namensstammsatz für Einträge im Namensregister und im Schlagwortregister heranzuziehen. Die Pseudoschlüssel werden im übrigen erzeugt wie ganz normale Schlüssel, und es gibt keine reservierte Sprungmarke dafür. Nur gespeichert werden sie nicht.
Mit V14a kann man endlich mit einem ak-Befehl mehrere völlig verschiedene Schlüssel erzeugen lassen, z.B. die
Pseudoschlüssel. Normalerweise endet ein Abschnitt der Indexparameterdatei mit #+# als Endebefehl. Jetzt
kann man (fast) beliebig viele weitere Schlüssel im selben Abschnitt programmieren, man muß nur den ASCII-Code 8 als
Begrenzung dazwischen setzen. Das geschieht entweder mit dem Befehl #t{ 8 }, oder man definiert sich ein
Zwischenteil, z.B. 8=8, und kann dann einfach #t8 schreiben.
Aber Vorsicht ist geboten:
+- an irgendeiner Stelle des Abschnitts herauszuspringen, denn dann wird
der Rest nicht abgearbeitet.
#u1 enthält immer nur das, was im ak-Befehl ausgewählt wurde.
Man startet also einen Abschnitt #-X, der mehrere Schlüssel erzeugen soll, am besten mit
ak=zz+X, kann aber dann dort keine #u1 verwenden.
Das Verfahren eignet sich folglich eher für Schlüssel, die aus einzelnen, speziellen Kategorien entstehen sollen, nicht für Mehrfachkategorien und Zerlegungen von Kategorien. In den Erwerbungs- und Ausleihsystemen, wo man etliche ganz spezielle Schlüssel z.B. für einen Bestellsatz oder Exemplarsatz braucht, kann man am meisten davon profitieren. Die Grenze liegt aber nicht bei sieben, sondern die Gesamtlaenge der Schluessel darf 7.200 nicht überschreiten.
waren auf 32 Zeichen begrenzt, was gelegentlich Probleme machte. Diese Grenze wurde auf 64 hinaufgeschraubt, was dem Standard aller anderen Programme entspricht.
Wenn ein Indexeintrag länger als das Maximum wird, kürzt INDEX die Länge auf den Wert der Variablen
il. Wenn zufällig dann das letzte Zeichen ein Komma oder Leerzeichen ist, wurde dies von V14 nicht
entfernt. Die Folge konnten hinterher Fehlermeldungen von QRIX sein ("Ladefehler 59..."). Dieses Problem wurde beseitigt. PRESTO
und UPDATE hatten diesen Fehler nicht.
Die Exportsprache bietet, wie jede anständige Programmiersprache, die Möglichkeit, Endlosschleifen zu programmieren.
(Übrigens kann kein Compiler solche Schleifen zuverlässig entdecken, weil sie oft erst zur Laufzeit entstehen.) Wenn es
passiert, daß INDEX an immer derselben Stelle stehenbleibt, kann man sich so helfen: man startet mit der zusätzlichen
Option -eE-1/CON. Dann wird jeder indexierte Satz zusätzlich auf den Bildschirm ausgeworfen (mit der
Parameterdatei E-1.APR). Wenn das Programm dann stehenbleibt, sieht man, an welcher Stelle das passiert.
Wahrscheinlich ist es der Satz, der dem angezeigten Satz in der Datei folgt. Dessen Struktur muß man sich anschauen.
Das Programm hat sich als nützliches Werkzeug in der WWW-Anwendung bewährt. Es produziert die Registerausschnitte, die man abrufen kann. Im Zuge dieser Entwicklung wurden kleinere Verbesserungen vorgenommen. Für WWW wird in der Hauptsache mit einem Aufruf dieser Form gearbeitet, den man auch anderweitig einsetzen kann:
qrix -fd -x0 -ddatenverz -bdbn -w%1 -s%2 -M15 -Edatei -tnnn,ppp >auszug
Wenn man diese Zeile als Stapeldatei QR.BAT verpackt hat, kann man Aufrufe wie diesen machen:
qr 1 meier
Es entsteht eine Datei auszug mit bis zu 15 Zeilen, und zwar der Auszug aus Register 1, der mit "meier" beginnt.
Außerdem entsteht eine Datei namens datei, in der die internen Satznummern der zu den Registereinträgen
gehörigen Datensätze stehen, dahinter jeweils die Registerzeile. datei ist eine
allegro-Grunddatei mit dieser Zeilenstruktur:
[1]nnn Satznummer[0]ppp registerzeile[0][13][10] ([1] bzw. [0] sind die ASCII-Steuerzeichen 0 bzw. 1)
Für nnn wird als Default 00 angenommen, für ppp wird 20 angenommen. Die Angaben nnn und ppp müssen erlaubte Kategorienummern ohne Folgezeichen sein, und nnn muß VOR ppp liegen.
datei wird neu angelegt bzw. überschrieben. Mit -E+datei werden die neuen Daten
an datei angehängt.
Eine solche Datei kann SRCH einlesen und mit dem neuen Nachladebefehl ¦01 den zugehörigen Satz
laden, mit ¦00 die Kurztitelzeile. Mehr dazu unter "WWW-Methodik" auf S.9f.
QRIX liefert den ERRORLEVEL 11, wenn die Maximalzahl (durch Option -M) vorgegeben, überschritten
wird. Also im Beispiel, wenn es mehr als 15 Zeilen sind, die mit "meier" anfangen. Das kann man zur Steuerung benutzen.
Ladefehler 59
Dieser kann vorkommen, wenn die Stopwortliste in der Parameterdatei enthalten ist (statt mit einem Befehl wie tSWL1
nachgeladen zu werden) und wenn darin das Wort il vorkommt (italienischer
Artikel!). Dieses wurde dann mit dem Befehl il=... für die Schlüssellänge verwechselt, und
QRIX arbeitete als Folge mit einer falschen Schlüssellänge. Das neueste QRIX fällt darauf nicht mehr rein.
Immer mal wieder, wenn auch immer seltener, trat ein irritierender Datenfehler auf: nach einer Verlängerung wurde ein Datensatz nicht, wie er sollte, korrekt verlagert, sondern in einen zu kurzen Bereich geschrieben. Sein Hinterende überschrieb dann das Vorderende des nachfolgenden Satzes. Bei Einzelplatzbetrieb trat dieses zwar schon lange nicht mehr auf, aber in Mehrplatzdatenbanken. In der Hauptdatenbank der UB Braunschweig mit über 500.000 Sätzen konnte jetzt mit SNIFFER nach monatelangem Betrieb ein einziger solcher Fall identifiziert werden. Die Analyse der LOG-Dateien ergab, daß der Fehler entstanden sein mußte, als zwei UPDATE-Läufe gleichzeitig stattfanden. Nach diesem Befund war die Ursache dann schnell auszumachen und auszumerzen. Es besteht eine noch deutlich geringere Wahrscheinlichkeit, daß ein solcher Fall auch bei gleichzeitigem Arbeiten von UPDATE und intensiver PRESTO-Bearbeitung (z.B. mit globaler Ersetzung auf einer großen Ergebnismenge) aufgetreten ist. Deshalb wird empfohlen, bei Mehrplatzbetrieb ab sofort nur noch ein UPDATE mit Datum ab 23.6.95 einzusetzen, selbst wenn ansonsten noch nicht V14 in Betrieb ist.
Um größtmögliche Gewißheit zu erreichen, wurde ein Härtetest durchgeführt. Eine Datenbank mit sehr vielen Leersätzen wurde erstellt und dann durch zwei gleichzeitige UPDATEs zehn Stunden mit Daten bombardiert, von einem dritten Platz wurden noch zwischendurch Ergebnismengen-Löschungen und globale Ersetzungen mit Verlängerung gefahren. Am Ende konnte SNIFFER, wie erwartet, keinen Fehler finden.
In der Original-V14 arbeitete UPDATE nicht korrekt: die Ersetzungen wurden vorgenommen, die Indexierung war also in Ordnung, doch die Ersetzungen wurden mit gespeichert, d.h. die Stammsatznummern verschwanden. Das ist korrigiert.
Die Kategorie #u1 kann benutzt werden, um UPDATE zum Löschen von Sätzen zu veranlassen
(#u1 @@@@@) oder zum Speichern eines Satzes in einer bestimmten Datei (z.B. #u1 #####47,
um den Satz in die Datei 47 speichern zu lassen. Nur bei Option -fm01 wurde die Hilfskategorie #u1 beseitigt, bei
-fm11 etc. blieb sie stehen, was nicht sein sollte. Auch dieser Fehler ist korrigiert.
Die am Bildschirm durchlaufenden Meldungen über die Speicherung bzw. Ersetzung von Datensätzen werden bei der UNIX-
Version jetzt zusätzlich in eine Datei upro geschrieben; mit Option -xdatei kann man
eine andere vorgeben. Die PC-Version schreibt nur die Endergebnisse hinein.
Eine simple Änderung der Namen der Zwischendateien ermöglicht jetzt bis zu 9999 Zwischendateien mit jeweils bis zu 800 Sätzen, d.h. die Gesamtgröße der zu sortierenden Datei kann ca. 8 Millionen Datensätze betragen. Man informiere die Entwicklungsabteilung rechtzeitig, wenn noch größere Projekte anstehen.
[Kap.5.0/1]
Die dazu vorgesehenen Funktionen wurden verbessert. Während das Programm IMPORT läuft, können Sie folgende Tasten drücken:
ax-m1 ("manuelle Unterbrechung") gestartet wurde, stehen im
Arbeitsspeicher die letzten ca. 50 umgewandelten Datensätze zum Durchblättern und Bearbeiten
bereit. Mit <BildHoch> und <BildRunter> kann man darin blättern. Diese Funktion geht
jetzt auch, wenn man mit -m0 gestartet hatte. Es läuft dann schneller, aber man
hat nur jeweils den letzten Satz im Arbeitsspeicher.
Wenn man mit x in den Bearbeitungszustand gekommen ist, muß man diese zwei Editorbefehle kennen,
damit es weitergeht:
#r#e
[Kap.11.2.3.4, S.237]
Die Länge der Zeichenketten, die man in Konkordanzen verwenden kann, ist nicht unbegrenzt: maximal 255 Zeichen sind je
Zeichenkette erlaubt. In einer Parameterdatei dürfen insgesamt 26 Konkordanzlisten mit zusammen höchstens 1500 (bisher
1000) Paaren von Zeichenketten vorkommen. Die mögliche Gesamtlänge aller Zeichenketten hängt vom
verfügbaren Parameterspeicher ab. Dessen aktuelle Größe erfährt man im Editorzustand mit dem Befehl
#s. Das Maximum erreicht man, wenn man in der .CFG den Befehl mX64000 einsetzt.
Es kann aber sein, daß dann PRESTO nicht mehr mitmacht, also muß man evtl. für IMPORT eine eigene CFG
einrichten (der Befehl mr hat für IMPORT keine Bedeutung).
waren problematisch, wenn mehrere Positionierungsbefehle (s-Befehle) in einem Paragraphen vorkamen. Es konnten dann Teile wegfallen. Dies passiert nicht mehr.
[Kap.10.2.6.7, S.195]
Die Befehle für das Nachladen wurden so erweitert, daß man nun praktisch vollständigen Zugriff auf alle Bestandteile
der Datenbank hat. Bisher konnte man beim Nachladebefehl ¦im für i nur die Werte 1 bis 11
angeben, um auf die Register 1 bis 11 zuzugreifen. Weil bei den Index-Präfixen immer ':' statt 10 und ';' statt 11 geschrieben
werden muß, sind diese Zeichen jetzt auch beim Nachladen erlaubt, weil man hier zu leicht Fehler machte. Also:
¦;8 bewirkt genau dasselbe wie ¦118.
Eine weitere Verbesserung ist diese: der Arbeitstext entspricht nicht immer genau einem Indexeintrag oder dem Anfang eines solchen.
Dann kommt bisher kein Ergebnis heraus. Jetzt kann man folgendes tun: man setzt als Präfix "<" oder ">" vor den
Arbeitstext, der gesucht werden soll. Dann wird als Ergebnis bei "<" der nächstkleinere Eintrag genommen, wenn es einen
übereinstimmenden nicht gibt, bei ">" wird der nächstgrößere genommen. Gibt es einen genau gleichen
Eintrag, wird in beiden Fällen dieser genommen. Beispiel: als Arbeitstext hat man "plz38106" und will aus Register 7 damit
nachladen, im Register 7 gibt es aber nur "plz38000" und "plz38179". Die bisherigen Nachladungen liefern dann kein Ergebnis. Statt
z.B. ¦78 schreibt man nun p"<" ¦78, dann kommt
"plz38000" heraus, bei p">" ¦78 erhält man
"plz38179".
Außerdem kann i jetzt auch den Wert 0 annehmen. Damit dabei etwas herauskommt, muß zu dem Zeitpunkt der Arbeitstext eine interne Satznummer sein. Dann gibt es zwei Fälle:
¦00#ux0 kopieren. Beispiel:#nr ¦00 in #ux0 steht anschließend die
Kurzzeile des aktuellen Satzes.¦01¦im, auch mit
dem bedingten Sprung.-Enum.alg eine Datei num.alg,
in der die Satznummern der von QRIX gefundenen Indexeinträge stehen; weiter oben unter QRIX wurde das schon beschrieben.
Weiter unten werden in einem eigenen Abschnitt über die WWW-Methodik diese Neuerungen im
Zusammenhang dargestellt, dann wird das alles klarer.
[Kap.10.2.6.5.3, S.191]
Bei Listenproduktionen hat man immer mal wieder den Wunsch, am Ende der Liste noch eine statistische Zusammenfassung oder
ähnliches auszugeben. Bislang konnte dazu nur der Fußabschnitt der Parameterdatei genutzt werden. Dann aber mußte
man auf Seitenumbruch verzichten (also zm=0 setzen), damit der Fußabschnitt nur am Ende des Durchlaufs
abgearbeitet wird. Jetzt kann man zusätzlich einen Endabschnitt programmieren. Er muß beginnen mit einer besonderen
Sprungmarke, diese muß aber im Hauptabschnitt liegen:
#- ENDE
Das Wort ENDE ist als solches unwichtig, es kommt darauf an, daß genau ein Leerzeichen hinter dem #-
steht. (Das Leerzeichen konnte ansonsten bisher nicht als Sprungmarke verwendet werden.) In den darauf folgenden Zeilen programmiert
man alles, was am Ende der Liste erscheinen soll.
#nr[Kap.10.2.6.2, S.176]
Bei SRCH-Läufen enthält diese Variable die interne Satznummer, wenn eine .ALD-Datei durchgearbeitet wird, aber eine
mit 1 beginnende laufende Nummer, wenn eine .ALG-Datei (Grunddatei) verarbeitet wird. Für den letzteren Fall kann mit dem
Befehl an=n (Kap.10.2.1, S. 158) ein anderer Wert vorgegeben werden.
Bei zwei oder drei gleichzeitigen Exporten funktionierte die Zählung nicht richtig, was für V14a korrigiert wurde.
Zwei Beispiele von Parameterdateien werden mitgeliefert, in denen man den Umgang mit Nummern sehen kann:
I-
NR.APR
|
Ausgabe mit der internen Nummer in #00, 6stellig |
I-
LFNR.APR
|
Ausgabe mit laufender Nummer in einer neuen Kategorie. |
[Kap.10.2.0, S.156]
Mit dem Steuerbefehl #t{ N } und dem Manipulationsbefehl ... p{ N } ... kann man
erzwingen, daß eine neue Karte begonnen wird, obwohl die Karte, die gerade produziert wird, noch nicht voll ist. Dies sollte in
V12.2 schon funktionieren, der letzte Fehler wurde aber erst am 12.5.95 beseitigt.
[Kap.1.5, S.60]
Hier eine neue, einfache Methode, den Datensätzen Identnummern zu verpassen, wenn sie noch keine haben:
man macht sich eine kleine Parameterdatei namens NUMMER.APR, die nur diese drei Zeilen enthält:
#-# notwendige Sprungmarke #00 +- Wenn #00 besetzt, nichts machen #nr r6,0 p"#00 " M interne Nummer in #00 schreiben
Dann startet man PRESTO mit diesem Befehl:
presto -a3 -enummer/nul ...
Wenn man nun auf Einzelsätze oder Ergebnismengen die Funktion <
Strg>+F10 anwendet (Globale Manipulation), wird die interne Nummer in Kategorie #00 eingetragen und zum Datensatz hinzugefügt. (Bei V14 ging dies noch nicht, da die Kategorie #nr in diesem Zusammenhang nicht funktionierte.)
[10.2.6.1, S. 173]
Der Wiederholungsbefehl
#xx ++ ...
zur Abarbeitung aller Kategorien #xxf funktionierte nicht, wenn er innerhalb von Unterprogrammen benutzt wurde. Jetzt geht es. Wenn
man nicht weiß, welches die erste besetzte Kategorie #xxf ist, schreibt man #xx. ++ ...,
dann sucht sich das Programm selbst die erste und arbeitet diese und alle weiteren ab.
[Kap.10.2.6.4, S.188]
Ein Befehl der Form #tn mit einer Zwischenteilnummer n ist keine Sonderkategorie, sondern ein
Steuerbefehl. Er bewirkt nur, daß Zwischenteil n ausgegeben wird, sonst nichts. Daher sind in solchen Zeilen keine
Manipulationsbefehle möglich.
Einige der "amtlichen" Parameterdateien mußten geringfügig korrigiert werden. Es handelt sich um:
S.APT
|
Tabelle der Sortierwerte. Einige neue Zeichenwerte wurden ergänzt. Der Befehl
q ¬
1 muß heraus, sonst funktioniert z.B. !20 b3 u
nicht. |
ALPHA2.APR
|
Die letzte Befehlszeile lautet jetzt#99z =sn,1 f" " p", "Vorher stand darin =sn,0 - dann wird der Rest der Zeile nicht mehr
ausgeführt. |
S-
KURZ.APT
|
Die Sprungmarken #-A und #-B sind
ungünstig, sie können leicht auch in der gewählten Datei |
S-
MITTEL.APT
|
des Typs S-*.APR auftreten. Sie wurden durch Kategoriesprünge ersetzt. |
Viele andere Parameterdateien wurden ausgebaut und verbessert.
Die Tabelle P-0.APT kann als Prototyp für neue Druckertreiber genommen werden. Sie enthält erstens die Nummern der Zwischenteile für die Schriftarten, zweitens Listen von p- und q-Befehlen für alle Zeichen des erweiterten Satzes OSTWEST.FON. Diese Tabelle muß man nur noch mit den Werten des eigenen Druckers ausfüllen.
Zur Umcodierung der Zeichen für die Register dient die Tabelle I.APT. Sie ist ebenfalls an den erweiterten OSTWEST.FON
angepaßt. Man setzt lediglich den Befehl ti in die eigene Index-Parameterdatei ein, dann braucht man
darin nicht die langen Listen der p- und q-Befehle mitzuschleppen.
Etwas anderes als die p- und q-Befehle sind die i-Befehle, die man ebenfalls in einer Indexparameterdatei anwenden kann. Diese machen keine Umcodierung! Sie sagen nur etwas über den Sortierwert der Zeichen im Index, die Zeichen selbst bleiben unverändert. Wenn man etwa das türkische "dumpfe " (i ohne Punkt) zwischen i und j sortieren möchte, wie es die Türken tun, müßte man schreiben (als Ergänzung der CAT.API)
p I in Normaltabelle: durch I ersetzen i 106 Zeichen erhält den Sortierwert 106 i j/z 107 j erhält 107, k 108 usw. bis z
Das bedeutet: bekommt den Sortierwert 106, das ist sonst der Wert von 'j'. Das 'j' und alle nachfolgenden Buchstaben rücken eine Position weiter, 'j' auf 107, 'k' auf 108 usw. bis 'z'. Alle anderen Zeichen werden standardmäßig nach ihrem ASCII- Wert sortiert. Auswirken wird sich dies nur, wenn die Alternativtabelle benutzt wird (wenn also !nn statt #nn geschrieben wird), weil das Zeichen in der Normaltabelle durch I ersetzt wird.
In deutsche OPACs wird man genau dieses nicht einbauen, sondern
p I q i
Dann wird im Index das durch ein "normales i" ersetzt und folglich auch so geordnet. Diese Zeilen sind in der Tabelle I.APT enthalten. Die i-Befehle wurden übrigens ursprünglich entwickelt, um kyrillische Zeichen mit ukrainischen Sonderzeichen benutzen und diese korrekt sortieren zu können.
[Kap.10.2.2/3, S.164f]
Auf die Druckseite müssen mindestens zm + z2 + ff Zeilen passen. Ausgenutzt werden mindestens
zm Zeilen, z2 werden als Toleranz zugegeben, wenn der aktuelle Datensatz dann noch komplett
paßt. Der Fußabschnitt, aber nur falls einer definiert ist, beansprucht dann ff Zeilen, also eine oder zwei.
Ein Kopfabschnitt zählt mit innerhalb der Zahl zm. Es muß ff auf 1 oder 2 gesetzt
werden, auch wenn es keinen Fuß-, sondern nur einen Kopfabschnitt gibt. Bisher war es so, daß der Kopfabschnitt noch eine
Leerzeile erhielt, wenn ff=2 war. Das ist nicht mehr so; man muß folglich am Ende des Kopfabschnitts evtl.
noch ein #t{ C } setzen, um dasselbe wie vorher zu erhalten.
Es gab ferner immer mal Probleme mit der ersten Seite. Jetzt hat sie dieselbe Anzahl Zeilen wie alle anderen.
und Leerzeichen kam oft am Zeilenanfang vor. Interne Korrekturen sorgen dafür, daß sich das Programm nicht mehr solche Eigenmächtigkeiten erlaubt.
Die i-Befehle, siehe oben, wurden im Handbuch vergessen. Sie gehören in einen neuen Abschnitt 10.2.4.5.
In der Tabelle des Abschnitts 10.2.6.3 (S. 179) ist das direkte Präfix pX als nicht wiederholbar mit * markiert.
Das ist falsch, es ist wiederholbar - besonders wichtig ist dies jedoch nicht, denn man könnte alles zu einem Präfix
zusammenfassen, statt zwei oder drei zu machen. In der Beschreibung S. 184/185 allerdings muß darauf hingewiesen werden,
daß die indirekten Präfixe pz und p>K mehrfach in einer Zeile auftreten
können, der Befehlstyp p{ CS } und alle Postfixtypen aber nur einmal.
Die meiste Arbeit steckt beim WWW-Zugang in einem "HTML-Skript". Das ist praktisch ein Programm, welches die Texte anzeigt, Benutzereingaben entgegennimmt und auswertet, Programme aufruft und deren Ergebnisse präsentiert. Die Zugriffe auf die allegro-Datenbank, die dabei unter der Oberfläche ablaufen, sind erstaunlich einfach und konnten ohne WWW-spezifische Eingriffe in die Programme realisiert werden, obwohl ein paar allgemein nützliche Verbesserungen eingebaut wurden, die es in V14 noch nicht gab. Diese Neuerungen wurden schon in den Abschnitten über SRCH und QRIX erwähnt. Hier legen wir offen, wie die Methode im Kern funktioniert, und zwar so, daß man auch ohne WWW etwas damit anfangen kann. Eine ausführliche Dokumentation einschließlich der HTML-Texte ist von Dierk Höppner erarbeitet worden und auf dem FTP-Server zugänglich. Über die WWW-Leitseite der UB können Sie auch einen informatorischen Text über die Hintergründe der Geschichte abrufen.
Es folgt eine Stapeldatei XT.BAT und eine Export-Parameterdatei E-XT.APR (XT steht für "extract"). Beide stellen das Minimum dar und sind beliebig ausbaufähig. Die Lieferdiskette enthält die Dateien. Probieren Sie es mit der DEMO- Datenbank aus, dann werden Sie auf den Geschmack kommen.
XT.BAT @echo off : Abfrage nach Suchbegriff: echo geben Sie einen Namen ein (klein geschrieben): reply : Satznummern ermitteln und in xxxnum.alg schreiben: qrix -w1 -dc:\allegro\demo -x0 -M20 -Exxxnum.alg -fd -s%REPLY% -S%REPLY%zz >nul if errorlevel 11 echo Mehr als 20 Eintraege! : Datensätze holen und per E-XT.APR nach XT.TXT exportieren: srch -f6 -dxxxnum.alg -bc:\allegro\demo\cat -eE-XT/xt.txt -m0 -s0 -v0 -kA : Datei anzeigen: v xt.txt
Für den Einsatz in Ihrer eigenen Umgebung sind zunächst nur die fettgedruckten Teile durch die entsprechenden Namen Ihrer Dateien und Verzeichnisse zu ersetzen. Weitere Variationen und Erweiterungen, die sich anbieten, sind diese:
-w1 im QRIX-Aufruf durch andere Ziffer(n) ersetzen, um auf andere Register zuzugreifen. Man kann eine
Auswahl mehrerer Register vorschalten und die '1' durch eine Variable ersetzen. Die mitgelieferte XT.BAT zeigt, wie das aussehen
kann.
E-XT/xt.txt durch eigene Angaben ersetzen. Beispielsweise kann statt E-XT eine Datei des
Typs S-*.APR eingesetzt werden, allerdings modifiziert, wie Sie es unten in XT.APR sehen. Das Ergebnis ist dann eine Grunddatei, die
man zunächst sortieren und in einem weiteren SRCH-Aufruf mit einer Datei des Typs P-*.APR in eine präsentable Form
umsetzen kann. So läuft es in der WWW-Anwendung. Mitgeliefert wird auch noch eine I-XT.APR.
Die Option -M20 dient zur Begrenzung der Ausgabe von QRIX: es werden nur die ersten 20 passenden
Registerzeilen verarbeitet. Wenn die Trefferzahl größer ist, entsteht eine unvollständige Ausgabedatei! Der
ERRORLEVEL ist dann 11 (siehe oben unter QRIX). In der Datei xxxnum.alg, die QRIX produziert, stehen die Satznummern, jeweils
in einer Kategorie #00, die für sich allein einen Datensatz bildet. (Mehr darüber wurde im Abschnitt über QRIX
gesagt.)
Hier folgt die Export-Parameterdatei E-XT.APR, in der Sie sehen, wie die Extraktion der Datensätze funktioniert:
--------- Konstanten --------------------------------------------
zl=66 Zeilenlänge
zi=4 4 Zeichen Einrückung bei Folgezeilen
zi=5 bei 3stelligem Schema (einzige Änderung!!!)
zm=0 kein Seitenumbruch (fortlaufende Ausgabe)
ae=13 10 Zeilenvorschub am Aufnahme-Ende
fl=0 Listenstruktur (keine Karten)
ks=0 Startpos. 0 (= Zeichen '#') innerhalb jeder Kategorie
ks=1 (setzen, wenn '#' wegfallen soll)
ke=C Kategorie-Ende: Zeilenvorschub
********* Kategorieliste ****************************************
Die von QRIX erstellte Datei xxxnum.alg wird hiermit verarbeitet:
Die nächste Zeile ist die entscheidende: (siehe auch I-XT.APR)
#00 b4 ¦
01 #zz 0 Datensatz laden (in #00 steht seine interne Nr!)
## sämtliche Kategorien ausgeben in interner Reihenfolge
In der mitgelieferten Datei finden Sie noch ausführlichere Kommentare.
Wenn Sie statt XT.APR eine modifizierte Datei des Typs S-*.APR einsetzen, können darin keine ak-Befehle verwendet werden. Die einzige zu exportierende Kategorie ist ja #00, und ein ak-Befehl kann sich nicht auf einen nachzuladenden Satz beziehen. Einfacher ist es, aber etwas mehr Zeit braucht es, wenn Sie zuerst eine unsortierte Grunddatei erstellen lassen, und zwar mit I-XT.APR, und diese dann in zwei SRCH-Läufen zu einer sortierten Liste aufbereiten.
E-mail-Adresse: allegro@mpim-bonn.mpg.de
An diese Adresse schickt man eigene Mitteilungen, die dann von allen Teilnehmern empfangen werden. Wenn Sie Ihrerseits alles lesen wollen, was die anderen schreiben, senden Sie an die Adresse
listserv@mpim-bonn.mpg.de (aber bitte nur an diese, nicht an die oben genannte!)
die Meldung
subscribe allegro Vorname Nachname... und später, um sich abzumelden: unsubscribe allegro
dann geht das seinen Gang, d.h. Sie bekommen ab sofort etwas mehr Post als vorher, und Sie können
Fragen und Kommentare an die ganze Runde schicken, also an die Adresse allegro@mpim-bonn.mpg.de
.
Datum der letzen Änderung: 05.07.95
© 1995, UB Braunschweig
Bernhard Eversberg (b.eversberg@tu-bs.de)