[Allegro] acon.exe 4.2.205 mit diagnostischem einschub: fehler

Di Feb 17 10:00:38 CET 2015

Guten Tag Herr Eversberg,
danke für Ihre Nachricht.
Am Montag, 16. Februar 2015 um 08:29 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

> ...
> ins $rec
> Wri $rec n
> var $rec
> ...
> B.E.
(re)kapitulierend: also ist es so richtig:
// naechsten Satz! aber Satz zuerst leeren mit "new"
:weiter
switch obj 1
new
fetch rec
// "diagnostischen Einschub" h.eversberg 16.2.2015
ins $rec
Wri $rec n
var $rec

das bringt ne endlosschleife, die so aussieht:
-1
J:<E111> -1 : fehlerhafte Eingabedaten

-1
J:<E111> -1 : fehlerhafte Eingabedaten
....

---> WIR sind noch immer im befehl, wo es um cat_1.ald geht! (s.u.)

WO fängt diese endlosschleife an?
das ist NICHT bei diesem versuch herauszufinden.... es fehlt ne 
pause....
die alg, die entsteht, hat als ende den letzten datensatz aus der 
entsprechenden ald.
achtund bitte: ich habe "fehlerergebnisse", die NICHT imm eindeutig 
sind: durch die manipulation in der srch.exe (original aus BS) ist 
obiges fehlerergebnis enstanden.
ohne die manipulation hatte ich entweder 20% verlust, oder 80% verlust 
in der alg. ODER ich hatte einen windowsfehler mit stillstehen des 
scriptes.
in EINEM fall hatte ich entdeckt: daß ein falscher zeilenanfang in der 
ald dafür verantwortlich war: ein tabzeichen (statt hex00 oder hex01).

nochmal: der aufruf lautet:
-P wird vorher definiert!
if exist c:\allegro\cat_1.ald c:\allegro\acon -j%-P%\srch.job -ka -dc:\allegro\cat\cat_1.ald -epa/c:\allegro\cat\1.alg -s-#9[ABDEFGR]
dann geht es weiter mit:
[diese nachfolgende pause ist NOICH gar NICHT erreicht!]
pause
if exist c:\allegro\cat_2.ald c:\allegro\acon -j%-P%\srch.job -ka -dc:\allegro\cat\cat_2.ald -epa/c:\allegro\cat\2.alg -s-#9[ABDEFGR]
usw. usw. usw.

pa ist pa.apr aus BS mit dem inhalt:
pn="allegro-Format"
    ver"ndert lediglich das verfassungsdatum in 11a... auf

   -------- Konstanten ----------------------------------------------------
                                          dieser Teil muss bleiben
zl=0        Zeilenl"nge unbegrenzt (kein Umbruch)
ks=1       Beginn des Ausgabetextes beim ersten Zeichen hinter #
ke=0        Kategorie-Ende = Code 0
as=h0       Aufnahme-Start: Hierarchiekennung + 0
                    Hauptaufnahme        : Code 01  als Startzeichen
                    Unteraufnahme Stufe 1:      02  ...
ae=13 10    Aufnahme-Ende: Carriage Return / Line Feed
   -------- Anweisungsteil --------------------------------------------------
  #dt p"11 zyx" e6

##          Pauschalexport : alle Kategorien hintereinander ausgeben
  /11

meine gedanken zum problem:
der vorgang mit srch findet das ende nicht!
die folge: eine endlosschleife.

das erklärt aber nicht die datenverluste, die ich vorzuweisen hatte. 
oder den windows-skriptabsturz. vielleicht ist es erst mal ein 
ansatzpunkt...

NOCH EIN hinweis:
"jage" ich das script über den fehlerhaften datenbestand, den ich oben 
erwähnte ["ein tab ist am anfang der datensatzzeile, statt hex00 oder 
hex01"], dann stürzt acon an EINEM datensatz DIREKT dahinter ab!
der betreffende datensatz endet mit 2x hex00 (statt 1x hex00). UND: ca 
30 datensätze später fängt einer mit tab statt mit hex00/hex01 an!
hilft das?

grüße vom k.lehmann

-- 
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
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: Bolero 64bit. Fußige Noten aufgeblättert (=Die Fußnotendoku)
* 2014: allegro-zdb: endlich. Die Wiedervereinigung! + eBooks
* 2015: allegro-vufind. Endlich! Noch moderner! Web2 auch für Ihren Katalog?

Am Montag, 16. Februar 2015 um 08:29 schrieben Sie:
> Am 12.02.2015 09:39, schrieb Klaus Lehmann:
>>
 >> T. Berger hatte geschrieben
>>
>>>>> Direkt unter "fetch rec" einfügen:
>>>>> Write kr
>>> Write kr
>>> hat daher konsequenterweise ein leeres Ergebnis. Und in acon hat
>>> "write" bzw. "Write" (anders als in a99?) den Nebeneffekt, die iV zu

> Und darauf K. Lehmann:

>> man beachte, in dem job hat man 3 schreibweisen von WRITE....
>> in der doku konnte ich keine unterschiede entdecken.

> Es steht drin: (h xwrite)

> Write  cstring        (großes W)    NUR avanti
>    Gibt auf dem Kanal  stderr  aus, statt in die Standardausgabe bzw.
>    Ausgabedatei.

> Und in der Einleitung der FLEX-Doku (h flex) steht:

> "Nur die Kurzformen sind "amtlich".
>   Alle Befehlswörter außer  erase  kann man bis auf die ersten drei
>   Buchstaben kürzen. Der Rest des Befehlswortes darf sogar anders
>   lauten, nur die ersten drei Zeichen sind signifikant. Z.B. ist
>   keychk  statt  keycheck  möglich, aber auch  key  klappt. Anders
>   gesagt: Nur die dreibuchstabigen Formen (sog. "Trigramme" oder
>   "Triliterale") sind die offiziellen Befehle, der Rest ist optional,
>   ist Konzession an Verständlichkeit und Lesbarkeit, wird vom Programm
>   aber ignoriert.
> "

> Was den von mir empfohlenen "diagnostischen Einschub" angeht, hat er
> damit nichts zu tun. Ich hatte die Sache nicht voll überblickt,
> sorry. Berger dagegen hat sich dann damit begnügt, meinen Denkfehler
> genüßlich aufzuspießen, aber keine konkrete Hilfe in Form einer besseren
> und funktionierenden Formulierung geboten.
> Statt nur "Wri" zu schreiben, wäre folgendes richtig:

> ...
> ins $rec
> Wri $rec n
> var $rec
> ...

> B.E.

> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro