Ausgabe 97/3, 22. Juli 1997
Diese Ausgabe hat 12 Seiten
Universitätsbibliothek der Technischen Universität Braunschweig, Pockelsstr. 13, D-38106 Braunschweig, Tel. (0531) 391-5011, -5026, FAX -5836
Show me the gates to the Promised Land
or at least the windows to view it!
Where are we led
on the road ahead?
And what if too many lights are red?
Before we do it, better we knew it ...
V15 - wieder nur ein Meilenstein oder eine Zäsur, Gipfel- oder Wendepunkt, nur eine weitere Zwischen- oder doch die Endstation? Nun, die liegt noch immer in einiger Ferne, aber die Richtung ist jetzt immerhin bekannt, deshalb konnte endlich die voraussichtlich günstigste Fahrtroute abgesteckt werden. Das Warten auf "die Windows-Version" dauert ja schon geraume Zeit. Das ist jedoch gut so, denn wäre man schon vor zwei Jahren auf den "Zug der Zeit" aufgesprungen, dann wäre jetzt bereits wieder eine grundlegende Revision nötig, man hätte die DOS/UNIX-Programme viel zu früh einfrieren müssen, und es gäbe wohl den avanti-Server und damit das WWW-Potential noch nicht. In der Nummer 46 wurde schon knapp umrissen, in welche Richtungen nach V15 weitergearbeitet werden kann. Die Umfrage half dann bei der Klärung, wo entlang die Reise denn nun wirklich gehen soll. Auf dieser Seite geben wir einen knappen Überblick, auf den folgenden Seiten werden die neueren Erkenntnisse und Arbeitsansätze dann genauer dargestellt.
Auf dem vor uns liegenden Weg waren noch drei Voraussetzungen zu schaffen, bevor auf ganzer Strecke grünes Licht für die Windows-Entwicklung geschaltet werden konnte:
In der Nummer 46 und in der E-Mail-Liste hatten wir eine Umfrage veranstaltet, um einen Überblick über Situation und Bedarf der Praxis zu gewinnen. Uns erreichten 60 Rücksendungen. Die aus der Sicht der Entwicklung wichtigen Ergebnisse sehen so aus:
| Betriebssystem | Sehr wichtig | Auch wichtig | Summe | Nicht wichtig / k.A. |
| DOS | 34 | 14 | 48 | 12 |
| Win 3.x | 21 | 15 | 36 | 24 |
| Win 95/NT | 29 | 19 | 48 | 12 |
| UNIX | 12 | 7 | 19 | 41 |
| X-Terminal | 2 | 3 | 5 | 55 |
| Browser | 24 | 9 | 33 | 27 |
Die 32bit-Systeme Windows 95 und NT sind hier zusammengefaßt, weil sie für die Entwicklung nicht unterschieden werden müssen. Win 3.x dagegen, als 16bit-System, muß man getrennt sehen.
Drei Beobachtungen sind hier sehr wichtig:
Zum Thema DOS dürfen keine Mißverständnisse aufkommen: man wird auf DOS ohnehin erst dann ganz verzichten können, wenn jede der Komponenten eine graphische Entsprechung gefunden hat. Zumindest die Programme INDEX, QRIX und SRCH sind hier zu nennen, aber besonders auch aLF, ORDER, REF und das CockPit. Sie alle haben wichtige Aufgaben im Gesamtsystem und können unmöglich in einem Rundumschlag alle ersetzt werden. "Logischer Abschluß" heißt nur: neue Kernfunktionen und größere Oberflächenverbesserungen für DOS wird es nicht mehr geben, wohl aber Verbesserungen z.B. an aLF und ORDER. Man muß aber betonen: wir schleppen hier keinen Ballast mit, indem wir DOS weiter unterstützen und kompatibel halten, denn Oberflächen- und Kernfunktionen sind jetzt streng getrennt!
Zwar liegen die UNIX-Interessenten rein zahlenmäßig hinter den Win 3.x- Interessenten, doch ist es keine Frage, daß UNIX als Server-Plattform weiter unterstützt werden muß. Das ist auch kein Problem, da die Kernbestandteile, die Klassenbibliothek und darauf aufbauende Produkte wie der für Web-Anwendungen sehr wichtige avanti-Server, plattformunabhängig programmiert sind. Fast niemand arbeitet jedoch nur unter UNIX mit allegro (Beobachtung 2)! Das bislang anvisierte Ziel einer ebenfalls plattformunabhängigen Oberflächen-Programmierung kann deshalb in Frage gestellt werden. Wenn man berücksichtigt, daß UNIX-basierte Datenbanken mehr und mehr über Internet und Browser benutzt werden, muß ein Schwerpunkt jetzt auf Web-Entwicklungen gelegt werden - was de facto schon geschehen ist. Die im Paket ACWWW25 zusammengefaßten HTML- und Perl-Skripte haben sich schon sehr verbreitet, laufen auf allen gängigen Web-Servern (UNIX, Linux und Windows) und sind offen für lokale Erweiterungen.
Nun aber nochmals zu Windows! Schon seit einer Weile wird Windows 3.1 vom Hersteller nicht mehr vertrieben, und neue Rechner werden durchweg mit Win'95 oder NT ausgeliefert und sind dafür auch genügend mächtig. Für Entwickler ganz entscheidend ist aber dies: wenn man so entwickelt, daß die Programme unter Win 3.x laufen (und dann automatisch auch unter 95/NT), dann nutzt man die Leistung der 32bit-Systeme mit solchen Programmen nicht aus, man verzichtet auch auf die effizienten Möglichkeiten, welche die neuen Compilersysteme bieten. Daß augenscheinlich niemand mehr kommerziell Win 3.x-Software entwickelt, liegt einfach daran, daß es sich keine Firma leisten kann, mit hohem Aufwand diesen schrumpfenden Markt noch zu bedienen. Für allegro ist das keine Entscheidung über Leben und Tod: weil die DOS-Unterstützung weitergehen muß, profitieren auch die Win 3.x-Anwender davon mit und sind nicht abgeschnitten, denn die DOS-Programme laufen ohne Einschränkung in der DOS-Box von Windows 3.x. Und solange es NetScape für Win 3.x gibt, können solche Rechner auch als Inter- und Intranet-Clients arbeiten. Einige der Rechner, die momentan noch mit Win 3.x arbeiten, können im übrigen auch auf Win'95 aufgerüstet werden. Wenn nicht, nun ja, dann wäre ein monolithisches Windows-allegro darauf wohl nur zum Kriechen, aber nicht zum Laufen zu bringen. Für das bisherige, noch unvollständige Presto-W mußte ja bereits der Win32s-Zusatz herangezogen werden, aber auch das hat seine Grenzen.
Realistisch gesehen wäre es so, daß eine als vollwertiger Ersatz für PRESTO einsetzbare Windows-Anwendung erst irgendwann nach 1998 erwartet werden könnte, wenn man Win 3.x mit berücksichtigen wollte. In dem Zeitraum wird aber mit Sicherheit die Basis von Win 3.x weiter schrumpfen, die der 32bit-Systeme stark expandieren.
Die angesammelten Erfahrungen konnten zunächst einmal zu sechs grundlegenden Forderungen verdichtet werden:
Die letzten zwei Forderungen erscheinen gegenüber den anderen ein wenig speziell, doch stecken gerade in diesen wichtige Ergebnisse der Erfahrung mit dem konventionellen System.
Auf dieser Basis ist jeder neue Ansatz zunächst einmal in seinen Grundlinien zu bewerten. Manche Ansätze fallen diesen Kriterien schnell zum Opfer. Zum Beispiel jede Art von Masken- oder Formularsystem: Forderungen 1, 5 und 6 sind damit nicht oder kaum erfüllbar, weil die meisten Konfigurationen zuviele Felder haben (bis zu mehr als 1000!) und z.B. Wiederholungsfelder und Felder mit großer Länge dann nicht elegant realisierbar sind. Gleichfalls abzulehnen ist das andere Extrem: ein Entwurf mit einem einzigen, großen Text-Eingabefeld für die freie Eingabe aller Kategorien; so etwas würde gegen 2, 3 und 4 verstoßen (und wäre nun wirklich antiquiert).
Wenn man mehr ins Detail geht, kommt eine viel größere Zahl von Forderungen zusammen, und leider kann man kaum eine davon als weniger wichtig oder verzichtbar abtun, will man nicht Grundforderung 3 verletzen:
| [a] | DOS-Datenbanken müssen ohne Änderung der Struktur auch unter Windows bearbeitbar sein, und zwar gleichzeitig von DOS und Windows aus. Intern darf sich also nichts ändern, was aber nicht heißt, daß eine Datenbank unter Windows genauso aussehen muß! Die Daten können gänzlich anders präsentiert werden. |
| [b] | Plausibilitätsprüfung sofort bei Eingabe eines Feldes, nicht erst beim Abspeichern des ganzen Satzes (s.a. [i]). |
| [c] | Variable Länge für alle Felder (die für manche Datenbanken typische Grenze von 255 Zeichen ist zu knapp); es darf keine Notwendigkeit geben, Längenbeschränkungen vorzugeben. |
| [d] | Mehrfachfelder: im Prinzip muß jedes Feld wiederholbar sein; auch wenn es zunächst nicht so definiert wurde, muß dies leicht zu ändern sein. |
| [e] | Kopieren einzelner Felder von einem Satz zum anderen. Dies leistet der konventionelle Hintergrundspeicher. Er sollte im Prinzip erhalten bleiben, aber in einem Auswahlfenster übersichtlicher als bisher angeboten werden. |
| [f] | Phrasenspeicher: vorbereitete Zeichenketten zur Einfügung an jeder beliebigen Stelle. Zusätzlich muß es im neuen Konzept auch die (zwar umständlichere aber) Windows-übliche Cut-and-Paste-Methode geben. |
| [g] | Abhängigkeiten zwischen Feldern sollten schon bei der Erfassung zum Ausdruck kommen. Die Abfragelisten realisieren das mit Sprungbefehlen: Wenn Feld A eingegeben wurde, springe nach X, wenn nicht, dann nach Y. |
| [h] | Pflichtfelder: gleich bei der Eingabe muß erkennbar sein, wo man etwas eingeben muß. |
| [i] | Programmierbare Prüfroutinen: die parametrierbaren, anwendungsspezifischen Feldprüfungen (PV-Routinen) des DOS-Systems müssen voll einsetzbar sein (Handbuch 10.2.8 und S.5-7 in diesen news). Neben strengen Prüfungen, die zur Zurückweisung einer Eingabe führen, muß es unverbindliche Hinweise auf mögliche Irrtümer geben. |
| [j] | Hierarchische und verknüpfte Sätze: für mehrteilige Veröffentlichungen müssen nach wie vor beide Konzepte realisierbar sein. |
| [k] | Satztypen: anwendungsspezifisch müssen in einer Datenbank mehrere Typen von Datensätzen existieren können, und das Erfassungssystem muß das unterstützen. Die konventionellen Abfragelisten haben sich hier sehr bewährt und werden geschätzt, sie müssen deshalb durch etwas mindestens Gleichwertiges ersetzt werden. |
| [l] | Zusätzliche Felder müssen frei eingebbar sein. Das konventionelle System setzt hierfür die Kenntnis des Kategorienschemas voraus, hier sollte das neue Konzept die Feldliste (aus der .CFG) als Hilfe anbieten. |
| [m] | Externe Bearbeitung eines Satzes sollte ermöglicht werden (z.B. mit X-Editor oder Notepad). Konventionell ging das bereits mit dem Programm PRESTOG, aber nur für einzelne Felder. |
| [n] | Visuelle Kontrolle des in Bearbeitung befindlichen Satzes. Konventionell kann man sich mit dem D-Befehl jederzeit die Anzeigeform ansehen. Das neue Konzept könnte eine aufbereitete Form oder auch verschiedene Formen des Satzes ständig in einem Fenster zeigen, in welchem jede Eingabe sofort im Kontext sichtbar werden sollte. |
| [o] | Übersichtlichkeit: Der Bildschirm darf nicht mit Fenstern und Kontrollelementen überfrachtet sein. Anders sind die Forderungen 6. und [n] kaum erfüllbar. |
| [p] | Stammsätze: Wird z.B. während der Eingabe eines Titelsatzes festgestellt, daß ein Stammsatz noch fehlt und zuerst erfaßt werden sollte, muß man diesen unmittelbar eingeben können, bevor man mit dem Titelsatz fortfährt. Diese Möglichkeit und auch der ständige Registereinblick während der Erfassung ergeben sich aber aus der Tatsache, daß man in Windows-Programmen jederzeit neue Fenster aufmachen kann. (Ein Tip: Unter Win'95 kann man eine Datenbank im Mehrplatzmodus betreiben und sie dann in zwei oder mehr DOS-Fenstern gleichzeitig benutzen.) |
Soviel wird (hoffentlich) klar: Es kann nicht unter Windows automatisch ein ganz einfaches Erfassungssystem geben, das keine Fehleingaben mehr zuläßt und von jedermann sofort intuitiv beherrschbar ist. Bibliotheks- und zumal Katalogdaten sind nun einmal nicht so einfach wie Adressen-, Warenlager- oder Rechnungsdaten. Versuche, sie drastisch zu vereinfachen, laufen immer auf drastische Kompromisse hinaus, die nur leider nicht sofort ins Auge stechen.
Was Sie unten sehen, ist die EBOX - die Editor Box oder das Bearbeitungsfenster. Diese Box soll immer dann erscheinen, wenn ein Datensatz zu bearbeiten oder einzugeben ist. Da sich dieser Entwurf noch in der Erprobungsphase befindet und funktional noch nicht voll ausgereift ist, kann sich das Erscheinungsbild noch ändern. Noch nicht realisiert sind die Forderungen [f] und [i], auch ein paar andere Punkte können noch verbessert werden.
Die Situation im Bild ist diese: Links als Auswahlliste die Übersicht eines hierarchischen Datensatzes (altmodisch, aber man soll sehen, daß es geht), rechts im Displayfeld seine Darstellung mit Hilfe der Anzeigeparameter (hier D-W.APR). Die Kategorie #19 des ersten Untersatzes wurde ausgewählt und steht zum Bearbeiten unten im Eingabefeld.
Die EBOX hat nur vier Bereiche: [o]
(in eckigen Klammern sind die Buchstaben der oben aufgezählten Forderungen angegeben.)
#-( hat, kann man mit Druck
auf den [Display]-Knopf auf diesen Abschnitt umschalten und
eine alternative Anzeigeform sehen. [n]
Bei der Anzeige werden alle Daten intern zwischen ASCII und ANSI über Tabellen gewandelt. Diese Tabellen sind anwendungsspezifisch modifizierbar und für jedes Kategoriesystem verwendbar (Dateien d.apt und o.apt). [a]
Ein Testprogramm namens EBOX.EXE für Win'95/NT liegt auf dem FTP-Server bereit. Wer will, kann es ausprobieren. Es hat noch keine Verbindung mit einer Datenbank, sondern ist nur zum Testen des neuen Konzepts gedacht. Noch nicht alle oben im Konzept erwähnten Funktionen sind implementiert. Es wird also in absehbarer Zeit eine erweiterte Version geben, bevor dann EBOX als Teil eines weiterentwickelten Presto-W erscheinen kann, oder auch als Bestandteil in neuen Programmen. Andere, speziellere Editormodelle können bei Bedarf hinzukommen.
Der Hilfsabschnitt H in der Index-Parameterdatei,
zuständig für die Programmierbaren
Validierungen, wird jetzt nicht mehr nur NACH Einordnen
einer Kategorie angesprungen, sondern auch noch in anderen
Fällen.
Damit man die Fälle auseinanderhalten kann, ist dann jeweils
die Sonderkategorie #u2 mit einem speziellen Wert
belegt. Diesen kann man am besten mit einem Befehl wie #u2 +X
c"y" e0 prüfen: wenn in #u2 ein
'y' steht, wird zum Abschnitt #-X gesprungen.
#u1 enthält den Eingabetext einschließlich
seiner Kategorienummer.
| 0 |
Die Eingabe stammt aus der Abfrageliste, d.h. es
wurde soeben [Enter] gedrückt, und die
Kategorie ist noch nicht in den aktuellen Datensatz
eingeordnet. (Wird die Abfrage leer weggedrückt,
passiert nichts.) #u2 0 , in diesem Fall ist:
#u1 = Eingegebene Kategorie incl. Nummer also z.B.
#u1 #40 Name, Vorname
|
| 1 |
Eingabe stammt aus Direkteingabe (am Promptzeichen)
#u2 1 , ansonsten wie 0
|
| 2 |
Eingabe stammt aus Bearbeitungsfenster (Befehl #b)
#u2 2 , ansonsten wie 0
|
| e |
Sofort nach Beendigung der Abfrageliste (nach Beantwortung
der letzten Frage) #u2 e , |
| s | Vor dem Speichern (es wurde [F10] oder #rj gegeben) |
| s |
Vor dem Speichern (es wurde [F10] oder
#rj gegeben) #u2 s
|
| E |
Vor Freigabe des Satzes zum Bearbeiten ('E' wurde
auf dem Anzeigemenü gedrückt) #u2 E
|
| C |
Vor Freigabe des kopierten Satzes ('C' auf Anzeigemenü)
#u2 C
|
| I |
Vor Einstieg in die Abfrageliste ('I' auf Anzeigemenü)
#u2 I
|
Damit hat man nun viele zusätzliche Möglichkeiten, die eingegebenen Daten zu prüfen, zu manipulieren und Fehlerausschriften zu produzieren.
Folgende Einzelheiten sind zu beachten:
M einordnen lassen. Auch das
geht bei beliebiger Länge.
Beispiel:
Wenn [E] gedrückt ist, soll aus Kategorie #90 das Teilfeld $P hilfsweise in #90z kopiert werden. Diese kann somit getrennt bearbeitet werden. Vor dem Speichern soll #90z wieder als $P an die #90 angehängt werden.
H Hilfsabschnitt #u2 +a c"E" e0 Vorbearbeitung (es wurde 'E' gedrückt) #u2 +a c"C" e0 mit kopierten Sätzen soll dasselbe passieren #u2 +b c"s" e0 vor dem Speichern (F10 wurde gegeben) #+- Andere Fälle: nichts machen #-a #90 $P p"#90z" M $P als #90z speichern #90 ~P p"#90 " M $P aus #90 löschen, #90 wieder einordnen #+# #-b F10 #90 dc9 ac9 #90 und #90z in #uc9 zusammenbauen #90z p"$P" Ac9 #uc9 p"#90 " M Inhalt von #uc9 als #90 wieder einmischen #90z p"#90z" y0 e4 M #90z wieder löschen #+#
Die bisherige PV-Methodik bleibt unberührt. Sie reagiert
auf Kategorien, die soeben bereits in den Aufnahmespeicher
eingeordnet WURDEN. (Mit Befehl M kann man sie trotzdem
verändern oder auch löschen (Handbuch S. 200).)
Soll beides kombiniert werden, beginnt der Hilfsabschnitt am besten so:
H Hilfsabschnitt
Ausführung erfolgt, nachdem
- Abfrage beantwortet wurde (dann ist #u2 belegt), und nachdem
- eingegebene Kategorie eingemischt wurde (#u2 nicht belegt)
#u2 +0 c"0" e0 Abfragezeile wurde beantwortet (Eingabe ist in #u1)
#u2 +1 c"1" e0 Neue Kategorie wurde eingegeben (Eingabe ist in #u1)
#u2 +2 c"2" e0 Kategorie wurde mit #b bearbeitet (Eingabe ist in #u1)
#u2 +e c"e" e0 Abfrageliste ist zu Ende
#u2 +s c"s" e0 F10 wurde gegeben
#u2 +E c"E" e0 E wurde gegeben zum Bearbeiten
#u2 +C c"C" e0 C wurde gegeben: Kopie des aktuellen Satzes bearbeiten #u2 +I c"I" e0 I wurde gegeben: neuen Datensatz per Abfrageliste eingeben
... bisheriger PV-Abschnitt (#u2 nicht belegt), oder aber
#+- wenn NACH dem Einordnen der Kategorie keine Prüfung mehr folgen soll
#+#
#-0 Abschnitt für Fall 0
... Vermutlich wird man meistens auch in den Fällen 1 und 2 nach #-0
verzweigen, statt dafür getrennte Behandlungen vorzusehen!
Empfehlung:
Wenn die bisherigen PV-Methoden ausreichen, die man sich eingerichtet hat, setzt man am besten am Anfang des Hilfsabschnitts zur Sicherheit den Befehl
#u2 +- e0 In den neuen PV-Fällen soll nichts passieren
ein. Dann braucht weiter nichts geändert zu werden.
Zur Erinnerung: die Sprungmarken im Hilfsabschnitt sind unabhängig von denen im Hauptteil, d.h. man braucht auf letztere keine Rücksicht zu nehmen, aber die Teile des Hilfsabschnitts können nicht vom Hauptteil aus angesprungen werden (ist auch nicht nötig).
Es konnte passieren (aber nur bei simultanen Updates mit
schnellen PCs auf langsamen Servern), daß IdNummern (per
cg/ci-Befehl in der CFG) doppelt vergeben
wurden oder .LOG-Sätze nicht stimmten. Diese und andere sehr
selten auftretende Randprobleme (auch bei zwei oder
mehr simultanen globalen Ersetzungen/Manipulationen) wurden
ausgeräumt.
Die nachfolgend beschriebenen und allesamt beseitigten Probleme waren zwar manchmal irritierend oder unangenehm, aber alle harmlos, d.h. es wurden keine Daten verfälscht.
Wenn eine Kategorie neu eingegeben wird, verschwindet eine schon
vorhandene mit gleicher Nummer, d.h. sie wird überschrieben.
Einerseits sehr bequem, andererseits manchmal unerwünscht, z.B.
wenn man irrtümlich die falsche Nummer eingegeben hat. Nun wird
die bereits vorhandene Kategorie vor dem Überschreiben in den
Hintergrundspeicher kopiert. Mit #a kann man sie also
wieder sichtbar machen und zurückholen.
Noch immer konnte man eine Kategorie dadurch löschen,
daß man schlicht nur die Kategorienummer eingab, ohne Text.
Genauer gesagt, das ging noch bei den Kategorienummern ohne
Wiederholungszeichen, also z.B. #31, aber nicht bei #31a oder #31p etc.
Dies wurde jetzt behoben. Löschen ist jetzt nur noch mit
#v möglich, und beim Fenster-Editor (#b)
dadurch, daß man den gesamten Text löscht, die
Kategorienummer aber stehenläßt.
Das Löschen von Ergebnismengen geht jetzt schneller. Bisher wurde jeder gelöschte Satz nochmals angezeigt. Bei sehr langen Sätzen hemmte das leider den Vorgang; es mußte dann erst [x] gedrückt werden, um aus der Anzeigeschleife herauszukommen. Jetzt läuft alles ohne Anzeige durch.
Wenn innerhalb einer Ergebnismengen-Löschung die
Löschkontrolle das Löschen eines Satzes verhinderte, blieb
dieser gesperrt zurück! Das wurde ausgemerzt, aber
gelöscht werden solche Sätze nicht. Auch -a3
nützt da nichts, während das Einzel- Löschen damit jetzt
möglich ist:
Da im Bibliothekswesen das Vorkommen von Ausnahmen eine
verläßliche Regel ist, bleibt es nicht aus, daß auch
mal ein Satz gelöscht werden muß, der durch die
Löschkontrolle nicht durchkommt (Kap. 10.2.6.8, S. 216). Z.B.
wenn ein Stammsatz aus Versehen verdoppelt wurde. Zwar gab es da
einen Trick, aber die logische Lösung war, das Löschen
wenigstens bei der begehrten Berechtigung -a3 zu
gestatten. Der Hinweis "Keine Löschung, da
verknüpft" kommt zwar, aber auch die Frage
"tilgen? j/n", und die Antwort 'j' bewirkt dann
die Löschung, wie sonst auch.
Unter dem Betriebssystem Windows NT bequemt sich in der Regel der Drucker erst dann, wenn das Programm den Druckerkanal schließt. Das tat PRESTO aber nur, wenn man die Sitzung beendete. Also kamen die Karten nicht sofort bei Druck auf [F2] heraus, sondern eben erst beim Verlassen des Programms. Jetzt wird intern der Druckerkanal nach jedem [F2] geschlossen und gleich wieder geöffnet. Der Effekt: alles kommt sofort raus, wie erwartet.
Die Standard-Indexparameter CAT.API wurden überarbeitet. Einerseits sind Beispiele für Restriktionen eingebaut worden (erkennbar am Kommentar "RESTR"), Vorkehrungen für die satzübergreifende Suche getroffen (Kommentar "SR"), aber es wurden auch die Zeitschriften und Serienkürzel (Kategorie #8na) in die V14-Ersetzungen einbezogen. Das bedeutet: wenn in #70 jetzt ein Kürzel mit '_' davor steht, braucht nicht mehr nachgeladen zu werden, sondern der Serientitel wird per V14- Methode eingesetzt. Dadurch vereinfachten sich die Anzeigeparameter D-1.APR. Es verbesserte sich aber auch das Register 5: die Stücktitel oder Aufsätze sind jetzt direkt unter dem Titel zu finden, nicht mehr unter dem Kürzel.
Mit verknüpften Untersätzen hatten Kartenfans ihre Not:
per [F3] und [d] gelang es seit einer Weile nicht
mehr, ausgewählte Einzelkarten auszudrucken. Jetzt geht das wieder;
die unbeliebte Meldung "Anzeige verschieben ..."
unterbleibt. Soll für jeden Untersatz (Band) eine
separate Karte entstehen, muß ein Befehl #t{ N }
(Handbuch S. 170) dort stehen, wo die Verarbeitung eines nachgeladenen
Untersatzes beginnt. In die Datei P-KARTE.APR ist das
eingebaut.
Die beliebten Flips holen sofort einen anderen Datensatz oder einen Registerabschnitt auf den Bildschirm. Jetzt kann mit der Taste [Bild[hoch]] gleich zurück zum Ausgangssatz geschaltet werden, wobei sich das Programm bis zu 32 Sätze merkt, die man mit [Bild[hoch]] und [Bild[runter]] durchblättern kann. Also: man kann ruhig schnell mal eben eine Fliptaste drücken und schauen, was dann kommt. Mit [Bild[hoch]] (= Flap) ist der Ausgangssatz dann sofort wieder da. Mit [L] erhält man, wie schon in Nummer 45 berichtet, die Liste der 32 gemerkten Sätze als Ergebnismenge.
Ist das allegro-System zu umfangreich geworden? Einsteiger haben schnell das Gefühl, den sprichwörtlichen Wald vor lauter Bäumen und Gestrüpp nicht sehen zu können. Nun gibt es zwar die neue Ouvertüre mit einem umfassenden und aktuellen Glossar, das viele Fragen beantwortet. Jedoch beschränkt sie sich im praktischen Teil auf das Arbeiten mit schon existierenden Datenbanken. Wie aber fängt einer mit null Ahnung an, eine ganz neue Datenbank zu entwickeln?
Lehrbücher für Programmiersprachen fangen heute meistens so an, daß ein ganz kleines Programm, praktisch das einfachste überhaupt mögliche arbeitsfähige Programm, vorgestellt wird, und dann zum sofortigen Nachmachen gezeigt wird, wie man dieses eingibt und dann zum Laufen bringt. So einfach das Programm auch ist (meistens tut es nichts anderes als die Meldung "Hello World!" auf dem Bildschirm auszugeben), man lernt dabei doch schon etliche der wichtigsten Handgriffe und Denkschritte. Eben diejenigen Dinge, darauf kommt's an, die bei jedem Programm immer wieder zu tun sind. Diese beliebte Methode kann man auch einmal für allegro versuchen. Die erste Lektion muß dann natürlich heißen: "Wir machen die einfachste mögliche Datenbank." Es wird sogar ein klein wenig mehr als das, aber mit zwei Seiten ist die Lektion gar nicht mal lang.
OK, was brauchen wir für eine Datenbank? Nur ein Unterverzeichnis und drei kleine Dateien!
Am einfachsten geht es, und lehrreich ist es, wenn wir uns auf DOS-Ebene begeben, und zwar ohne Norton-Commander oder XTREE-GOLD, auch ohne CockPit. (Gewiß, diese Programme sind ihr Geld wert, aber hierbei stören sie. Sie machen eigentlich unmündig: man kennt irgendwann die einfachsten Befehle nicht mehr, oder lernt sie gar nicht.)
Es sind vier Schritte zu tun, und zwar alle ausgehend vom Verzeichnis C:\ALLEGRO, dem Programmverzeichnis.
1. Ein Unterverzeichnis anlegen: das kann heißen, wie es will, also sagen wir mal TESTBANK. Wir geben ein:
md testbank (vorher mit cd C:\ALLEGRO auf das Programmverzeichnis wechseln)
Jetzt müssen die drei Dateien geschrieben werden. Wir zeigen hier, wie es "zu Fuß" mit dem X-Editor geht. Jeder andere Editor tut es auch, aber eine Antipathie gegen den X-Editor ist eigentlich irrational. Wie auch immer: ersetzen Sie den Aufruf X durch den Namen Ihres eigenen Editors, wenn Sie wollen. (Anhang D erklärt auf 1 Seite (!), was man über den X-Editor wissen muß: Zwei Minuten, die sich lohnen. Noch nicht gelesen? Soviel Zeit muß sein.)
Die drei Dateien legen wir alle auf dem neuen Unterverzeichnis TESTBANK an. Dann haben wir hinterher alles hübsch beisammen, was zur Datenbank gehört. Und können später alles leicht wieder löschen.
2. Erste Datei: Die Konfigurationsdatei (Handuch: Anhang A+B)
Wofür? In ihr steht, was für Felder (Kategorien) die Datenbank haben soll. Im einfachsten Fall ist das nur ein Feld!
Name: Frei wählbar, Typ muß
.CFG sein. Die Programme erwarten, wenn man nichts
anderes sagt, daß die Konfiguration $A.CFG heißt.
Wir nennen unsere Konfiguration aber B.CFG, damit man sieht,
was dann zu beachten ist, und wie die anderen Dateinamen
beeinflußt werden.
Befehl: x testbank\b.cfg Dann [Einfg] drücken (Schreibmodus einschalten) und folgendes eingeben: (Sie sind schreibfaul? Was kursiv gedruckt ist, brauchen Sie nicht einzugeben, das sind nur Kommentare)
Einfachste mögliche Konfigurationsdatei
B.CFG 970630
t2 2stellige Feldnummern
#u1 Die 8 Zeilen muss es immer geben
#u2
#00
#00
#00
#00
#00
#00
Es gibt nur 1 echte Kategorie: (Definitionszeile, mit '#' am Anfang)
#20"Titel"
Abfrageliste: auch nur diese eine Kategorie
(ohne '#' am Anfang! und blank hinter 20
20 " Titel: "
Wenn fertig eingegeben : [Esc][q][s] zum Speichern (jedenfalls beim X-Editor)
3. Zweite Datei: Die Index-Parameter. Handbuch: Kap. 7 + 10
Wofür? Darin steht, was für Register angelegt werden sollen, und auf welche Weise.
Name: Frei wählbar, aber nur bis zu 4 Zeichen lang. Wählen wir den Namen DAT. An den Namen ist die Typbezeichnung .BPI anzuhängen (das 'B' kommt von B.CFG). Die Datei heißt also dann DAT.BPI.
Befehl: x testbank\dat.bpi dann [Einfg] um den Schreibmodus einzuschalten, dann eingeben:
Parameter fuer die Indexerstellung : Fast minimales Grundgerüst ( zwei Register: Titelanfänge und Stichwörter) DAT.BPI 970630 *** 1. Grundparameter: (nicht ändern) *** zl=0 zm=0 ad=0 ag=0 *** 2. Überschriften der Register: ******* |1="1 : Stichwörter" |2="2 : Titelanfänge" |a=" ... Titel Ihrer Datenbank ..." *** 3. Befehle zur Schlüsselgenerierung ** ak=20+A nimm #20 und verarbeite es bei Sprungmarke #-A ak=20"[ ¶] "+B zerlege #20 bei Leerzeichen und ¶, dann Sprungmarke #-B *** 4. Abschnitte fuer die Ausführung *** #-A !u1 u p"|2" Titelanfänge: Reg. 2 (#u1 enthält den Inhalt von #20) #+# (Der Befehl u beseitigt den Artikel am Anfang) #-B !u1 p"|1" Stichwörter: Reg. 1 (#u1 enthält ein Stichwort aus #20) #+#
Wenn fertig eingegeben: [Esc][q][s] zum Speichern geben (X-Editor) Damit das klappt, Kopien machen: copy i.apt i.bpt (Tabelle der Zeichenumwandlungen für die Register, z.B. ä -> ae) und copy swl1.apt swl1.bpt (Stoppwortliste).
4. Dritte Datei: Die Anzeige-Parameter. Handbuch: Kap. 10
Wofür? Sie sagt dem Programm, wie ein Datensatz auf dem Bildschirm angezeigt werden soll.
Name: Frei wählbar, Typ muß .BPR sein (auch hier 'B' wegen B.CFG). Die Programme erwarten, wenn man nichts anderes sagt, daß die Datei D-1.BPR heißt, wenn man B.CFG verwendet, also nennen wir sie so.
Befehl: x testbank\d-1.bpr, [Einfg] für Schreibmodus. Hinterher wieder [Esc] q s zum Speichern
Anzeigeparameter : fast einfachste mögliche Ausführung
D-1.BPR 970630
#20 Kategorie #20 anzeigen
und als kleine Zugabe:
p ¶ 255 Zeilenumbruch beim Zeichen ¶ ( = Strg+t )
Und jetzt? Die drei Dateien sind da, aber wo ist die Datenbank? Die legen wir an mit folgendem Aufruf von PRESTO:
presto -kb -dc:\allegro\testbank -idat -S -n1 -a3
Eine leere Datenbank macht keinen Sinn, deshalb fordert das Programm PRESTO dann sofort dazu auf, einen Titel einzugeben (die Abfrageliste in der Konfiguration B.CFG wird aktiviert). Geben Sie also einen Titel ein. Danach [F10][j], und die minimale Datenbank mit nur einem Satz ist komplett. Sie sehen (mit NC, wenn Sie wollen) auf dem Unterverzeichnis, welche Dateien neu entstanden sind. Lesen Sie Handbuch-Kap. 0.8, um zu erfahren, was diese Dateien bedeuten und enthalten. Die neue Datenbank kann später wieder angewählt werden, indem man per CockPit Optionen / Datenverzeichnis das Verzeichnis TESTBANK anwählt und dann über Routinen/Benutzen einsteigt.
Ende der Lektion! Hiermit ist der gesamte Vorgang "Neue Datenbank erstellen" beschrieben. Grundsätzlich sind das die Schritte, die man immer machen muß, nur wird man in der Praxis sich mit viel mehr Einzelheiten herumzuschlagen haben. D.h. die drei Dateien werden viel größer. Aber das Strickmuster ist dasselbe. Zuerst kann man immer einen Anfang mit den allerwichtigsten Dingen machen und die drei Dateien dann Schritt für Schritt erweitern und verbessern.
Das andere Extrem zu diesem Minimalmodell sind die drei Dateien B.CFG, DAT.BPI und D-1.BPR auf dem Programmverzeichnis, die für die Demo-Datenbank benutzt werden. Wenn Sie eine neue Datenbank entwerfen wollen, die zwischen diesen Extremen liegt: starten Sie das Hilfsprogramm PRONTO (news Nr.42, S.6-7; Handbuch Kap.1.1.2). Es legt Ihnen eine Reihe von Fragen vor, und am Ende baut es die drei bewußten Dateien für Sie zusammen. Das ist dann der Rohbau, den Sie weiter ausgestalten können. (Genaue Anleitung in der Datei PRONTO.TXT auf C:\ALLEGRO)
Wenn wir aber schon Daten aus einer anderen Anwendung haben, und diese in unsere neue allegro-Datenbank überführen wollen? Auch dafür gibt es ein Minimalmodell. Sie müssen nur zwei Dinge tun:
import -f5 -kb -drohdaten.txt -ikat -ei-1/roh.blg -m0
-v0 -s0
|
Datei ROH.BLG entsteht |
update -fm01 -kb -d testbank -u roh.blg -n1
|
Datei ROH.BLG wird eingespeist |
Das Programm IMPORT braucht hier die Datei KAT.BIM. Sie enthält die Beschreibung (geschrieben in der "Importsprache", siehe Kap. 5 und 11), was mit den Fremddaten zu machen ist. Viel steht da nicht drin:
ASCII-Datei mit Kategorienummern einlesen
KAT.BIM Anwendbar für alle Kategoriesysteme! 970630
(Kopie von KAT.AIM)
re=13 10 13 10 Satzende: 2x Zeilenumbruch 13 10 13 10 (das
fe=13 10 Feldende: 1x Zeilenumbruch (beides evtl. ändern)
_ 13 10 " " ersetze den Zeilenumbruch innerhalb von Feldern
_ " " durch ein Leerzeichen T )
Damit das umwandeln (das Programm IMPORT) aber klappt, muß unsere Rohdatei schon eine bestimmte Form haben:
13 10 13
10) zwischen zwei Datensätzen,
13 10 am Zeilenende und 4 Blanks am Anfang der
nächsten Zeile. Zeilenlänge: beliebig.
Beispiel: Hier sehen Sie eine kleine Datei (ROHDATEN.TXT) mit drei Datensätzen, jeder hat nur eine Kategorie. In Wirklichkeit ist eine Datei kein bedrucktes Blatt Papier, sondern eine lange Zeichenkette. Die Zeilen sind durch die Codes 13 10 begrenzt; beim Betrachten im Texteditor sieht man die nicht, man sieht nur, daß eine neue Zeile anfängt.
#20 Der Name der Rose13 10 1.Datensatz
13 10
#20 Die Entwicklung von Gedächtnis- und Metagedächtnisleistungen13 10 2.Datensatz
in Abhängigkeit von bereichsspezifischen Vorkenntnissen13 10
13 10
#20 Wir amüsieren uns zu Tode 3.Datensatz
Die CD-ROM erfüllt mehrere Zwecke:
Während Funktion 3 auf jedem Windows-PC mit CD-Laufwerk ohne
Umstände (d.h. ohne Installation von Software auf dem PC) sofort
genutzt werden kann, ist für 1. und 2. eine Schlüsselzahl
notwendig, die jeder 97er Anwender individuell mitgeteilt bekommt.
allegro ist keine Freeware, deshalb geht es nicht
ohne jeden Kopierschutz. Wer die CD weitergibt, muß auch die
Schlüsselzahl mitgeben, und anhand dieser läßt sich
feststellen, wer der freizügige Weitergeber war. Wer den Katalog
der UB Braunschweig als Fremddatenquelle nutzen will
(vorausgesetzt, man arbeitet mit dem konsolidierten Format), braucht nur
dieses zu tun: wenn das CD-Laufwerk z.B. E: ist, ergänzt man in der
eigenen CP.OPT die Zeile d e:\katalog\kat, oder
erweitert PRESTO-Aufrufe durch die Option
-de:\katalog\kat.
Wer Windows'95 hat, braucht die CD nur einzulegen und einen Moment zu warten, dann erscheint ein Auswahlmenü, mit dem sich die wichtigsten Programme (1. bis 3.) direkt von der CD starten lassen. Falls die AUTORUN-Option Ihres CD-Laufwerks deaktiviert ist, müssen Sie das Programm AUTORUN32 manuell starten. Unter Windows 3.1 muß man das gleichwertige Programm START16 aufrufen. Beide Programme liegen im Wurzelverzeichnis der CD. Ganz ohne Windows kann man nicht von der CD installieren. In diesem Fall kann man jedoch auf einem Windows-Rechner die Installationsdisketten herstellen (siehe 2.) und diese dann auf jedem Nicht- Windows-PC benutzen.
| S. 49 |
Vergessen wurde die Erwähnung der Option
-M für APAC: wird sie gesetzt,
erscheint nach dem ersten Tastendruck erst einmal das
Esc-Menü, wird sie nicht gesetzt, kommt das
Menü nur dann, wenn [Esc] gedrückt
wird. Das bezieht sich nur auf die Situation gleich nach
dem Start, wo vorher immer sofort das Menü kam. Das
jedoch hatten einige wieder nicht gewollt. Auch vergessen:
wenn man APAC mit zwei Datenbanken startet, muß man
-a01 geben, sonst kann man nicht mit
[Alt+a] umschalten auf die zweite Datenbank.
Die Einstellung -a00 ist sinnvoll, wenn aus
dieser nur nachgeladen werden, der Benutzer aber keinen
Einblick nehmen soll.
|
| S. 156 | Mit dem Befehl log2alg katalog a:cat erhält man nichts Brauchbares. Man muß auf das Datenverzeichnis wechseln, dort log2alg cat geben, dann entsteht cat.alg, die man sich auf eine Diskette kopieren kann. Anders geht's zur Zeit nicht. |
| S. 333 |
Der Code für den diakritischen Unterstrich ist nicht
233, sondern 223.
Neue Codes im OSTWEST.FON: 215 für das große dänische Ø und 221 für das (leider noch nicht druckbare) Euro-Währungssymbol (vorher standen dort die Zeichen ® bzw. (ungleich), die unseres Wissens niemand brauchte. |
Die Eintragung in diese Liste geht so: Sie senden nichts als
die Meldung subscribe allegro an die Adresse
maiser@buch.biblio.etc.tu-bs.de.
Sie erfahren dann alles Weitere.
Abmelden: unsubscribe allegro senden, aber gleichfalls
an maiser@..., nicht an die Liste !
© 22.07.1997 UB Braunschweig, Bernhard Eversberg (b.eversberg@tu-bs.de)
Fragen bitte an:
ub@tu-bs.de