[Allegro] Zum Thema "Füllzeichen"
Anando Eger
a.eger at aneg-dv.de
Fr Sep 2 14:42:13 CEST 2022
Hab' den zweiten Fall vergessen:
Wenn mit b"#utr" der Inhalt der Variablen #utr gemeint ist, gibt's die unten beschriebenen,
schwer eingrenzbaren Fehler, wenn die Variable leer ist.
Viele Grüße
Anando Eger
Am 2 Sep 2022 um 14:28 hat Anando Eger geschrieben:
Hallo Herr Lehmann,
> #ux1 +ó y0 dx1 b"#utr" =x1 e0
Ich weiß nicht genau, wann die Sonderbehandlung in ""-Zeichenketten für <,>,# usw.
eingeführt wurde - jedenfalls lange vor V31.10. (ab 28.3??)
Ausnahmen: Statt (b"<") muß man (b"[<]") schreiben, entspr. für die Zeichen >, # und ~.
Auch das aktuelle Allegro verträgt es nicht, wenn es in Systemen mit
"Ausführungsverhinderung" läuft (Code-Abarbeitung in Datenbereichen verhindert):
Die einfachen Sache funktionieren, bei komplexeren Flex-Scripten gibt's Abstürze in
Abhängigkeit von vorher erfolgten Aktionen (set obj ist kritisch) oder Datenbewegungen
(lange Zeichenketten).
Diese Art Fehler sind typisch nicht reproduzierbar und nach meinen Beobachtungen
abhängig u.a. von den Latenzen beim Datenbank-Dateizugriff.
Ein Einfügen einer Test-Meldung kann z.B. einen Fehler unsichjtbar werden lassen, den man
schon eingegrenz zun haben glaubt.
Die gute Nachricht: Auf einem Standard-PC, auch Windows 11, mit einem "normalen"
Server (keine Virtualisierung oder per SAN angebundenen Festplatten) und ohne von der
Systemadministration verbogenen Windows-Einstellungen (Sicherheit;-) funktioniert alles
weitestgehend störungsfrei.
Viele Grüße
Anando Eger
Am 1 Sep 2022 um 22:26 hat Klaus Lehmann geschrieben:
>
> Guten Abend Herr Eger,
> danke für Ihre Nachricht.
> Am Donnerstag, 1. September 2022 um 21:19 schrieben Sie.
> Ihre Nachricht finden Sie am Ende dieser eMail.
>
> > Hallo Herr Lehmann,
> >> > Das ist auch einer der Gründe, weshalb ich die neueren Allegro-Kernsysteme (>
V31.10
> >> > Dezember) bei meinen Kunden nicht einsetze.
> >> das ist natürlich eine böse entscheidung.
> ~~~~~~~~~~~~~~~~~
> ja,.... das war ein zu(?) schneller satz von mir.
>
>
> nur mal so nebenbei geplaudert:
> aber: ich hatte neulich ein problem bei meiner aktuellen version von allegro-cjk. (utf8, mit
china,japan und korea)
> eine bibliothek lief sehr zufriedenstellend mit einem ca 8-12 jahren alten allegro von mir.
> das könnte in ihre "bedingung" mit (> V31.10 > Dezember) reinpassen.
> dann: es gab zusammenbrüche, es gab datenverluste.
>
> ursache: sie migrierten von 32bit-w7 auf 64bit-w10.
> [achtung: die migration fand erst 2022/02 statt! sic!]
>
>
> die erste erkenntnis:
> das alte allegro machte unter den neuen bedingungen nicht mehr mit.
> hätte die bibliothek win7-32bit weiter gehabt, wäre es nicht zur zweiten erkenntnis
gekommen:
>
>
> die zweite erkenntnis:
> diese zeile aus einer api, die ich (mit h.allers vor 12 jahren) entwickelt habe, hatte eine
eingebaute sprengfalle:
>#99W $$ha/28.8.2010
>#-ó $$ha/28.8.2010
> !ux1 { 8 "|3" } P{"*"} $$ha/28.8.2010+6.12.2010
> #ux1 y0 dx2 e"#utr" f" " F" " =x2 e0 $$ha/28.8.2010
> !ux2 { 8 "|3" } P{"*"} $$ha/28.8.2010+6.12.2010
> #ux1 +ó y0 dx1 b"#utr" =x1 e0 $$ha/28.8.2010
> ~~~~~~~~~~~~~~~~~~~ wenn diese zeile aktiv ist, knallt es! (indexvorgang2 bricht ab!
2022/2)
> #utr dtr dx1 dx2 e0 $$ha/28.8.2010
>#+# $$ha/28.8.2010
>
> aktiviert man die zeile, die bis 2022/2 gültig, wars das.
> niente. meister kaputtnick hatte die herrschaft übernommen. ich hatte monatelang nach
dem fehler gesucht...
>
>
>
> > Ja, manchmal bin ich böse ;-)
> > Man versucht halt Stabilität/Aufwand zu maximieren.
>
> > Viele Grüße
> > Anando Eger
> > Erfolg ersetzt alle Argumente.
> na klar. voll einzusehen.
>
>
> aber: ich habe bei wolfgang grein (kennt ihn noch jemand?[er war mein mentor]) erlebt,
was das (sein!) beharren auf eine search.exe (16bit) für schlimme auswirkungen hatte.
> er war einfach zu "faul" (wolfgang vergebe mir!), seinen code so anzupassen, daß es mit
moderneren search.exe zusammenarbeiten würdee. und wir wissen alle, was mit 16bit
passierte.
> keiner kann es sich heute leisten, ein win10-32bit zur verfügung zu haben. es muss 64bit
sein!
>
> deshalb ist bei mir die maxime: auf 16bit hört keiner mehr.
> die basis ist 32bit. 64bit-module werden angeboten (ist bei allegro leider kein thema, noch
nicht. wann?)
> ich gehe davon aus, daß allegro-32bit für die nächsten 5-10 jahre arbeiten wird.
>
>
> grüße, ihr klaus lehmann
>
> ps: ich hätte sehr gerne ein 64bit allegro.
>
> um die 2GB-grenze bei adx und stl-dateien zu akzeptieren, muss ich bei sehr(!) großen
datenbank gewaltige klimmzüge machen. noch schaffe ich sie.
>
> hier ein kleiner einblick:
>imd.adx |1365475328|13.11.2020| 18:1816:42
>imd.aex | 311517184|13.11.2020| 18:1816:42
>imd.afx | 455438336|02.12.2020| 13:0411:58
>imd.agx | 100964352|02.12.2020| 13:0411:58
>imd.ahx | 34242560|02.12.2020| 13:0414:42
>imd.aix | 2531328|02.12.2020| 13:0415:30
>imd.ajx | 340926464|09.11.2020| 14:4223:25
>imd.akx | 357294080|14.02.2021| 13:1323:25
>imd.alx | 113082368|09.11.2020| 14:4723:25
>imd.amx | 317595648|09.11.2020| 14:5010:22
>imd.anx | 110241792|09.11.2020| 14:5119:55
>imd.aox | 238284800|09.11.2020| 14:53
>
> würde ich die a?x-dateien nicht aufdröseln, würde ich auf eine größe 3,7GB bei der
adx-datei kommen. bei 2GB und eben 32bit-allegro ist aber derzeit schluss! ernsthaft!
> für die letzte fassung der imdb-allegro habe ich 9,0 GB an ald's.
> nagut, solche allegro-datenbank hat und braucht nicht jeder ;-)
>
> naja: ich könnte mir schon zwei anwendungsbereiche für bibliotheken vorstellen: die DNB
und ZDB als vufind-katalog! eben MIT marc-export.
> warum? weil sie offiziell von der (bescheuerten) DNB keine marc-export bekommen, und
ebensowenig von der (bescheuerten) ZDB bekommen. das war mal.
> wenn sie die datensätze offiziell ansehen, haben sie keine vorstellung vom echten
marc-code, aus dem die datensätze gebaut sind.
>
> tip: bei k10plus haben sie manchmal/öfter glück! was die ansicht betrifft. es ist eben
k10plus. und das ist nicht als positivum gemeint.
> meine neuen server werden irgendwann in der lage sein, komplett dnb und zdb abzubilden.
aber nicht zugänglich für die öffentlichkeit (auch nicht für "meine" bibliotheken!).
>
>
>
>--
> Mit freundlichen Grüßen,
> Ihr Klaus Lehmann
> http://allegronet.de * eMail: allegronet at t-online.de *
> phone: 03528-452 807(fax 809) * mobil: 0171-953 7843 *
> allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1 *
> zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden *
> zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760 *
> * Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
> * Internetkataloge &WebHosting für Allegro-C & Web 2.0 mit VuFind
> * 2011-22: Sponsor: Peter-Sodann-Bibliothek
> * 2013-14: Bolero 32bit.+allegro-zdb: endlich. + eBooks
> * 2015-16: allegro-imd. Die weltgrößte(?) Filmdatenbank
> * 2017-22: Exporte. Marc und Co. Marc ist sehr different
> * 2019-22: All for VuFind! The perfect export into marc21
> * 2020-22: kohanet.de. Alternativen zu allegro-C und allegronet.de
>
>
>
>
>_______________________________________________
> Allegro mailing list
>Allegro at biblio.tu-bs.de
>https://bibservices.biblio.etc.tu-bs.de/mailman/listinfo/allegro
>
> Um sich von dieser Liste abzumelden, klicken Sie hier:
mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe
>
> To unsubscribe from this list, click here:
mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20220902/0a31c4bb/attachment-0001.htm>
Mehr Informationen über die Mailingliste Allegro