[Allegro] Vb.321 : a35-Paket aktualisiert u.a.

[Bernhard Eversberg]

Verlautbarung 321 zur allegro-Entwicklung                    2020-05-20
-----------------------------------------

INHALT
I.   a35 aktualisiert
II.  allegro.exe
III. acon: srch.job / a35: a35srch.job und a35fts.job
IV.  Irritierende Fehlermeldung "Keine Löschung..."


I. a35 aktualisiert
-------------------
Das Paket ist wieder auf dem neuesten Stand
  http://www.allegro-b.de/download, Win: a35.zip  /  Linux: a35.gz 
Neu sind die Jobs  
  users.job : Zeigt die registrierten User mit ihren Berechtigungen
              (X users eingeben)
  a35edp.job   : Damit editiert man die Berechtigungen eines Users
Ein Text "newuser.txt" im a35-Ordner db beschreibt, was genau alles 
zu tun ist, um einen neuen User aufzunehmen.
Auch die Ordner 
    www\db\demou  und  allegro\db\datuni
für die Unicode-Demobank wurden aktualisiert.
Abgeschlossen ist das Thema "a35" damit noch nicht. Dazu werden auch,
wie immer, Vorschläge entgegengenommen.
(Unter Unicode klappt das Editieren der gegenläufigen Schriften noch
nicht (Hebräisch und Arabisch).)


II. allegro.exe
---------------
In Vb320 wurde behauptet, ein Programm allegro.exe gebe es gar nicht.
Das ist falsch und richtig:
FALSCH:  Es gibt sehr wohl eins. Es tut jedoch nichts anderes als 
         a99 zu starten. Das wurde nur deshalb so gemacht, damit der/die
         unvoreingenommene, rein intuitionsbasiert arbeitende Admin*in,
         mit allegro konfrontiert, nicht enttäuscht wird, wenn er/sie
         nur mal eben "allegro" eintippt oder allegro.exe im Explorer 
         doppelklickt, sofort die DemoBank zu sehen kriegt und nicht 
         eine verstörende Fehlermeldung. 
RICHTIG: allegro.exe ist kein wirkliches Programm,
         das selber mit einer allegro-Datenbank was anfangen könnte.


III. acon: srch.job / a35: a35srch.job und a35fts.job
-----------------------------------------------------
Der neue srch.job, interessant auch als Lehrbeispiel, wurde nochmals 
kritisch gesichtet und Zeile für Zeile überarbeitet mit dem Blick 
auf Korrektheit, Verständlichkeit, Übersichtlichkeit, und was 
sonst noch alles wichtig ist, nebst ausführlichem Kommentar.
Zur Klärung
Der srch.job ist gedacht zur Anwendung unter Windows und Linux, 
wenn srch.exe (bzw. srch64), welches etwas schneller ist, nicht 
zum Einsatz kommen kann, weil man z.B. eigene Befehle einbauen will,
die zugleich während der Suche bei jedem gefundenen Satz auszuführen 
wären. Dabei ist insbes. zu denken an Änderungen in Sätzen und deren 
sofortige Abspeicherung - was srch nicht kann. So etwas läßt sich 
einbauen in den klar markierten Abschnitt zwischen den Marken 
:BEGINN  und  :ENDE.

Hinweis:
Innerhalb von a35 kann man dagegen den funktional identischen Job
a35srch.job zum Einsatz bringen, der aus a35srch.htm aufgerufen wird.
Der Unterschied: a35fts.job nutzt srch(.exe) zum Suchen - so geht's 
am allerschnellsten, a35srch.job dagegen macht alles selber (es 
liest die .ald-Dateien sequentiell, das geht aber auch ganz schön 
schnell, wenn's keine riesige Db ist).
Jedoch kann man NICHT den einen gegen den anderen austauschen
also a35srch.job im Kommandofenster einsetzen bzw. srch.job
innerhalb a35 - beides klappt nicht.

Wie man mit acon den srch.job aufruft, das wurde schon in Vb320 erzählt.
Zum Thema "Reguläre Ausdrücke" wurde eine neue Doku erarbeitet. 
Die stellt alles, und nur das, was man wirklich braucht, glasklar 
mit Beispielen vor. Hier ist sie:
  http://www.allegro-b.de/db/a35ftsh.htm
 
Ein Instrument für Bibliotheks-Endnutzer ist die Volltextsuche,
das wird einleuchten, nicht. Sie ist zudem auch ein zusätzliches
Suchverfahren, das den Betreibern einer Datenbank helfen kann,
problematische Datensätze aufzufinden. Etwa solche mit typischen
Schreibfehlern oder sonstigen Mängeln, die nicht über die
Indexregister zu packen sind. Das sind insbes. auch Daten mit
längerer Vorgeschichte, in denen bestimmte Angaben noch gar nicht
vorhanden sind oder andersartig abgefertigt wurden. Also Daten aus
den dunklen Epochen vor der Heraufkunft von RDA - vor dem
Zeitalter der, wie man dereinst sagen wird, bibliothekarischen
Aufklärung im ausgehenden 20. Jh.


IV.  Irritierende Fehlermeldung "Keine Löschung, da verknüpft"
--------------------------------------------------------------
Diese irritierende Meldung kann kommen, wenn man einen Zeitschriften-
Datensatz löschen will. Sinnvoll ist das, wenn man ZAboM anwendet und
Bandsätze hat - die würden sonst in der Luft hängen, d.h. man wüßte
gar nicht, wozu sie denn gehören.
Will man aber den Satz dennoch löschen, oder geht die Meldung auch
dann nicht weg, wenn man alle Bandsätze löscht, dann hilft folgender
einfache Trick:  Feld #00 mit Entf-Taste wegnehmen und dann Alt+ö.
Dann greift die sog. "Löschkontrolle" nicht und das Löschen klappt.
Ähnlich ist es, wenn man Normsätze löschen will, die eine #2n, #4n
oder #6n haben. Dann dieses Feld mit [Entf] entfernen, und Alt+ö.
Ausgelöst wird das ganze Problem von dem Abschnitt  #--  in der
cat.api, wo die Löschkontrollschlüssel gebildet werden: Wenn einer
davon im Reg 10 vorkommt, wird nicht gelöscht.