Universitätsbibliothek der Technischen Universität Braunschweig, Universitätsplatz 1, D-38106 Braunschweig, Tel. (0531)391-5026, FAX-5836
Der Zufall gibt dem Leben Würze, weshalb man ihm ganz gern mal etwas überläßt. Ganz falsch wäre z.B. die Vorstellung, die allegro-Entwicklung sei nach einem sorgfältig ausgetüftelten Projektplan verlaufen. Natürlich wurden immer wieder Pläne gemacht, doch die im Jahre 1980 beginnende Entwicklungsgeschichte wurde von Anfang an durch eine lange Kette von Zufällenbegünstigt. Oder sollte man sagen, daß immer wieder gute Gelegenheiten ergriffen wurden, statt an einem Plan zu kleben? Ein Projekt mit einer Laufzeit von bald 14 Jahren hätte man sowieso unmöglich planen können - man bedenke nur, daß z.B. MS-DOS 1980 noch gar nicht erfunden war. Stoff genug läge tatsächlich vor für einen bibliothekarischen Roman - doch wer soll ihn schreibenund wer würde ihn lesen? An dieser Stelle ist ganz sicher nicht der Ort, damit zu beginnen. Statt dessen soll und muß es hier einmal um die unerfreulichen Zufälle gehen, denen man keine Chance geben sollte, und für die man einen Plan in der Schublade haben muß. Eine Art Überlebensplan!
Wer sich mit Computern einläßt, wird sehr bald mehr oder weniger von ihrem korrekten und zuverlässigen Funktionieren abhängig.Ist erst einmal die Schreibmaschine nicht mehr da, werden PC- oder Druckerdefekte zu einer gefürchteten Malaise. Hat man sich dann aber sogar des Zettelkatalogs entledigt, geht ohne Rechner so ziemlich gar nichts mehr. Ist man vernetzt und liegen alle Daten auf einem Server, wird dessen Ausfall zum absoluten Alptraum. Und selbst wenn Soft- und Hardware nie versagen: einzufälliger Stromausfall legt schlagartig den Betrieb lahm. So abhängig war man früher nicht: mit Taschenlampe konnte man zur Not noch alles finden. Im Zettelkatalog, aber nicht mehr auf einer stillstehenden Festplatte! Und wenn der Strom zurückkommt, kann die Datenbank Schaden genommen haben. Das merkt man sofort daran, daß der Index nicht mehr erscheint. Wohl dem, der dannsofort auf eine Sicherungskopie zurückgreifen kann. Dieses Thema muß hier nicht vertieft werden, denn das Systemhandbuch vermittelt das dazu notwendige Knowhow, und das CockPit unterstützt die schnelle und sichere Wiederherstellung einer defekten Datenbank (Kap. 0.7). Das Sichern größerer Datenbestände wird mit den heutigen Bandkassettensystemen (sog. "Streamer-Tapes") zueiner sehr einfachen Routinesache, aber dran denken und es anstoßen sowie die Kassetten in Ordnung halten muß man schon immer noch! In Netzen ist es eine bequeme Alternative, wenn kein Kassettenlaufwerk da ist, eine Datenbank vom Server auf die genügend große Festplatte einer Arbeitsstation zu kopieren. Hat man ausreichend Raum auf den Platten des Servers, kann man einezusätzliche Kopie der Datenbank (nicht anstatt der Bandkopie, denn der Server könnte ja als Ganzes kaputtgehen!) auf einem anderen Verzeichnis unterbringen. Nach einem Zusammenbruch kann man sofort die .LOG-Datei mit UPDATE in die Kopie "einfahren" lassen, und während dies läuft, ist sogar die Datenbank schon wieder benutzbar. Wenn man eine Routine konstruiert, die jedenTag die .LOG-Datei auf das andere Verzeichnis kopiert (und sie auf dem echten Verzeichnis löscht!) und dann den UPDATE-Vorgang (s.u. "LOG2ALG") macht, wird der Zeitverlust sehr gering.
Will man absolut nichts dem Zufall überlassen, muß man außer der Datenbank auch die Parameterdateien und Stapelprogramme (.BAT-Dateien) sichern. Das leuchtet jedem ein, der selbst solche Dateien erstellt hat, denn es steckt viel Zeit drin. Wer regelmäßig
die gesamte Platte auf Band abzieht, hat in diesem Punkt keine großen Sorgen, wer nur per CockPit die Datenbank sichert, sollte
jedoch diese Dinge ebenso regelmäßig von Hand machen oder sich eine Batchdatei mit den nötigen copy -Befehlenanlegen. Dazu ein Tip: mit dem Befehl
xcopy *.?p? a: /d:10.3.94 /s
eingegeben auf dem Verzeichnis ALLEGRO, sichert man z.B. alle Export- und Index-Parameterdateien, die sich auf dem Programmverzeichnis und dessen Unterverzeichnissen befinden und seit dem Datum 10.3.94 geändert wurden. Dazu reserviert man sich nur eine Diskette, das reicht, und schiebt sie jedesmal vorher ins Laufwerk A:. Auf der Diskette entstehen dannautomatisch dieselben Unterverzeichnisse, die man auf der Platte hat! Mit ähnlichen Befehlen sichert man, wenn gewünscht, die Importparameter und Hilfs- sowie UIF-Dateien oder was immer man sonst noch für sicherungswürdig hält. Und die Programme? Solange man die Originaldisketten der letzten Version (und davon noch eine Sicherungskopie) greifbar hat, braucht man dieProgramme nicht zu sichern. Im Fall des schlimmsten Desasters läßt man sich eine neue Diskette aus Braunschweig kommen, oder man bedient sich der Mailbox oder des FTP-Servers. Oder man kennt andere Anwender in der Nähe. Die Programme sind als solche zum Glück so gut wie unzerstörbar, weil sie so weit verbreitet sind. (Für alle, die es ganz genau wissen wollen: die Originaleder Programme, die sog. "Quellcodes", sind selbstverständlich in der besten möglichen Weise gesichert.)
Immer wieder wird nach einer "Demo-Diskette" gefragt. So etwas kann man nicht "schnell mal eben" zusammenschustern. Und da ineiner Entwicklungsabteilung stets mehr Aufgaben anliegen als Zeit vorhanden ist, sie zu lösen, muß man Prioritäten setzen. Die UB Braunschweig arbeitet nicht als gewinnorientiertes Softwareunternehmen, deshalb konnte die Erstellung einer Demo-Diskette keine hohe Priorität bekommen. Nach Fertigstellung von Version 13 wurde aber die Notwendigkeit gesehen, die neuen Fähigkeitendieser Version in Form einiger Beispieldatenbanken in verschiedenen Formaten demonstrieren zu können. Es entstand eine Demo- Diskette mit fünf verschiedenen Datenbanken: MAB, USMARC, UNIMARC, Pica, und NMN ("konsolidiertes allegro-Format). Alle fünf sind mit echten Daten aus einer authentischen Quelle gespeist worden. Die Parametrierung wird in den Einzelheiten (besondersbeim UNIMARC-Format) noch zu wünschen übrig lassen. Mitgeliefert werden das CockPit und ein abgespecktes PRESTO.EXE, so daß man die Datenbanken leicht besichtigen kann. Für diesen Zweck wurde die Demo-Disk erstellt, nicht als Werbemittel!
Generell wird deshalb weiterhin jedem, der sich für allegro interessiert, empfohlen, einen versierten Anwender aufzusuchen,sich den praktischen Einsatz anzusehen und mit Leuten zu sprechen, die routinemäßig mit dem System arbeiten. Daraus erhält man Eindrücke, die eine Demo-Version nicht vermitteln kann.
Wer meint, von der Demo-Diskette profitieren zu können, kann sie von der UB Braunschweig erhalten (siehe beiliegenderBestellschein). Auch auf dem FTP-Server und in der Mailbox finden Sie dieses Angebot jetzt vor, sogar kostenlos.
[Korrektur 31.1.94]
Auch Version 13 ist nicht perfekt. Das nachfolgend beschriebene Problem ist behoben worden. Wer davon betroffen ist (Datum von PRESTO.EXE vor dem 31.1.94) kann mit dem beiliegenden Bestellschein eine Nachbesserungs-Diskette anfordern. Die korrigierten Programme liegen natürlich auch auf dem FTP-Server und in der Mailbox.
Wenn man bei der Bearbeitung eines mehrbändigen Werkes den Editorbefehl #m einsetzt, um einzelne Bände zu verschieben, kann es passieren, daß auf einmal die nachfolgenden Bände nicht mehr da sind. Abhilfe: Nach dem #m-Befehl den #s-Befehl geben. Dann sieht man, wieviele Haupt- und Unteraufnahmen im Arbeitsspeicher sind. Bei "Hauptaufnahmen" sollte immer eine 1 stehen. Wenn es eine 2 ist: zu der Bandaufnahme gehen, die hinter der verschobenen steht, dort auf die #01 fahren und <Enter> drücken. Mit nochmaligem #s überzeugen, daß nun bei "Hauptaufnahmen" wieder 1 steht, erst dann mit F10 speichern.
Das ist für die Dauer zu undurchsichtig und umständlich. Wer also hierarchische mehrbändige Werke hat (andere sind nichtbetroffen) besorge sich die aktualisierten Programme.
[Korrekturdatum: 11.3.94]
Die globalen Ersetzungen wirken sich nicht auf nachgeladene Datensätze aus. Diese manchmal ärgerliche Tatsache erklärt sich so:
das Ausführen der globalen Ersetzungen ist die erste Handlung des Exportmoduls, danach erst beginnt es mit der Abarbeitung der
ak -Befehle und der Kategorieliste. Während der Abarbeitung der Kategorieliste kann jederzeit ein Nachladebefehl
angetroffen werden. Dieser wird dann ausgeführt, aber, wie gesagt, die globalen Ersetzungen sind zu diesem Zeitpunkt schon
erledigt. Da nun dieser Sachverhalt schon vielfach Unmut gestiftet hat und die Erwartung plausibel und berechtigt ist, daß
Ersetzungen sich auch auf nachgeladene Aufnahmen auswirken, wurde die Nachladefunktion intern so ergänzt, daß gleich nach dem
Nachladen, bevor es also mit dem Export weitergeht, automatisch die Ersetzungen ausgeführt werden - ganz gleich, wieviele
Nachladungen man macht. Natürlich kann dies ein wenig Zeit kosten.
[24.2.94]
Mit <Esc>0 (im Editor) bekommt man seit langem das aktuelle Datum mit Uhrzeit. Wenn man nun NUR das Datum als Phrase möchte: man setze in der .CFG den Befehl D8 ein und betätige dann <Esc>Leertaste. (Anmerkung: die <Esc>-Taste ist, anders als <Shift>, <Strg> und <Alt>, zuerst zu betätigen und dann loszulassen, bevor man die nächste Taste drückt; siehe Befehl #p in Kap.3.)
[24.2.94]
Wollte man z.B. auch die zweiziffrigen Zahlen oder die Jahreszahlen aus dem Stichwortregister ausblenden, war das bisher nicht möglich, man hätte eine allzulange Stopwortliste machen müssen. Jetzt wurde dies verbessert: mit dem '?' als Joker lassen sich die genannten Fälle elegant lösen: man gibt etwa "19??" an, dann werden alle vierstelligen Einträge, die mit "19" beginnen, ausgeschlossen. Betroffen sind die Programme PRESTO, LARGO und INDEX.
[24.2.94]
Bislang konnte man nicht sehen, ob und welche globalen Ersetzungsbefehle zu einem Zeitpunkt gerade im Arbeitsspeicher definiert
waren. Man mußte zur Sicherheit den Befehl #X_ geben und die gewünschte(n) Ersetzung(en) neu eingeben. Jetzt
bekommt man eine Anzeige der momentan definierten Ersetzung(en), wenn man den Editorbefehl #p <Enter> a e
gibt. Es erscheint dann eine u.U. lange Liste von Zahlenwerten, am Ende aber sieht man die vorher eingegebenen
Ersetzungsbefehle.
[Änderung am 23.3.94]
Bisher wurde die Nummernvergabe nur bei neuen Datensätzen ausgeführt. Jetzt erfolgt sie generell bei jedem Speichern, wenn die
vom Befehl cg definierte Kategorie nicht belegt ist, oder wenn in dieser Kategorie ein '?' vorkommt. Also: auch
ein korrigierter Satz erhält eine neue Nummer, wenn eine dieser Bedingungen erfüllt ist!
An dieser Stelle sei Annemarie Tews in Leipzig gedankt, die mit freundlicher Beharrlichkeit die Vorschläge für die vier zuletzt genannten Verbesserungen machte.
Das OPAC-Programm APAC.EXE ist ein abgewandeltes PRESTO.EXE. Einerseits hat es keine Schreibfunktionen (wo käme man da auch
hin), andererseits gibt es aber ein Menü zur Unterstützung des Benutzers, auszulösen mit der <Esc>-Taste. Damit das
funktioniert, braucht APAC eine zusätzliche UIF-Datei, und zwar die UIFA. Mitgeliefert wird sie unter dem Namen UIFAGER. Wenn
man nicht mit dem konsolidierten Format und mit KAT.API oder der neueren CAT.API arbeitet, muß man UIFA für die eigene
Datenbank anpassen! (Bearbeitung über CockPit µd m .) Mindestens die Namen der eigenen Register wird man ändern
müssen. Man sieht in der Datei aber unmittelbar, wo und wie man diese Dinge einzutragen hat. Auch die Bezeichnungen der anderen
Menüpunkte und die Hilfszeilen dazu dürfen anders formuliert oder auch weggelassen werden.
Wenn man mehrere Datenbanken auf verschiedenen Verzeichnissen hat, legt man am besten auf jedes der Verzeichnisse eine eigene UIFA, die der jeweiligen Datenbank entspricht.
APAC braucht ansonsten, wie PRESTO, die Dateien UIF0 und UIF1. Diese brauchen nicht datenbankspezifisch angepaßt zu werden,liegen deshalb am besten auf dem Programmverzeichnis. Die Zeile 186 mit der Überschrift kann man auch in die UIFA verlegen!
Will man den OPAC-Benutzern ermöglichen, Daten zu exportieren (also zu drucken oder auf Diskette zu speichern), muß man APAC
mit einer Option -e param/filename starten, wobei param der Name der zu benutzenden Parameterdatei ist, filename
die Exportdatei, wohin die Daten gehen sollen. Achtung: Schreibberechtigung muß erteilt sein! (Oder filename=PRN, wenn die
Ergebnisse auf den angeschlossenen Drucker gehen sollen!).
Hat man so eine Option angegeben, erscheint im Menü auf dem Anzeigebildschirm (nicht auf dem Registerbildschirm) der zusätzliche Punkt exportieren.
Wahlweise kann auch mit <Alt>+F4 (statt F4 wie bei PRESTO) exportiert werden. Noch eine, allerdings wenig komfortable
Möglichkeit: man gibt beim APAC-Start -a1 -n1 zusätzlich an. Im Anzeigebildschirm wird dann beim ersten
<Alt>+F4 die Auswahlliste der Parameterdateien geboten; man wählt eine aus und muß dann noch einen Dateinamen geben.
Anschließend kann man mit <Alt>+F4 beliebig viel exportieren, doch erscheint der Punkt nicht auf dem Menü. Außerdem hat
man (wegen -a1 ) nicht die richtige Überschrift im Anzeigebildschirm. Diese Ungereimtheiten sollen in einerkünftigen Version verschwinden.
Die mit Version 13 gelieferte Beispieldatenbank enthält auch einige Zeitschriftenbestandssätze und sogar Exemplarsätze füreinzelne Bände. Wenn Sie die Zeitschrift "Angewandte Informatik" über Register 5 aufsuchen, werden Sie die Bestandssätze unter
der Titelaufnahme sehen. Sie werden über das Register 10 nachgeladen. In das Register 10 kommen Sie mit <Alt>+0. Unter
zcsz300 finden Sie die Angaben zur Zeitschrift "Angewandte Informatik". Die Exemplarsätze werden nur auf
besondere Anforderung gezeigt, und das geht so: man startet APAC oder PRESTO mit der zusätzlichen Option -q band
. Dadurch wird BAND.APR als zusätzliche Parameterdatei geladen. Hat man die "Angewandte Informatik" auf dem Bildschirm,
gibt man bei PRESTO F3 und bei APAC <Shift>+F3. Dann erscheint unten ein Eingabefenster mit der Aufforderung, eine
Jahreszahl einzugeben. Geben Sie versuchsweise "197" ein. Sie erhalten die Anzeige aller Bände aus den 70er Jahren. Geben Sie
"1973", dann kommt nur der Band von 1973. Geben Sie "1" oder "19", dann kommen alle Bände.
In der BAND.APR können Sie studieren, wie das gemacht wird. Der neue Befehl #q kommt dabei zum Einsatz, um die
Antwort des Benutzers einzuholen, die dann in #uxq gespeichert wird.
Die Indexierung der Bestands- und Exemplardaten ist ein kompliziertes Thema für sich. Die dafür nötigen Abschnitte in der neuen CAT.API sind länglich und kompliziert. Diese Methodik soll allerdings ja auch mehrere Dinge zugleich leisten: eine flexible Erfassung und rationelle Speicherung von Beständen ermöglichen, die Daten in einer sinnvollen Reihenfolge im Register darbieten, und die für Ausleihe und Erwerbung notwendigen Elemente bereithalten. Damit nicht dieses Räderwerk für dieunterschiedlichen Kategoriesysteme jeweils neu erfunden werden muß, wurden erstens die Kategorienummern für Bestände (#9DF und #9DG) so gewählt, daß sie in jedem System verwendet werden können (in MAB muß man ohnehin von MAB-Lokal abweichen!), und zweitens wurde die Parametrierung so konzipiert, daß man die kommentierten Teile aus CAT.API in andere Index-Parameterdateien kopieren kann. Als Sprungmarken wurden einige Grafiksymbole verwendet, die vermutlich ansonsten kaum in Gebrauch sind.
konnte Update eigentlich schon ab Version 12.2. Erst nach Auslieferung von Version 13 wurden die Möglichkeiten noch etwas
verbessert. Bisher war die Bedingung: ein zu löschender Satz muß als erstes Byte den Code 9 statt 1 haben, und er muß
mindestens alle Kategorien enthalten, die zur Bildung des Primärschlüssels nötig sind. Die zweite Bedingung muß immer gelten,
aber statt der ersten ist jetzt auch folgendes möglich: der Satz beginnt mit Code 1, aber als erste Kategorie die Zeichenkette
" u1 @@@@@ " (5mal "Klammeraffe". Die #00 käme also erst dahinter!). Warum dieses? Nun, eine Grunddatei mitsolchen Datensätzen läßt sich vor dem Update-Vorgang noch editieren (mit dem Programm ALLEGRO.EXE) oder exportieren (mit
SRCH.EXE), was mit den Sätzen des anderen Typs (Code 9 am Anfang) nicht geht - die würden als gelöschte Sätze rausfliegen.
Besonders interessant wird dieses im Zusammenhang mit einer weiteren neuen Funktion:
[Neuerungen wirksam ab 21.3.94]
Ein kleines Zusatzprogramm namens LOG2ALG (das spricht sich "LOG to ALG") wandelt die .LOG-Datei einer Datenbank um in eine
Grunddatei des Typs .ALG. (Wenn man nicht A.CFG verwendet, muß man noch die Option -k anhängen.) Man gibt
schlicht den Befehl log2alg datenpfad -kc , dann wird aus einer XYZ.LOG eine XYZ.cLG erzeugt. Die gelöschten
Sätze stehen ebenfalls darin, aber seit neuestem mit der zusätzlichen Kategorie #u1 @@@@@ . (Vorher bekamen sie
vorn den Code 9, siehe oben.) Neue Datensätze erhalten die Zusatzkategorie #u1 #####n mit der n als Dateinummer
für die Speicherung des Satzes (UPDATE speichert dann den Satz in Datei n). Damit hat man nun folgende Möglichkeit: aus der
XYZ.ALG kann man mittels SRCH beliebige Teilmengen extrahieren (Export mit PA.APR). Solche Extrakte kann man zum Einmischen an
andere Datenbanken übergeben. Ist etwa die fragliche Datenbank so etwas wie ein Zentralkatalog, kann man für angeschlossene
Teilnehmer, die ihrerseits allegro-Kataloge haben, diejenigen Sätze aus der .LOG-Datei herausziehen, die den jeweiligen Bestandbetreffen. Der Teilnehmer mischt dann diese Daten mit update -fm41 wieder bei sich ein.
Wenn man selber eine Grunddatei mit #u1 -Kategorien der beschriebenen Form erstellt, werden diese Sätze von
UPDATE natürlich auf dieselbe Art behandelt. Damit hat man nun die Aktualisierung einer Zieldatenbank vollständig unter
Kontrolle.
Noch ein Anwendungsfall: man hat einen Dienst- und einen Publikumskatalog. Der Dienstkatalog enthält gewisse Sätze, die nicht in den Publikumskatalog sollen, oder es gibt Kategorien, die nur im Dienstkatalog existieren sollen. Jetzt kann man aus der .LOG-Datei mit geeignetem Export genau das erstellen, was dann in den Publikumskatalog einzumischen ist. Dank der neuen Behandlung der Löschsätze erfolgen dann auch die nötigen Löschungen in der Zieldatenbank!
Die korrigierten Programme UPDATE und LOG2ALG sind ebenfalls auf der erwähnten Diskette, die man bei der UB Braunschweig erhalten kann, sie sind natürlich auch auf FTP und Mailbox.
Datumsangaben hat man in der Regel in der Form JJMMTT gespeichert (also z.B. 940207 statt 7.3.94), denn nur so können sie korrekt sortiert werden. Gelegentlich tritt die Frage auf, wie man die Differenz zweier Datumsangaben in Tagen ermitteln kann. Das läßt sich, wie unten in knapper Form gezeigt, mit den Rechenbefehlen lösen:
Nehmen wir als Beispiel an, #99d enthält zwei Datumswerte, und zwar in den Teilfeldern D (Enddatum) und d (Anfangsdatum). Das sieht dann z.B. so aus:
#99d D940127 d921009 , das sind also der 27.1.1994 und der 9.10.1992 (wofür auch immer).
Es wird außerdem gezeigt, wie man das Ergebnis ganz einfach so aufbereiten kann, daß eine absteigende Sortierung (die größten Zahlen nach oben) möglich wird: man subtrahiert eine genügend große Zahl (hier 10000), nimmt vorn das Minuszeichen weg, macht das Ergebnis 5stellig und gibt es als #u1 aus. Die unveränderte Zahl kommt in #u2 und kann hinterher zum Ausdrucken verwendet werden.
...#99d D b2 e2 =m1 Datum D wird zerlegt: Tage in #ut1, Monate in #um1, Jahre in #uj1
#99d D b4 e2 =t1 d.h., aus #99d D940123 (für den 23. Januar 1994)
#99d D e2 =j1 entstehen: #uj194 , #um101 , #ut123#99d d b2 e2 =m0 Datum d wird zerlegt: Tage in #ut0, Monate in #um0, Jahre in #uj0
#99d d b4 e2 =t0
#99d d e2 =j0
Beide Daten werden umgerechnet in Tage ab 1990!
Zuerst das Enddatum, Ergebnis kommt in #ued:
#nr x"=0" =ed #ued (Enddatum) zuerst auf 0 setzen
#uj1 x"> 90" x"=365" =ed Dies wäre zu erweitern, um noch frühere Jahre zu berücksichtigen!
#uj1 x"> 91" x"=365" =ed
#uj1 x"> 92" x"=366" =ed
#uj1 x"> 93" x"=365" x"+ed" =ed So kommt für 1994 der Wert #ued 1461 heraus!
#um1 x"> 1" x"=31" x"+ed" =ed Jetzt werden die Monate dazugerechnet
#um1 x"> 2" x"=28" x"+ed" =ed
#um1 x"> 3" x"=31" x"+ed" =ed#um1 x"> 4" x"=30" x"+ed" =ed
#um1 x"> 5" x"=31" x"+ed" =ed
#um1 x"> 6" x"=30" x"+ed" =ed
#um1 x"> 7" x"=31" x"+ed" =ed
#um1 x"> 8" x"=31" x"+ed" =ed
#um1 x"> 9" x"=30" x"+ed" =ed
#um1 x"> 10" x"=31" x"+ed" =ed
#um1 x"> 11" x"=30" x"+ed" =ed
#ut1 x"+ed" =ed Und jetzt noch die Tageszahl, Nun ist #ued = Anzahl Tage ab 1.1.90
Dasselbe wird für das Anfangsdatum gemacht:
#nr x"=0" =ad #uad (Anfangsdatum) auf 0 setzen
#uj0 x"> 92" x"=365" =ad
#uj0 x"> 92" x"=365" =ad#uj0 x"> 92" x"=366" =ad
#uj0 x"> 93" x"=365" x"+ad" =ad
#um0 x"> 1" x"=31" x"+ad" =ad
#um0 x"> 2" x"=28" x"+ad" =ad
#um0 x"> 3" x"=31" x"+ad" =ad
#um0 x"> 4" x"=30" x"+ad" =ad
#um0 x"> 5" x"=31" x"+ad" =ad
#um0 x"> 6" x"=30" x"+ad" =ad
#um0 x"> 7" x"=31" x"+ad" =ad
#um0 x"> 8" x"=31" x"+ad" =ad
#um0 x"> 9" x"=30" x"+ad" =ad
#um0 x"> 10" x"=31" x"+ad" =ad
#um0 x"> 11" x"=30" x"+ad" =ad
#ut0 x"+ad" =ad So ergibt sich #uad = Anzahl Tage ab 1.1.92
#ued x"-ad" =dd e0 #udd enthält nun das Ergebnis in Tagen (also die Differenz #ued - #uad)
#udd x"-10000" f"-" e"." r5,0 p"u1 " P{ 0 } Zum absteigenden Sortieren wird 10000 abgezogen
#udd p"u2 " P{ 0 } #u2 enthält das Ergebnis in druckbarer Form
... [weitere Kategorien, am Ende #t{ 0 13 10 } ]
Für solche Export-Parameterdateien, die man in der Bildschirmanzeige testen kann, gibt es eine noch schnellere als die "Allers'sche Testschleife" (Handbuch Kap.10.3.3). Man startet zunächst PRESTO ohne Optionen -q und -e, um auf die fragliche Datenbank zuzugreifen. Dann wählt man eine geeignete Titelanzeige zum Testen. Nun drückt man zweimal F2: es erscheinen dieParameterdateien, die auf dem Datenverzeichnis liegen. Wenn die zu testende Datei auf dem Programmverzeichnis liegt: nochmal F2 geben. Die Datei mit dem Cursor anfahren und F10 drücken (das ist der Trick!), dann wird der X-Editor aufgerufen und die Datei zum Editieren geladen. Man macht Änderungen, die man testen will, speichert mit <Esc> q s wieder ab, setzt ein '+' vor den Dateinamen und drückt <Enter>. Nun wird die Parameterdatei geladen und sofort für die Anzeige benutzt: man sieht das Ergebnis. Evtl. läßt man sich noch andere Sätze zeigen, dann erneut F2 F2, usw. dasselbe von vorn, so oft man will. Diese Methode ist deswegen so schnell, weil PRESTO die ganze Zeit geladen bleibt, bei der Allers'schen Schleife muß es jedesmal neu geladen werden. (Der X-Editor ist hinreichend klein, sonst würde es nicht gehen!)
(H. Allers hat übrigens ein Programm geschrieben, das eine Liste aller verwendeten Sprungmarken erstellt.)
Der Name "Merseburger Testschleife" kam zustande, weil die Methode erstmals in Merseburg auf einer Schulung bekanntgemacht wurde. Jemand schlug sogar "Merseburger Zauberschleife" vor - anspielend auf obskure althochdeutsche Zaubersprüche, die jedoch unter Nicht-Merseburgern außer einigen Germanisten kaum jemandem geläufig sind.
Der N-Befehl arbeitet nicht immer korrekt. Wenn der Text der zu importierenden Kategorie mit einem Sonderzeichen anfängt (z.B.Anführungszeichen oder Klammer), wird die gesamte Kategorie nicht importiert. Dieses Problem wurde beseitigt.
[Erweiterung ab 21.3.94]
Zwei oder drei Datenbanken lassen sich jetzt auch in der Vorgabendatei vorgeben: Man wiederhole die Eintragung unter d
am Anfang der Vorgabendatei, wobei die zweite und dritte Eintragung auch noch, anders als die erste, den jeweiligen
Datenbanknamen enthalten müssen. Ferner schreibe man unter Befehl a z.B. a 321 für die
unterschiedlichen Berechtigungen.
Achtung! Fehlergefahr [Handlungsbedarf]
besteht dann, wenn man bei der Stichwortbehandlung den Manipulationsbefehl u in der Parameterdatei verwendet.
Das kann etwa so aussehen:
#-E #u1 u p"|3" hier sollte stehen: #u1 p"|3" #+#
Man entfernt also das u , und es gibt keine Probleme. (Die Artikel werden ohnehin durch die Stoppwortliste
ausgeschaltet, daher ist der Befehl u logisch gesehen ohnehin überflüssig.) Fehlersymptome, die allerdings
selten auftreten: falsche Registereinträge, falsch gespeicherte Datensätze, wenn mit Funktion -f7 indexiert
wird.
[Bestellung mit beiliegendem Formular]
Statt einen Nachdruck des begehrten Lehrbuchs aufzulegen, um akuten Bedarf abzudecken, wurde im Oktober letzten Jahres beschlossen, lieber umgehend eine aktualisierte und erweiterte Neuauflage in Angriff zu nehmen. Version 13 sollte voll berücksichtigt werden, außerdem wurde ein Kapitel für den Import vermißt, das mußte ganz neu geschrieben werden. Kollege Allers legte sich einmal mehr ins Zeug, aber die penible Entwicklungsabteilung brauchte für die Autorisierung auch noch ihre Zeit. Etwas zu optimistisch war der Januar angepeilt worden; nun ist es doch März geworden, aber am 8.3. kam das Werk aus der Druckerei. Die Auslieferung an alle vertrösteten Besteller ist inzwischen erfolgt.
Unter diesem Titel erschien schon 1988 als Nebenprodukt der Import-Entwicklung eine schmale Schrift, in der die wichtigsten Formate mit Beispielen vergleichend dargestellt wurden. Diese ist seit langem vergriffen, wird jedoch regelmäßig nachgefragt.Jetzt ist die wesentlich erweiterte Neuausgabe da, mit gleichem Titel aber dreifachem Umfang (gut 180 S.). Behandelt werden die Formate MAB, USMARC, BNB-MARC, UNIMARC, Pica+, Pica3, Zeta (ZDB), NZN und das konsolidierte allegro-Format (ehemals NMN). Die einleitenden Kapitel ordnen die Datenformate in das Gesamtgefüge der Datenverarbeitung ein, danach werden Anforderungskriterien für bibliothekarische Formate aufgestellt, darauf folgen einheitlich gestaltete, kritische Kurzporträts der genannten Formate. Der zweite Teil besteht aus einer umfangreichen Konkordanz der Formate und einem alphabetischen Gesamtregister, das alle Feld- und Teilfeldbezeichnungen nachweist. Ergänzt wird das Werk durch eine zusätzlich auf Diskette erhältliche Datenbank, in der man noch komfortabler als im gedruckten Werk die verschiedenen Formate und das alphabetische Register durchsuchen kann.
In Braunschweig können bis auf weiteres keine Einsteigerveranstaltungen stattfinden, weil das Haus der Entwicklungsabteilung, in dem wir einen Seminarraum hatten, abgebrochen wurde. Andere, z.B. vom DBI organisierte Veranstaltungen, werden im "Bibliotheksdienst" angekündigt. Es soll in Braunschweig jedoch in diesem Jahr zwei Tagungen geben:
Zur Auswertung der Erfahrungen mit den Programmen aLF und ORDER, zur Vorstellung der aktuellen Versionen und zur Diskussion der noch zu realisierenden Anforderungen gibt es ein Treffen am 16./17.6. (Do/Fr).
Die alljährliche Expertentagung soll wieder im September sein: am 15./16.9. (Do/Fr). Dort wird dann wieder der neueste Stand der Entwicklungen umfassend demonstriert. Erfahrungsgemäß kann man sich dazu gar nicht früh genug anmelden.
Die Teilnehmerzahl muß in beiden Fällen auf 50 begrenzt werden.
Version 94.1 wird voraussichtlich Ende Mai ausgeliefert werden können. Bis dahin wird es auf dem FTP-Server und auf der Mailbox Vorabversionen mit den Nummern 94.0x geben. Bug reports und Anregungen werden gern von Peter Hartwig entgegengenommen, bevorzugt per E-Mail (p.hartwig@tu-bs.de), Mailbox (persönlich oder über das Brett) oder schriftlich, weniger gern per Telefon.
Ebenfalls auf Server und Mailbox ist schon seit Anfang dieses Jahres das Systemdienstprogramm für aLF zu haben:
aLF errechnet das Rückgabedatum immer so, daß es auf einen Öffnungstag fällt. Damit das klappt (Bibliotheken haben ja nicht alle dieselben Öffnungstage) muß es Kalenderdaten geben. Die korrekte Erstellung und Wartung dieser Kalenderdatensätze war bisher eine lästige Nebenarbeit (man mußte lauter Nullen und Einsen abzählen). Jetzt, dank aLFX, geht es einfach, schnell und sicher, weil vollständig menügeführt.
Nicht nur die Kalendersätze, auch alle anderen Systemdatensätze lassen sich mit aLFX erstellen und bearbeiten. Und wenn man überhaupt erst mit der Ausleihverbuchung beginnen will (aLF selbst startet gar nicht erst, wenn die entscheidenden Systemdaten noch nicht vorhanden sind), übernimmt aLFX auch dieInitialisierung (Ersteinrichtung) einer Katalogdatenbank für den Ausleihbetrieb, d.h. es produziert die wichtigsten Systemdatensätze und mischt sie ein, so daß man sie anschließend per Menü bearbeiten kann.
Das Erwerbungssystem wird in diesen Tagen an die Abonnenten in einer neuen Version und mit überarbeitetem Handbuch verschickt. Es ist eine Version, die noch auf dem Kernsystem 12.2 beruht, weshalb sie noch 1993.2 heißt. Aber die Arbeiten für die Umstellung auf die Fähigkeiten von Version 13 laufen auf vollen Touren. Wir rechnen mit dem Abschluß spätestens zum Spätsommer dieses Jahres. Immerhin: man kann durchaus Version 13 installieren und die Programme des Kernsystems benutzen, ohne ORDER damit zu stören. Nur dann, wenn man eine neue .CFG erstellt und die neuen Möglichkeiten der Version 13 ausnutzt, kann evtl. ORDER die Titeldaten nicht mehr korrekt verarbeiten.
Es gibt aber dennoch, neben vielen Verbesserungen im Detail, einige Neuheiten in dieser Version: Die wichtigste ist, daß es ab jetzt keinen fest eingebauten Signaturgenerator mehr gibt. Man kann jetzt sowohl für die Magazinsignatur als auch für die Aufstellungssignatur jeweils einen Generator parametrieren! Damit steht jetzt der Erzeugung beliebiger Signaturen nichts mehrim Wege. Die zweite wichtige Neuerung ist, daß man etliche Felder in den Datenerfassungsmasken deaktivieren kann, indem man die UIF-Datei für ORDER an geeigneten Stellen manipuliert. Die Felder treten dann nicht mehr auf und werden somit vom Cursor auch nicht mehr angesprungen. Eine nachträgliche Reaktivierung ist selbstverständlich jederzeit möglich. Dasselbe gilt für die Menüpunkte des Funktionsmenüs.
Als Neuerungen für die nächste Version sind neben der Umstellung auf Version 13 vorgesehen:
Schon in der Nummer 27 vom 5.10.92 wurde über das Herannahen des Pica-Systems berichtet ("PICA ante portas..."), insbesondereüber die Frage, ob und welche Konsequenzen dies für allegro haben wird. Am 24.3.1994 traf Pica in der UB Braunschweig ein. Da die Nummer 27 schon vielerorts makuliert sein dürfte und die Ausführungen ohnehin aktualisiert werden müssen, folgt hier ein Bericht zu den wichtigsten Fakten, über den status quo und bevorstehende Auswirkungen.
An dem erwähnten 24.3. wurde vom BRZN (Bibliotheksrechenzentrum für Niedersachsen, Göttingen) die Anlage für das lokale System (Typ LBS3) nach Braunschweig geliefert. Diese Anlage besteht aus:
1 Rechner IBM AIX Risc6000 Modell 55L mit 6 GB Plattenspeicher
2 Rechner DEC MicroVAX 3100-30 (zusammengeschaltet zu einem "VAX Cluster")
1 Router DEC MicroServer zur Anbindung an das WIN
Der IBM-Rechner agiert als "Datenbankserver": auf seiner Platte befindet sich die Datenbank der UB Braunschweig und dasrelationale Datenbanksystem SYBASE, mit dem sie verwaltet wird. Auf den zwei DEC-Rechnern laufen die LBS3-Programme für den OPAC, die Ausleihe, und später dann auch für die Erwerbung. Diese Rechner fungieren also, wie man sagt, als "Anwendungsserver"; sie halten selbst keine Daten, sondern holen sich diese vom Datenbankserver. Die Datenbank muß zwar noch komplettiert werden,der OPAC läuft jedoch bereits und wird intern probeweise benutzt. Eine Verbindung zum Netz der UB ist hergestellt, daher kann der OPAC wahrscheinlich sehr bald über das Internet auch von außen angewählt werden. Die Nummer geben wir über den FTP-Server bekannt. Über das WIN ist eine 64kBit-Verbindung nach Göttingen geschaltet. Über diese Leitung wird der Update-Betrieb laufen, 7d.h. die ständige Aktualisierung der Braunschweiger Datenbank aus dem Zentralsystem heraus, in dem sich die Katalogisierung abspielt. In einigen Wochen soll dieses Verfahren in Betrieb gehen. Wird allegro dann in die Wüste geschickt? Oder auf Sparflamme gestellt? Sicher nicht. Zunächst einmal muß es an der UB so lange voll weiterlaufen, wie dieZeitschriften und die Bestandsdaten noch nicht in der Pica-Datenbank sind. Außerdem müssen die Zugriffsqualitäten des Pica-OPAC noch verbessert werden. Wenn diese Voraussetzungen erfüllt sind und die Ausleihe in Betrieb ist, mag es sein, daß der allegro-OPAC an der UB entbehrlich wird. Jedoch laufen noch einige andereallegro-Datenbanken, die vorerst oder gar auf längere Sicht nicht in die Pica-Umgebung überführt werden können. Obenan steht der Institutskatalog (ca. 100.000 Titel, Tendenz wachsend), dann die ebenfalls beliebte Datenbank der Zeitschriftenaufsätze (DBI-ZD und andere Daten, ca. 95.000 Sätze).
Aber im Prinzip geht es gar nicht darum, ob und wann die UB Braunschweig auf allegro verzichten kann. Weitaus wichtiger ist die Tatsache, auf die schon früher eingegangen wurde, daß Pica und allegro keinesfalls Konkurrenten sind, sondern sich ergänzen. Nach außen muß man dies immer noch einmal sagen, in Niedersachsen weiß esjeder (der sich dafür interessiert). Die oben erwähnte Hardware-Konfiguration macht es schon deutlich: Pica-LBS3 läuft nicht auf einer PC-Anlage, weder auf Einzelplätzen noch auf Netzen. Damit bleibt der Einsatz des LBS3 auf die großen Hochschul- und Landesbibliotheken begrenzt. Das vom Ministerium für Wissenschaft und Kultur formulierte und tatkräftig geförderte Ziel derallegro-Entwicklung ist es, ein integriertes System zu schaffen, das kompatibel zu Pica ist und in allen anderen Bibliotheken eingesetzt werden kann, die sich wenigstens ein paar PCs leisten können. Außerdem ist allegro vorgesehen und schon vielfältig im Einsatz für Sonder- und Nebenaufgaben wie Konvertierung undKartendruck.
Hier wird man fragen, was denn LBS3 besser kann oder allegro (noch) nicht kann. Die sehr direkte und leistungsfähige Integration der LBS3-Systeme mit dem Zentralsystem ist für die großen Bibliotheken ein sehr wichtiger Faktor,denn sie haben einen hohen Bedarf an verbesserten Fernleih-Leistungen (Verwaltung der Bestellungen, automatisierte Anfragen zwischen den Systemen) und auf dem Gebiet der Erwerbungs-Kooperation (sofortige Speicherung aller Bestellungen im Zentral- system). Der Pica-Verbund ist für diese Bibliotheken nicht nur ein Datenverbund, sondern auch ein Lastverbund zur besserenAusnutzung von Ressourcen zugunsten der Benutzerschaft. Für deutsche Verhältnisse ist dieser Sachverhalt, mindestens in seinen Ausmaßen, ein Novum.
Wenn es vorwiegend um die Katalogisierung geht (Nutzung von Fremddaten und Einbringen der eigenen Daten in den Verbund) istallegro auf einem PC-Netz das wirtschaftlichere System und steht dem LBS in der Leistung wohl nicht nach. Die Umwandlung der Pica-Daten in das konsolidierte allegro-Format ist voll entwickelt und bewährt. Die während einer Pica-Katalogisierungssitzung bearbeiteten Daten können sofort nach Abschluß der Pica-Bearbeitungumgewandelt und in die lokale allegro-Datenbank eingemischt werden. Dieses Verfahren ist überall einsetzbar, wo man mit der IBW-Software katalogisieren kann, und dazu benötigt man als Minimum nur einen PC und eine Datex-P- oder WIN-Verbindung. Dieses aber bedeutet, daß dank allegro die Katalogdaten des Pica-Zentrums an sehrviel mehr Stellen nutzbar gemacht werden können, und zwar nicht nur in den Grenzen der Verbundregion.
Nicht überall bekannt ist ferner diese Tatsache: LBS3 kann man nicht als autonomes System betreiben, jedenfalls wird dies noch nirgends gemacht. Es bedarf der Anbindung an die Pica-Zentrale und entfaltet nur so sein Potential.
Wir fassen zusammen: es gibt keine Alternative "allegro oder Pica", sondern es ist zu unterscheiden zwischen zwei Situationen, wenn eine Bibliothek im Einzugsbereich des Pica-Systems liegt:
a) eine Bibliothek liegt im Verbundbereich und hat einen nennenswerten Anteil am Gesamtbestand und am Fernleihaufkommen der Region: dann ist das LBS3 die anzustrebende Lösung. (Was hier "nennenswert" heißt, mag zu diskutieren sein und auch eine politische Komponente haben.) Oder:
b) dies ist nicht der Fall, oder es besteht nicht die Möglichkeit (aus welchen Gründen auch immer), ein LBS3 zu betreiben: dann kommt im Prinzip jedes lokale System in Betracht, das mindestens die Daten des Pica-Systems in sein eigenes Format umwandeln kann. Teilnahme am Katalogverbund und an der Fernleihe ist trotzdem möglich.
Datum der letzen Änderung: 29.03.94
© 1995, UB Braunschweig
Bernhard Eversberg (b.eversberg@tu-bs.de)