UB BRAUNSCHWEIG
Symbolfoto
  • Impressum
  • Startseite
  • allegro-C von A-Z
  • Druckversion
´╗┐

14 Jahre allegro


Grundfragen - Kernprobleme - Anwenderkreise

(Aktualisierte Übersetzung eines Beitrags  "Development of allegro at Braunschweig Technical University Library" in "Program" 29(1995)2, S.147-157)

(Bernhard Eversberg, UB Braunschweig, Universit├Ątsplatz 1, D-38106 Braunschweig)

Inhaltsverzeichnis


Vorbemerkungen

Dieses Papier soll in einem einigermaßen breiten Überblick darstellen, was allegro nach 14 Jahren Entwicklungsarbeit eigentlich ist und wofür es eingesetzt wird. Fünf grundlegende Fragen (Teil A) sollen beantwortet werden. Anschließend wird gezeigt, wie allegro auf sieben Problemfeldern des heutigen Computereinsatzes einzuschätzen ist (Teil B). Im Teil C folgt eine Liste von zehn "Anwenderkreisen", in denen das System zu einem Faktor geworden ist.

Zunächst einmal ganz knapp: allegro ist ein Datenbanksystem für variable Daten. Es wurde seit 1980 an der Universitätsbibliothek Braunschweig entwickelt. Seine strukturellen Möglichkeiten entsprechen den spezifisch bibliothekarischen Anforderungen, und es kann insbesondere mit Formaten wie MARC, MAB und Pica3 umgehen, Normdaten eingeschlossen. Es existieren voll integrierte Module für Ausleihe und Monographienerwerbung. Ein hohes Maß an Effizienz und Flexibilität ist kombiniert mit geringen Anforderungen an Systemressourcen (Speicherplatz und Rechenleistung).

Die bibliothekarische Datenverarbeitung blickt zurück auf eine Geschichte widersprüchlicher Anforderungen. Die Widersprüche sind vielleicht noch schärfer als in manchen anderen Anwendungsbereichen.

Die 70er Jahre wurden beherrscht von dem Konflikt zwischen Geschwindigkeit und Funktionalität: ein System konnte entweder schnell sein (kurze Antwortzeiten) oder eine angemessen breite Funktionalität haben (gute Bearbeitungsfunktionen), aber nicht beides zugleich. Jedoch waren die wenigen Systeme, die es überhaupt gab, für fast alle Bibliotheken unerschwinglich, so daß der Konflikt nur wenige berührte. Trotz laufender Verbesserungen des Preis-Leistungs-Verhältnisses war dann in den 80ern immer noch ein Konflikt zu spüren zwischen Leistung und Kosten: Systeme waren entweder gut (d.h. hatten den ersten Konflikt überwunden), aber teuer, oder preisgünstig, aber immer noch wenig leistungsfähig.

In der ersten Hälfte der 90er erleben wir, wie laufend neue und höhere Anforderungen formuliert werden, wobei zugleich die Hardwarepreise immer tiefer fallen, die Systemleistungen in Megabyte und Megahertz aber laufend steigen. Computer mit angemessener Leistung sind heute für erheblich mehr Institutionen erschwinglich als je zuvor. Wir beobachten jetzt den Konflikt zwischen Benutzerfreundlichkeit und Flexibilität, neben einer auch in anderen Bereichen noch immer vorhandenen Diskrepanz zwischen Erwartung und Wirklichkeit. Eine Multi-Milliarden-Dollar-Industrie, die es vor 10 Jahren noch gar nicht gab, muß ständig die Kundschaft überzeugen, daß sie neue und leistungsfähigere Maschinen braucht - denn diejenigen, die den Anforderungen angemessen sind, sind nicht mehr profitabel. Die Industrie muß praktisch die Anwender dazu überreden, Hydraulikhämmer statt Nußknacker zu kaufen. Das erzeugt ein Klima, in dem die nicht allzu computerversierten Anwender ihre Anforderungen kaum noch realistisch einschätzen können, sondern verführt werden zu denken, daß die Computerei doch heutzutage kinderleicht sein müsse, wenn man nur das richtige System mit der hohen Leistung kauft. Zumindest für die Bibliotheksarbeit ist das noch immer einfach nicht wahr, und man mag sich fragen, ob es schon bald wahr werden könnte.

A. Fünf Grundfragen

1. Denkmodell

"Was sind die Konzepte und Ideen, die das System als Ganzes charakterisieren?"

Für allegro gibt es getrennte Antworten für die Aspekte der Datenbankbenutzung und des Datenbankmanagement:

Benutzung

  • Keine Befehlssprache; direkte Aktionen mit möglichst wenig Tasten
  • Browsing als Grundprinzip der Benutzung: Index und Kurzanzeige sind die wichtigsten Suchhilfsmittel)
  • Die am häufigsten benötigten Funktionen sollen die schnellsten sein.

Management

  • keine "Black Box", sondern für lokale Anpassungen alle Macht dem Anwender
  • Hohe Verfügbarkeit der Datenbank (z.B. Updating im laufenden Betrieb)
  • Schnelle Reorganization, Wiederherstellung und Aktualisierung.

2. System-Anforderungen

"Welche Hardware und Systemsoftware braucht allegro?"

Nicht mehr als eigentlich jeder hat oder sich leisten kann: normale PCs und irgendeine DOS-Version ab 3.3 aufwärts. Version 14 läuft immer noch auch auf 286er Maschinen mit 640K, das OPAC-Programm sogar auf XTs. Für einen Mehrplatzbetrieb kann jedes LAN benutzt werden, auch die Billignetze (Peer-to-Peer networks) haben sich als genügend sicher und leistungsfähig erwiesen. Der Plattenspeicherbedarf liegt im Durchschnitt unter 600 Byte je Datensatz (inclusive Index, d.h. ca. 20 Schlüssel je Datensatz, mit bis zu 72 Byte je Schlüssel sind darin schon enthalten). Anders ausgedrückt: auf 10 MB Platte kann man gut 15.000 Sätze unterbringen.

3. Datenbanktechnische Grundsätze

"Was sind die charakteristischen Aspekte des Datenbanksystems?"

Von vornherein stand die Vorstellung im Vordergund, daß man die vollständige Kontrolle über alle Teile der Software bewahren sollte: so gibt es bis heute keine Abhängigkeit und keine Rechte von Dritten, und die Quelltexte in C liegen vollständig vor. Insbesondere basiert die Software nicht auf einem kommerziellen Datenbankprodukt.

Das Datenbankmodell ist nicht relational, daher gibt es auch keine SQL-Schnittstelle. Aber: ein API (Application Programmers' Interface) ermöglicht es Programmierern, neue Funktionen für neue Anwendungen zu schaffen. Jedoch gibt es wenige Bibliothekare, die sich flüssig in C ausdrücken können.

Seit einer Weile wird das Schlagwort Client/Server-Modell ständig bemüht, wenn es um neue Systeme geht. Dieses Konzepte rfordert einen Datenbankserver. Dieser kann entweder in den File-Server integriert oder ein zusätzliches Produkt sein, evtl. sogar auf einem zusätzlichen Rechner. Innerhalb lokaler Systeme macht das nicht viel Sinn, es erhöht nur die Komplexität und die Kosten. allegro arbeitet ohne dieses Konzept effizienter. Das Client/Server-Modell entfaltet seinen Nutzen in offenen Netzen mit heterogenen Endsystemen. Es muß dann aber ein wohldefiniertes Protokoll geben, wie etwa das vielzitierte SR oder Z39.50. Für die Indexfunktionen von allegro gibt es ein Server-Modul. Eine SR-Schnittstelle dafür ist realistisch, müßte aber erst noch programmiert werden, sobald dafür ein Bedarf sichtbar wird. Derzeit wird aber schon ein WWW-Zugriff zum allegro-OPAC der UB Braunschweig angeboten, der sehr schnell und sehr einfach zu benutzen ist, aber keine große Programmierarbeit bereitet hat. Hierfür hat sich ein Bedarf sehr deutlich gezeigt. Die Adresse (sog. URL) des WWW-Zugangs lautet  http://www.biblio.tu-bs.de/db/opac/.

4. Funktionen

"Welche Funktionen unterstützt die Software, welche Module gibt es?"

Es gibt sechs Module, ein paar davon mit gewissen Varianten, die sich auf bestimmte Bereiche der Bibliotheksarbeit konzentrieren, und daneben fünf Programme, die das DatenbankManagement unterstützen:

Bibliotheksfunktionen (in Klammern Hinweise zur jeweiligen Benutzeroberfläche):

  1. Katalogisierung (Funktionstasten, Befehle)
  2. Sacherschließung (Menü, Funktionstasten, Befehle)
  3. OPAC (Menü, Funktionstasten)
  4. Volltextsuche und Export (Stapelverarbeitung)
  5. Monographien-Erwerbung (Menü, Funktionstasten, ergänzt durch Stapelverarb.)
  6. Ausleihe (Menü, Funktionstasten, ergänzt durch Stapelverarb.)
    Hier besteht die Alternative zwischen dem aufwendigen System aLF und dem einfachen aLFA, das nur die Funktionen Ausleihe und Rückbuchung bietet, integriert mit dem OPAC.

Datenbankmanagement-Funktionen

  1. Konvertieren Programmierbare Umwandlung von Fremddaten
  2. Sortieren Alphanumerisches Sortieren beliebig großer Dateien mit variablen Sätzen
  3. Updating Neue Daten in eine Datenbank einmischen, verschiedene Modalitäten zur Ersetzung vorhandener Datensätze
  4. Export Programmierbare Umwandlung von allegro-Daten in andere Strukturen
  5. Indexieren Aus Grunddaten eine Datenbank aufbauen (hauptsächlich den Index)

Alle diese Leistungen können vom CockPit gesteuert werden. Dies ist eine Art Datei- und Programm-Manager mit speziellen Management-Funktionen für den Systemverwalter. Die Programme lassen sich aber auch in Stapeldateien einbauen.

5. Datenstrukturen

"Sind die internen Datenstrukturen offengelegt?"

Die interne Datenstruktur der Anwenderdaten ist relativ einfach und vollständig dokumentiert, also für Programmierer ohne weiteres zugänglich. Die Feldstrukturen der gängigen Standardformate (MARC, MAB, Unimarc, Pica) können alle weitgehend auch unverändert als Internformate eingesetzt werden. Nur die Registerdateien sind sehr komplex, jedoch ist dies aus Gründen der Effizienz so, und Anwender müssen sich damit nicht direkt auseinandersetzen. Die Register sind parametrierbar, und die Parameterdateien sind offen und dokumentiert.

Man muß immer unterscheiden zwischen dem bibliothekarischen Format (wie MAB, MARC, Pica) und der Struktur, in der die Daten wirklich abgespeichert werden. Der Einsatz von Standard-Datenbanksystemen wie Adabas, Sybase oder Informix erzwingt es in der Regel, daß die interne Speicherung der Daten stark abweicht von der Form, wie der Bearbeiter sie am Bildschirm sieht. Bei Pica werden, allerdings aus anderen Gründen, außerdem noch intern ganz andere Feldbezeichnungen (Kategorienummern) verwendet. allegro vermeidet solche zusätzlichen Komplikationen. Die Zugriffsregister sind strukturell von den eigentlichen Daten vollständig getrennt, so daß jederzeit eine Neu-Indexierung mit geänderter Registerstruktur stattfinden kann, ohne daß in die Struktur der Titeldaten eingegriffen werden muß.

B. Sieben Software-Kernprobleme

In der Software-Entwicklungsarbeit hat man es mit einer Reihe von ganz verschiedenen Aspekten zu tun, die man nicht einen nach dem anderen abhandeln kann, sondern die man meistens alle gleichzeitig im Blick haben muß. Der Entwickler sollte sich mindestens diese Bereiche ständig vor Augen halten:

 

Offenheit

Sicherheit

- Netze
- Standards
- Integration

- Datensicherung
- Datenschutz
- Fehleranfälligkeit

 

Verfügbarkeit

 

 

Leistung

Bereitstellung

Flexibilität

- Real-time Update
- Schneller Zugriff
- Produktivität

- Rechte und Lizenzen
- Kontinuität
- Dokumentation

- Know-how Verbreitung

- Lokale Varianten
- Formatanpassung
- Import/Export

 

 

 

Benutzeroberfläche

Ressourcenbedarf

- Einfachheit
- Intuitive Struktur
- Adaptierbarkeit

- Kosten <---> Leistung
- Plattformen
- Anwendungsbereiche

Hier wird kein Versuch gemacht, diese sieben Anspruchsbereiche in eine Prioritätenfolge zu bringen - das geht einfach nicht. Sie werden deshalb im folgenden alphabetisch abgehandelt.

Benutzeroberfläche

Manchen Anwender mag es überraschen, aber die "Mensch-Maschine-Schnittstelle" ist der komplizierteste Problembereich, mit dem es der Programmierer heute zu tun hat. Das liegt daran, daß hier zwei grundverschiedene Intelligenzen aufeinandertreffen: die natürliche und die künstliche. Kein Wunder also, daß die Graphischen Benutzerschnittstellen (GUIs) dazu neigen, mehr Speicher und Rechenleistung zu verschlingen als die Anwendungen selbst.

Man hat im Bibliotheksbereich zu unterscheiden zwischen zwei Arten von Programmbenutzern: der OPAC-Benutzer (bei Pica "Nutzer" genannt), und der Bibliotheksangehörige (nur dieser heißt in der Pica-Terminologie "Benutzer").

Die allegro-Oberfläche für den Bibliothekar wird von unvorbereiteten Windows- oder gar Mac-verwöhnten Anwendern als sehr schlecht eingestuft und oftmals kaum richtig verstanden. Es wurde im Abschnitt A bereits ausgeführt, daß die Entwicklungsprioritäten auf Leistung und Speichereffizienz lagen, und wenn man diese zwei vereinbaren will, ist das schon ein genügend großes Problem. Daher konnte man nicht noch zugleich ein optimales Oberflächendesign realisieren - das mußte warten.

Gewisse Anstrengungen wurden jedoch unternommen, ein praktikables OPAC-Modell zu entwickeln. Immerhin haben schon über 50 Bibliotheken ihre Zettelkataloge zugunsten dieses neuen Katalogs aufgegeben. Der OPAC arbeitet mit Menüs. Der erfahrene Nutzer kann aber auch die Menüs umgehen und alle Funktionen per Tastenkombination auslösen. Wer an andere OPACs gewöhnt ist, findet den allegro-OPAC zunächst "eigenartig". Er arbeitet jedoch "direkter" und schneller als andere Modelle, denn er kommt mit weniger Bildschirmen (nur zwei: Register und Titelanzeige!) und weniger Tastendrücken aus. Wer an einen allegro-OPAC gewöhnt ist, empfindet manche anderen Modelle als umständlich und "lahm" oder "betulich". Für den allegro-OPAC stehen aber durchaus noch Verbesserungswünsche im Raum. Wenn man über einen WWW-Server verfügt, kann man seit neuestem noch einen zusätzlichen, andersartigen Zugang anbieten.

Eine Benutzerschnittstelle wird oft als "Schale" betrachtet, die einen "Kern" vor der Außenwelt verbirgt. Der Kern ist allerdings das eigentlich entscheidende Element für den dauerhaften Erfolg eines Systems. Das Oberflächendesign muß, so gesehen, dem Design des Kerns folgen, nicht vorangehen. Das Umgekehrte scheint eher die Regel zu sein, vor allem bei kommerzieller Software. Das ist völlig verständlich: Eine Softwarefirma muß versuchen, möglichst viele Interessenten zu überzeugen, und wenn dies überwiegend durch Vorführungen zu geschehen hat, überzeugt nichts leichter als eine brilliante Oberfläche. Die Qualitäten eines Kerns können aber grundsätzlich nie von der Oberfläche her und aus relativ kurzen Vorführungen heraus eingeschätzt werden. Softwarebeurteilung ist deshalb schwieriger geworden als früher. "Oberflächlicher" Glanz kann jedenfalls die wahren Qualitäten einer Software eher verhüllen als offenlegen.

Das alles wird hier nicht deshalb ausgeführt, um eine Entschuldigung für Mängel der allegro-Oberfläche zu konstruieren, sondern als allgemeiner Hinweis an jeden, der sich mit der Bewertung und Entscheidung in Sachen Software zu befassen hat. Wer vor der Entscheidung für ein neues System steht, sollte unter anderem immer das nicht zu kurze Gespräch mit erfahrenen Anwendern dieses Systems suchen, und in solchen Unterhaltungen muß Klartext gesprochen werden.

Das oben erwähnte CockPit ist als Benutzeroberfläche leider nur eine halbe Lösung. Es ist sehr hilfreich, aber nicht ausgesprochen intuitiv, und es ist nicht viel mehr als ein Datei- und Programm-Manager. Bei der Dateneingabe und –bearbeitung hilft es nicht, und auch nicht bei den wirklich schwierigen Aufgaben des Datenbank-Entwurfs und der Parametrierung. Ein menügeführtes Programm für die letztere Aufgabe müßte ein außerordentlich großes Programm sein. Es ist wahrscheinlicher, daß man eine Art Compiler mit "Debugging"-Funktionen entwickeln kann, der die Konstruktion von Parameterdateien erleichtern würde. So etwas ist zur Zeit jedoch noch nicht in der Entwicklung, wenngleich der Bedarf erkannt ist.

Die Ausleih- und Erwerbungsprogramme haben bereits eine ausgedehnte Menüführung, ebenfalls das Programm für die Sachkatalogisierung und der OPAC. Das alles bezieht sich aber auf den Einsatz, nicht auf die Konfigurierung und lokale Adaptierung/Parametrierung.

Die Arbeitssprache ist Deutsch oder Englisch. Da sich alle Menü- und Meldungstexte in Dateien außerhalb der Programme befinden, und diese Dateien dem Anwender zugänglich sind, kann man die Kernsoftware als multilingual bezeichnen.

Eine der wichtigsten Fragen beim Nachdenken über Benutzeroberflächen war außerdem die, wie man MS-DOS und UNIX dann noch zusammenhalten kann. Dies ist der entscheidende Grund, weshalb nicht die Microsoft- oder Borland-Tools für objektorientiertes Oberflächendesign zum Einsatz gekommen sind: diese beschränken sich auf MS-Windows. Gebraucht wird aber ein "plattformunabhängiges" Entwicklungswerkzeug. An solchen Werkzeugen gibt es nur eine sehr kleine Auswahl. Es müssen sich damit Programme schreiben lassen, die hinterher ohne Veränderung für MS-DOS, OS/2 und UNIX kompiliert werden können, und zwar für UNIX sowohl als zeichenorientierte wie auch als graphische Anwendung. Es steht noch nicht fest, was für einen Preis man hinsichtlich Overhead bezahlen muß, wenn man dies realisieren will. Eins ist sicher, Rechner mit 286, vermutlich auch 386, werden auf der Strecke bleiben. Das mag nicht jeder als Problem sehen, jedoch sind viele allegro-Anwender nicht in der Lage, in kürzeren Abständen neue Hardware zu beschaffen.

Flexibilität

Deutsche Bibliotheken (oder Bibliothekare?) sind bemerkenswert individualistisch. Ausländer sind immer wieder erstaunt, daß es kein allgemein akzeptiertes und überall angewendetes Standardformat gibt. Man vermutet automatisch, es müsse ein German MARCgeben. Das deutsche MAB mag sich nun zwar als Austauschformat bewährt haben, aber doch nur relativ zu den Ansprüchen, denen es ausgesetzt wurde. Hinter USMARC oder UNIMARC liegt es hinsichtlich Detaillierungsgrad und Anwendungsbreite sehr weit zurück. Genau das ist der Grund, warum es soviele erweiterte MAB-Versionen gibt, aber auch soviele ganz anders strukturierte lokale oder Verbundformate, wobei jetzt Pica das prominenteste Beispiel ist. In diesem Chaos war es ein logischer Ansatz, eine Datendefinitionssprache zu entwickeln, um allegro für jedes Format konfigurieren zu können, und zudem eine Datenmanipulationssprache für das Konvertieren zwischen einzelnen Formaten. In Wirklichkeit gibt es zwei verschiedene Sprachen:die Import- und die Exportsprache, die bei der Konvertierung von einem Format in ein anderes zusammenarbeiten können. Die Exportsprache ist vorwiegend dazu da, jedes erwünschte Ausgabeprodukt zu erzeugen. Dazu gehören nicht nur Druck- und Downloadaktionen, sondern auch die Bildschirmanzeige, ja sogar die Schlüsselgenerierung für die Zugriffsregister.

Die Datendefinitionssprache wurde für Version 13 stark erweitert und verfeinert. Erst dadurch wurde es möglich, unter allegro mit weitgehend originalgetreuen MARC-, MAB- oder Pica-Daten zu arbeiten. Ob das wirklich in einem Anwendungsfall sinnvoll ist, ist eine andere Frage, aber man kann es tun. "Feld-Deskriptoren" spezifizieren alle Aspekte und Eigenschaften jedes Datenfeldes, das im Format vorkommt. Zu Testzwecken wurde eine US-MARC Konfiguration geschaffen und für Interessenten zugänglich gemacht, ja sogar an der Library of Congress vorgeführt. Beeindruckt hat dabei, daß sogar die noch sehr neuen und recht komplexen Stammdaten der LC-Klassifikation als Datenbank mit passenden Zugriffsregistern aufbereitet werden konnten. Dashatte noch keine US-Software geschafft.

Kurz zusammengefaßt: das Format, mit dem eine Datenbank arbeitet, wird in der Konfigurationsdatei definiert (mit der Definitionssprache). Getrennt davon gibt es die Index-Parameterdatei, wo die Zugriffsregister definiert sind (in der Exportsprache). Ebenfalls in der Exportsprache geschrieben sind die Export-Parameterdateien, mit denen die Titelanzeige, der Kartendruck und sonstige Ausgabeprodukte geregelt werden.

Die Exportsprache ist der schwierigste Teil des Systems. Das Lehrbuch von Heinrich Allers enthält eine komplette Einführung und umfangreiches Beispielmaterial, während das Kapitel 10 des Systemhandbuchs als Referenz zum Nachschlagen eine systematische Dokumentation bietet.

Dasselbe gilt für die Importsprache. Die Kapitel 10 und 11 des Handbuchs liegen auch vollständig übersetzt in Englisch vor.

Leistung und Zuverlässigkeit

Seit Beginn der Entwicklungsarbeit (Ende 1980!) standen hohe Geschwindigkeit und geringer Platzbedarf ganz oben auf der Prioritätenliste. Die Universitätsbibliothek Braunschweig blickt im Jahre 1995 zurück auf 247 Jahre sparsamen bis knausrigen Wirtschaftens. Für die Software-Entwicklung verpflichtete diese ungebrochene Tradition nachgerade dazu, jede Verschwendung im Ansatz zu vermeiden.

In den Vorbemerkungen war die Rede von einem Konflikt zwischen Geschwindigkeit und Funktionalität. In der Praxis wird vielfach dieser Konflikt nicht gelöst, sondern umgangen, indem man eine mächtigere Maschine kauft und/oder etwas (bis ziemlich viel) Speicherplatz opfert. Keine dieser "Lösungen" erschien akzeptabel, es mußte ein anderer Ansatz gefunden werden. Dieser Ansatz wurde zum Kern des Erfolges von allegro. Früher oder später muß ja überall, da die Bestände dauernd wachsen, über Effizienz und Sparsamkeit nachgedacht werden. Der allegro-Ansatz stellt sicher, daß man relativ große Datenbanken auf relativ kleinen Maschinen betreiben kann, und zwar stets mit annehmbarer Leistung. Und wer sich eine bessere Maschine leisten kann, kommt mit allegro damit weniger schnell an neue Grenzen. Anders gesagt, man muß nicht ständig hinter der neusten Technologie herjagen, nur um sich über Wasser zu halten.

Außer dem Datenbank-Hauptprogramm PRESTO, das die Indexsuche sowie die Dateneingabe und -bearbeitung ermöglicht, gibt es die Programme INDEX (zum Neuaufbau der Registerdatei) und UPDATE (um neue Daten in eine existierende Datenbank einzumischen, wobei wahlweise vorhandene Datensätze mit gleichem "Primärschlüssel" ersetzt oder teilweise ersetzt werden können). Auch dieseProgramme müssen sehr effizient sein, damit sie bei großen Datenmengen überhaupt noch eingesetzt werden können. Je größer eine Datenbank ist, umso länger wird es natürlich brauchen, sie neu zu indexieren. Die dafür nötige Zeit wächst jedoch linear an, nicht quadratisch oder gar exponentiell. Das ist das beste überhaupt erreichbare Verhalten für diese Art von Aufgaben. Konkrete Beispiele: der Braunschweiger OPAC mit gut 500.000 Datensätzen braucht etwa 8 Stunden, um den Index mit über 5.000.000 Einträgen neu zu erstellen. (Dies wurde auf einem 486er Rechner mit 66MHz festgestellt, wobei der Novell-Server ein 386/33MHz war.) Der Nord-OPAC mit 3.3 Millionen Sätzen brauchte auf einem Pentium mit 100 MHz nur gut 48 Stunden.

Das Programm UPDATE kann laufen, während die Datenbank in voller Benutzung ist. In der Tat wurde es zu Testzwecken regelmäßig im Hochbetrieb gefahren. Probleme traten dabei nicht auf.

Im Ergebnis kann man feststellen, daß man mit allegro eine sehr hohe "Verfügbarkeit" der Datenbank erreicht. In Braunschweig gab es in einer Laufzeit von über drei Jahren keine Softwareabstürze, nur einige wenige hardwarebedingte Ausfälle, die jeweils maximal in wenigen Stunden zu beheben waren.

Wenn ein Index erneuert werden muß, was demnach selten vorkommt, kann es bis zu einer Datenbankgröße von 1 Million Sätzen immer noch über Nacht geschehen. Bei noch größeren Datenbanken würde man z.B. zuerst die wichtigsten Register erneuern, in der zweiten Nacht die anderen. Auch der schlimmste GAU würde demnach den Betrieb nicht für länger als einen Tag lahmlegen. Für alle Beteiligten ein beruhigender Gedanke.

Offenheit

Die Fähigkeiten zur Umwandlung von Fremdformaten und zur Produktion dieser Formate aus den internen Daten sind wichtige Aspekteder Offenheit des Systems. Die Universitätsbibliothek Braunschweig mußte als Mitglied des Pica-Verbundes Niedersachsen frühzeitig in der Lage sein. die Pica3-Daten des Verbundzentrums in allegro Daten zu konvertieren. Routinemäßig werden seit 1993 die Produktionsdaten jeweils mehrerer Tage oder wahlweise auch die Daten einer Sitzung per Download "heruntergeladen", und sofort nach der Sitzung erfolgt die Umwandlung und das Einmischen der Daten in den allegro-Katalog. Das Analoge ist in anderen Verbünden möglich und wird auch praktiziert. "Offenheit" umfaßt jedoch erheblich mehr. (Zum Thema mehrsprachiger Arbeitsweise siehe "Benutzerschnittstelle".)

Die Import- und Exportsprachen, wie im vorigen Abschnitt ausgeführt, sind zwar nicht einfach, doch vollständig dokumentiert, d.h. sie machen allegro zu einem offenen System in dem Sinne, daß es für den versierten Benutzer keine "black box" ist, sondern an Ort und Stelle adaptiert werden kann.

Für den ambitionierten Anwender, der zufällig auch in C programmieren kann, gibt es eine Programmierschnittstelle (ein sog. "API" (=Application Programmer's Interface)). Damit kann der Funktionsumfang erweitert und modifiziert werden. Dieser Ansatz wurde auch gewählt, um die Ausleih- und Erwerbungsfunktionen an den Datenbankkern anzuschließen. Dadurch verfügen auch diese Programme über den gesamten Funktionsumfang der Suche und Dateneingabe, den die Katalogisierung umfaßt. Und ferner kommt dadurch auch den Ausleih- und Erwerbungsteilen der gesamte Umfang der Exportsprache zugute, um Ausgabeprodukte jeder Art herzustellen.

Wenn die Zukunft eine OSI-Welt sein wird (was abzuwarten bleibt), steht noch einige Programmierarbeit bevor. Eine Schnittstelle mit einigen SQL-Funktionen wird geschaffen werden müssen (um das "Search & Retrieve"-Protokoll zu realisieren). Anforderungen auf der Indexebene (für die Zugriffsfunktionen) können bereits mit der vorhandenen Exportsprache abgedeckt werden.

Die Gegenwart ist eine TCP/IP-Welt, in der das TELNET-Protokoll für den Fernzugriff eine wichtige Rolle spielt. Dieses Protokoll ermöglicht schon jetzt den Zugriff auf einen allegro-X-Katalog: der Braunschweiger OPAC auf einer SUN-Workstation istin der Internet-Welt unter telnet 134.169.20.2 zu erreichen. allegro-X ist seit kurzem auf demselben Stand wie die MS-DOS- Version. Mehr darüber im nachfolgenden Abschnitt.

Ressourcenbedarf

Wie bereits erwähnt, kann allegro immer noch im Einzelplatzbetrieb auf Maschinen der untersten Leistungsklasse eingesetzt werden - sogar noch auf 286er PCs. Die Software braucht noch immer nicht mehr als 3 MB Plattenspeicher für sich selbst. Stark angestiegen ist in den letzten zwei Jahren die Zahl der Mehrplatzanwender. Viele setzen eines der billigen "peer-to-peer"-Netze ein, die ohne separaten Fileserver arbeiten. Andererseits haben etliche Universitäten Campusnetze auf Ethernet-Basis, und die Bibliotheken können dann ihren Netware-Server der ganzen Hochschule öffnen. In solchen Netzen können auch "DisklessWorkstations" (PCs ohne eigene Platte) als OPAC-Endgeräte eingesetzt werden. In Braunschweig gibt es typischerweise während des Tages oftmals etwa 10 gleichzeitige Zugriffe von außerhalb des Hauses. Vielleicht sollte man hier anmerken: es gibt bei allegro keine gesonderte "Netzwerkversion", sondern die Software ist von Hause aus mehrplatzfähig.

Eine UNIX-Portierung, genannt allegro-X, wurde Ende 1994 erstmals freigegeben. Da alle Quellprogramme in C geschrieben sind, war die Portierung kein extremes, wenngleich ein durchaus arbeitsaufwendiges Unternehmen. Schwierigkeiten treten primär im Bereich der Bildschirm- und Tastaturprozeduren auf, denn hier unterscheidet sich die UNIX-Welt grundlegend von der MS-DOS-Welt.Der Durchbruch wurde jedoch erzielt, und die weitere Entwicklung kann auf Programmquellen aufbauen, die für beide Welten Gültigkeit haben.

Der Braunschweiger OPAC auf der SUN-Workstation ist prinzipiell von allen Terminals erreichbar, die am Internet hängen und eine VT-100-Emulation fahren können. Wegen der Flexibilität der Software und ihrer niedrigen Kosten können nicht nur OPACs, sondern viele Arten von Spezialdatenbanken für große und verstreute Nutzerkreise geöffnet werden. Ein frühes Beispiel ist die deutsche Datenbank des EROMM-Projekts (European Register of Microform Masters): diese liegt auf einem Novell-Server an der GöttingerStaats- und Universitätsbibliothek und kann mit jedem Modem erreicht werden. Zunächst wurde dafür eine Omniware-Lösung mit einem Gateway-PC eingesetzt, der aber nur zwei PCs gleichzeitig bedienen konnte. Eine UNIX-Anlage könnte wesentlich mehr Verbindungen ermöglichen.

Sicherheit

Dieser Punkt steht auf der alphabetischen Liste recht weit unten, in seiner Wichtigkeit jedoch mit an der Spitze.

Die Kernsoftware stürzt kaum jemals ab. Selbst wenn es einmal passiert, entsteht normalerweise kein Schaden an den Daten. In Braunschweig sind zwar schon Stromausfälle vorgekommen, aber NetWare hat sich dann in der Regel ohne Probleme selbst wieder"erholt" und es gab keine Defekte. Ein Zusammenbruch wird nur dann Folgen für eine Datenbank haben, wenn er genau zum Zeitpunkt eines Schreibvorgangs passiert, d.h. wenn gerade ein Datensatz abgespeichert wird. Hinterher wird dann der Index nicht mehr benutzbar sein. Dann kommt die "LOG-Datei" zum Einsatz: man hat ja höchstwahrscheinlich (?) eine nicht zu alte Sicherungskopie seiner Datenbank. Diese wird zuerst wieder vom Sicherungsmedium zurückgeholt, dann läßt man das UPDATE-Programm darauf los. Es mischt die aktuelle LOG-Datei in die Datenbank ein. Diese Aktion nennt sich auch "Playback", weil praktisch alles das wiederholt wird, was an Veränderungen seit der Anfertigung der Sicherungkopie ausgeführt worden war. Man erhält dadurch den Zustand, der unmittelbar vor dem Zusammenbruch bestanden hatte.

Um dem Anwender das regelmäßige Anfertigen von Sicherungskopien zu erleichtern, unterstützt das CockPit diese Funktion sehr komfortabel. Auch andere Management-Arbeiten, wie etwa die "Kompaktierung" (Freigabe ungenutzten Platzes) und der Index-Neuaufbau werden auf wenige Knopfdrücke reduziert.

Verfügbarkeit, Vertrieb, Kontakte zum Anwender

Wenn eine Software für eine größere Anwenderschaft verfügbar gemacht wird, muß es zu jedem Zeitpunkt eine wohldefinierte und sofort lieferbare Version geben. Sie muß für den Interessenten leicht erhältlich und problemlos zu installieren sein. Die Entwicklungsabteilung macht Anstrengungen, dies zu gewährleisten. Seit 1990 hat das Niedersächsische Ministerium für Wissenschaft und Kultur die allegro-Weiterentwicklung der Bibliothek als "Staatliche Sonderaufgabe" zugewiesen und dafür auch substantielle Personalmittel bereitgestellt. Das bedeutet, die Software ist und bleibt auf absehbare Zeit ein nicht- kommerzielles Produkt. Das Kernsystem wird deshalb gegen eine bloße Lizenzgebühr von DM 350.- an Einrichtungen der öffentlichen Hand überlassen, nicht verkauft. (Irgendwelche anderen Lizenzen sind nicht erforderlich, da allegro ein Komplettsystem ist und keine Datenbank- oder sonstige Software als Grundlage oder Ergänzung benötigt.) In Form des Systemhandbuchs und des Lehrbuchs liegt eine aktuelle und vollständige Dokumentation der Version 14 vor, die vierteljährlich durch die allegro news ergänzt wird. Anwender ohne DV-Erfahrung sind in der Regel überfordert, mit diesen Mitteln eine optimale Anwendungsumgebung für die eigenen Belange einzurichten. Das standardmäßige Katalogisierungs- und OPAC-System, das man bei der Erstinstallation automatisch eingerichtet bekommt, ist zwar so vielseitig und leistungsfähig, daß viele damit schon zunächst einmal zufrieden sind. Die UB Braunschweig kann nicht als Dienstleister tätig werden und auf Wunsch Anpassungen vornehmen oder Schulungen vor Ort durchführen. Für das oben genannte Entgelt wäre das ohnehin undenkbar. Es steht jedoch nichts im Wege, wenn eine Bibliothek sich auf dem "freien Markt" einen Dienstleister sucht, der solche Aufgaben übernehmen kann. Dafür gibt es Beispiele. Bis auf die Lizenzvergabe, die nur von Braunschweig aus erfolgen darf, kann eine DV-Dienstleistungsfirma alles anbieten und ausführen, was mit der Anwendung des Systems zu tun hat. Es ist wohl eine Besonderheit, daß man bei allegro die Alternative "Eigenleistung oder bezahlte Dienstleistung" hat.

Es gibt seit einer Weile neben dem Postversand einen weiteren Vertriebsweg: den FTP-Server. Dieser kann über das Internet benutzt werden, und registrierte Anwender können sowohl die aktuellen Programme "herunterladen" als auch "Betaversionen" neuer Programme, Parameterdateien, die Textdateien der news, Public-Domain-Hilfsprogramme etc. Der FTP-Server hat die Adresse134.169.20.1 und hat auch einen ANONYMOUS-Bereich, in dem sich jeder umsehen kann. Wer keinen Internet-Zugang hat, kann per Modem die Mailbox (mit demselben Inhalt) anwählen. Die Telefonnummer ist (0531)391-5064.

Die Entwicklungsabteilung macht Anstrengungen, neue Versionen stets mit den Vorgängern kompatibel zu halten. In der Regel muß daher bei Installation einer neuen Version weder an den Datenbanken noch an den Parametrierungen etwas reorganisiert oder geändert werden. Wer neue Funktionen konsequent nutzen will, muß allerdings seine eigene Konfiguration überdenken und entsprechend tätig werden, d.h. die Anweisungen in den news studieren und umsetzen.

Entwicklungsarbeit kann nicht in Isolation betrieben werden, sondern braucht die ständige Rückkopplung mit der Praxis. Deshalb haben Entwicklung und Vertrieb schon immer Hand in Hand gearbeitet. Eine wachsende Zahl von allegrologen stehen mit der Entwicklungsabteilung per E-mail in Verbindung. Ein Anwender in Bonn hat eine Diskussionsliste eingerichtet (allegro@mpim-bonn.mpg.de), an der jeder über E-mail teilnehmen kann: man sendet die Message subscribe allegro Vorname Nachname (mit dem eigenen Namen) an die Adresse listserv@mpim-bonn.mpg.de . Außerdem findet seit einigen Jahren jeden Herbst ein "Expertentreffen" in Braunschweig statt, an dem immer bis zu 60 fortgeschrittene Anwender teilnehmen (mehr sind nicht zu verkraften). Für die Kontaktpflege hat die Entwicklungsabteilung eine allegro Datenbank aller registrierten Anwender und weiterer Personen. Diese Datenbank wird laufend aktualisiert und täglich konsultiert, um Kontakte herzustellen. In mehreren Spezialbereichen des Bibliothekswesens haben sich Anwenderkreise gebildet, z.B. kirchliche Bibliotheken, Öffentliche Bibliotheken, Sinologen, Kunst- und Museumsbibliotheken, Archive, etc. (siehe Teil C). Diese Kreise agieren als Selbsthilfegruppen und tauschen zum Teil neben Erfahrungen auch Daten aus. Jede solche Gruppe hat mindestens einen allegrologen, der über das fachspezifische Know-how verfügt.

C. allegro Anwenderzirkel

Gegenwärtig gibt es etwa zehn allegro-Anwendergruppen. Einige davon haben keinerlei organisierte Zusammenarbeit oder Gruppenidentität, sondern nur ein gleichartiges Interessenprofil. Andere haben ein reges Gruppenleben entwickelt (Arbeitstreffen, Austausch von Know-how und Daten). Im folgenden sind die gegenwärtig zu erkennenden fachlichen Gruppen näher beschrieben. Es gibt zudem mindestens zwei spartenübergreifende regionale Gruppen: in Berlin und im Nordwesten (um Oldenburg).

1. Staatsbibliotheken

Alle deutschen Bibliotheken mit Staatsfunktionen sind allegro-Anwender. (Die alphabetische Liste: Berlin, Bremen, Frankfurt, Göttingen, Hamburg, Leipzig, München, Wolfenbüttel.) In den meisten Fällen werden spezielle Projekte oder Sonderkataloge damitbetreut. Die größte Datenbank wird momentan in Hamburg bereitgestellt: alle 3.3 Millionen Datensätze des Nordverbundes bis 1984 sind auf einem Novell-Server für die Universität Hamburg in deren LAN zugreifbar. Die Datenbank ist auch auf 2 CDs erhältlich.

2. Hochschulen

Die meisten Hochschulbibliotheken sind eingetragene allegro-Anwender und nutzen das System für verschiedenste Anwendungen auf unterschiedlichen Niveaus. Einige betreiben OPACs, einige nutzen die Schlagwort-Normdatei als allegro-Datenbank, einige haben das Ausleih- bzw. Erwerbungsprogramm im Einsatz. Gegenwärtig wächst das Interesse für allegro-X, besonders wegen der Möglichkeit, dann einen Katalog per WWW anzubieten. Etliche haben eine Campus-Lizenz und koordinieren die Katalogisierung inden Institutsbibliotheken, sammeln deren Daten und machen sie in einem Zentralkatalog verfügbar.

Einige Bibliotheksschulen haben allegro in ihre Lehrpläne aufgenommen und geben den StudentInnen mindestens Gelegenheit zum Kennenlernen. Es wird aber wohl als schwierig empfunden, die notwendige Zeit für eine hinreichend gründliche Beschäftigung einzuplanen.

3. Institutsbibliotheken

In Hochschulinstituten werden oftmals zusammen mit Büchern auch Zeitschriftenartikel katalogisiert. Viele haben schon einen OPAC eingerichtet, die Ausleihe wird aber nur selten automatisiert, und dann in der Regel mit dem Einfach-Programm aLFA, nicht mit dem aufwendigen aLF. An einigen Universitäten sind die Institute sogar durch Senatsbeschlüsse gehalten, für die Katalogisierung nichts anderes als allegro einzusetzen, weil man eine gewisse Einheitlichkeit sichern will, ohne die das Zusammenführen der Daten nicht praktikabel ist.

4. Öffentliche Bibliotheken

In Niedersachsen und in Berlin gibt es eine beträchtlich große Zahl von ÖBs als allegro-Anwender. Für Niedersachsen ist offiziell und mit ministerieller Förderung die Büchereizentrale Lüneburg dafür zuständig, eine Standardversion zu parametrieren, zu pflegen und zu vertreiben, sowie auch Schulungen und Vor-Ort-Dienstleistungen zu erbringen - gegen entsprechende Entgelte. Eine Zielvorstellung ist, daß hierdurch die ÖBs auch einen Zugang zu den Datenressourcen des Pica- Verbundsystems erhalten können. Viele ÖBs importieren CD-ROM- und Diskettendaten der Deutschen Bibliothek und aus dem VLB.Viele wollen das Ausleihprogramm einsetzen, einige haben damit schon begonnen.

EIne besondere Gruppe Öffentlicher Bibliotheken sind die Auslandsbibliotheken des Goethe-Instituts. Die Zentrale in München betreut diese Institute und liefert ihnen auch Daten.

5. Schulbibliotheken

Insgesamt gibt es ungefähr 25 Schulen im Sekundarbereich und berufsbildende Schulen, die allegro zur Katalogisierung und z.T.auch als OPAC einsetzen. In allen Fällen sind es einzelne Lehrer, die sich für die Materie interessieren und die Durchführung übernommen haben. In Niedersachsen haben ein paar Lehrer auch Kontakt zur Büchereizentrale Lüneburg und versuchen, von dort Know-how für ihre Zwecke zu übernehmen.

6. Parlaments-, Archiv- und Behördenbibliotheken

Das Hauptinteresse in dieser Gruppe ist die Katalogisierung bzw. Dokumentation. Es gibt einige OPACs, es wird z.T. auch die Schlagwort-Normdatei eingesetzt. Einige Archive haben begonnen, Datenbanken für Archivalien anzulegen. Großes Interesse besteht für die Ende 1994 freigegebene Spezialversion für Graphik-Anbindung, um gescannte Dokumente zugreifbar zu machen.

7. Spezialbibliotheken

Eine Untersuchung des DBI, über die kürzlich berichtet wurde ("Bibliotheksdienst" 1995/2), hat ergeben, daß in Spezialbibliotheken allegro das zahlenmäßig meistverbreitete DV-System ist. In der Regel werden Katalogdatenbanken aufgebaut,immer öfter werden diese in den hauseigenen Netzen für die Angehörigen der Institution zugänglich gemacht. Man ermöglicht es den Teilnehmern, Daten für ihre Zwecke herunterzuladen, entweder zur Einbeziehung in Texte oder in persönliche Datenbanken, wozu dann auch "Downloads" aus anderen (Online- oder CD-)Datenbanken beitragen können, umgewandelt mit dem IMPORT-Programm.

Besonders aktive Untergruppen sind Kunst- und Museumsbibliotheken (Projekt capriccio), Musikbibliotheken (Projekt bolero) und Handschriftenabteilungen (Projekt HANS).

8. Kirchliche Bibliotheken

Eine überkonfessionelle Arbeitsgemeinschaft wird von sehr aktiven allegro-Anwendern gebildet, die unter sich Daten und Parameter austauschen und sich um Standardisierung bemühen. Es gibt Anwender in Ordinariaten, Abteien, Archiven und kirchlichen Ausbildungsstätten. Die Abteien betreiben einen Zentralkatalog alter Bücher.

9. Sinologische Bibliotheken

Es gibt eine europäische Gruppe, genannt EASL (= European Association of Sinological Librarians). Führend in der allegro- Anwendung sind Oxford (East Asia Department der Bodleian), Berlin (Staatsbibliothek, Ostasienabteilung) und Heidelberg (Sinologisches Institut der Universität). Etliche andere haben die Parametrierung von einer dieser Stellen übernommen, wie z.B.die British Library.

Man benutzt eine PC Front End Software zur Darstellung von etwa 20.000 chinesischen Zeichen. Es zeigte sich schon vor einigen Jahren, daß allegro keine Probleme hat, mit diesem Front End zusammen zu funktionieren und sogar brauchbare Register mitchinesischen Schriftzeichen zu produzieren - obwohl es für das Chinesische keine "alphabetische" Ordnung gibt.

Ein ähnliches Front End wurde auch für das Japanische geschaffen. In Oxford wird dieses schon für die Umwandlung von NACSIS- Daten benutzt. Das ist eine in Tokyo angesiedelte Einrichtung, die auf ihrem Host-Rechner die Japanische Nationalbibliographie hält. Bibliotheken mit japanischen Beständen in Großbritannien wollen alle diese Datenbank nutzen, und die meisten werden dies wohl mit allegro machen.

10. Projektbezogener Einsatz

In etlichen Institutionen laufen Projekte, für die spezielle Datenbanken aufgebaut werden müssen. allegro dient dann als allgemeines Datenbanksystem, das für die jeweiligen Zwecke an Ort und Stelle konfiguriert wird.

Anwender im Ausland

In Österreich und der Schweiz gibt es naturgemäß die meisten ausländischen Anwender. (Die Bibliotheken der Goethe-Institute, umden Globus verstreut, sind als deutsche Einrichtungen anzusehen und arbeiten auch in Deutsch.) Da die Software aber im Prinzip mehrsprachig ist, gibt es zumindest kein prinzipielles Hindernis für den Einsatz in Ländern mit anderen Sprachen. Die sinologische Gruppe, wie erwähnt, hat einige Mitglieder, die in Englisch und Chinesisch oder Japanisch arbeiten. Ein weiteres Beispiel sind Musikbibliotheken in Belgien, die eine teilweise schon flämische Oberfläche benutzen. Die UB Braunschweig hat im Auftrag des Ministeriums die Bibliothek der Ukrainischen Akademie der Wissenschaften in Kiew aktiv unterstützt, um dort allegro in der Katalogisierung einzuführen. Ein Mitarbeiter dort hat alle Menütexte und auch schon Teile der Dokumentation ins Russische (!) übersetzt, und es wird mit dem kyrillischen Zeichensatz gearbeitet.

Nach 14 Jahren Entwicklungsarbeit kann allegro nunmehr das Spektrum vom kleinen Einzelplatzsystem (auf billigsten PCs) bis hinzu umfangreichen Mehrplatzsystemen in großen Staats- und Hochschulbibliotheken abdecken.

Die UNIX-Version allegro-X ist nach erfolgter Umstellung auf Version 14 gerade erst "im Kommen", hat aber ein großes Potential für die Bereitstellung von Datenbanken im Internet, und hier ist es besonders die Komponente für den Zugang per WWW, die jetzt zunehmend interessant wird.

Konkurrenz allegro - Pica?

Gelegentlich wird immer noch einmal gefragt, ob denn nicht die Heraufkunft des Pica-Systems für allegro über kurz oder lang das Ende bedeutet. Nun, langfristig muß jedes Produkt sich in einer Art Evolution weiterentwickeln oder irgendwann Platz machen für ein besseres - das gilt genauso für Pica. Die allegro-Anwenderschaft hat in ihrem Umfang längst die "kritische Masse" überschritten, die ein schnelles Verschwinden von der Bildfläche nicht mehr zuläßt. Die Entwicklungsarbeit geht weiter, obwohl die UB Braunschweig ihren OPAC und ihre Ausleihe im März 1995 auf Pica umgestellt hat. Die Mehrheit der jetzigen allegro- Anwender hat keine Möglichkeit oder kein Interesse, Pica-Teilnehmer zu werden, d.h. im Normalfall besteht gar keine Konkurrenzsituation.

Für den interessierten Leser ist es nicht notwendig, hier in viele Einzelheiten zu gehen oder gar einen umfangreichen Vergleich zwischen beiden Systemen anzustellen. Zwei Feststellungen reichen aus, um zu begründen, warum auch das Niedersächsische Ministerium weiterhin allegro neben Pica für notwendig hält und deshalb weiter fördert:

  • Ein lokales Pica-System (LBS3) kann man nur betreiben, wenn man als Vollmitglied an einem Pica-Verbund angeschlossen ist, denn LBS3 hat keine lokale Katalogisierung und keine lokale Software zur Fremddatennutzung, auch nicht für Kartendruck etc.
  • Ein komplettes Pica-LBS3 ist erheblich teurer (sowohl hinsichtlich Hardware, Systemsoftware, als auch Betreuungsaufwand) als ein allegro-System gleichen Leistungsumfangs. Es läuft bisher nur auf DEC-Rechnern (VAX-Systemen) und (noch nicht mit vollem Umfang) auf UNIX-Systemen. Ein PC-System ist LBS3 nicht und kann es auch nicht werden.

Vor diesem Hintergrund könnte die Frage aufkommen: Warum überhaupt LBS3 und nicht vielmehr nur noch allegro? Vor wenigen Jahren hätte man diese Frage noch nicht stellen können, denn allegro hatte noch keine Ausleih- und Erwerbungskomponenten. Was derzeit im Verbund realisiert wird, beruht aber natürlich auf zeitlich zurückliegenden Planungen. Für neue Installationen hat man von veränderten Randbedingungen auszugehen, zumal der Pica-Verbund sich beträchtlich vergrößert hat und auch viele Spezialbibliotheken und ÖBs an der Teilnahme interessiert sind. Die noch bestehenden bedeutsamen Vorteile des LBS3 - stärkere Integration mit dem Zentralsystem, kontinuierliches Updating, Fernleihkomponente, bessere Möglichkeiten des zentralen Managements für das Gesamtsystem - können nur einer überschaubaren Zahl von Teilnehmern zugute kommen. Daher wird beim BRZN offiziell eine Pica-Parametrierung des allegro-Systems gepflegt (mit vollem Umfang von über 1200 Kategorien), und die Entwicklungsabteilung in Braunschweig hat etliche notwendige Verbesserungen am Kernsystem dafür durchgeführt.

 



[i] zuletzt aktualisiert: 13.03.2017
Email: ub@tu-bs.de