[Allegro] kleines problem mit avanti -> fehlerabfangen mit acon(avanti) im skript: ein lösungsansatz!

Di Jul 5 21:38:07 CEST 2016

Guten Tag allseits interessierte...

Am Mittwoch, 18. Mai 2016 um 17:55 schrieb ich was zum thema :

abstürze von acon(avanti),
und fragte, wie man diese abfangen kann.
versprach auch, mich selber um einen lösungsansatz zu kümmern.

lange zeit gabs keine fehler mit dem update.job, aber jetzt endlich!
;-)

das war das thema:
> ODER
> 2. [das ist viel fataler! in "meinem" fall:]
> avanti logt alles. der "ZICK" kommt. der nächste "ZICK" kommt. durch
> die vielen(?) "beinahmeabstürzen" wird im avanti-log was
> mitgeschrieben.
> DIESE gilt es nun herauszubekommen. WAS/WELCHE genau sind die
> Schlüsselworte in der avanti-log, die auf einem Absturz hindeuten.
> [ich habe DERZEIT keine avanti-log, die solche fehler notiert hat...]
> also: WENN man diese worte weiss, kann man externen tools (perl,awk
> usw) rangehen, die nach einem absturz geschlossene avanti.log nach
> diesen worten abfragen, wenn sie gefunden werden, könnte man eine
> pause mit einigen echoes VORHER aktivieren.

> somit hätte man endlich KEIN avanti, was per skript fehlerhaft
> das jetzt WIEDER mal keiner denkt, icke will wat für lau:
> ich werde die lösung hier präsentieren, wenn ich entsprechende hinweise in
> der avanti.log habe, und diese auswerten zu vermag.

nehmen wir mal an, wir haben diese aufgabenstellung:

x:\allegro\acon -jx:\allegro\update.job -fm11 -dc:\cat\cat
-utu-was.alg -n150 -F0/0 -L -xprotokoll

ich denke, es gibt (mir bekannte) 3 zustände von acon(avanti):
wichtig: !alles in zusammenhang mit dem update.job!

a. acon(avanti) hat die aufgabe erledigt.
in der protokolldatei steht in den letzten drei-zehn zeilen sowas:
ENDE : 0000 Indexeintragungen ge"ndert
2 records processed
0 records replaced
0 records merged
0 records ignored
0 records deleted
2 records new

b. acon(avanti) ist "leise" abgestürzt: MIT rückkehr zum betriebssystem
es geht ohne probleme weiter (im skript). WICHTIG: es geht OHNE stop
weiter! keiner, weiss, ob acon(avanti) den job zuende gemacht hat!
bin ziemlich sicher, in -xprotokoll sieht es SO aus:
gesucht: >|9zdb2304161-4<
Satz #6956=1369461 gefunden: >|923041614<
[11:49:25] Satz 1369461 ersetzt (Datei 80, Offset 13898847 / 0, Laenge 736)
[11:49:25] Satz #6957 geladen:
ges [ABBRUCH]

c. acon(avanti) ist "laut" abgestürzt:: das betr.system meldet sich, gibt eine
fenster-meldung heraus, und wartet auf eine tastatureingabe.
hier ist es ziemlich klar. das skript kann nicht automatisch
weiterarbeiten, das betr.system weigert sich!
bin ziemlich sicher, in -xprotokoll sieht es SO aus:
gesucht: >|9zdb2304161-4<
Satz #6956=1369461 gefunden: >|923041614<
[11:49:25] Satz 1369461 ersetzt (Datei 80, Offset 13898847 / 0, Laenge 736)
[11:49:25] Satz #6957 geladen:
ges [ABBRUCH]

kleine aufgabe für jeden: heraus finden, wo -x die protokolldatei
abgelegt. bei mir war es x:\allegro...

so. weiter denken!
der schlimmste fall ist b.
hierzu kommt mein lösungsansatz!

der fall ist zwar auch schlimm, aber bei c. stoppt uns das
betriebssystem! da gibt es eine "natürliche" pause.

der fall a. ist ok.

nachstehende lösung kann man also für alle drei fälle anwenden:
x:\allegro\acon -jx:\allegro\update.job ... -x%UPRO%
rem ~~~~~~~~~~~~~~~~~~~~~~~ hier passiert es! 2016/06

eine x-beliebige "finder.exe" -find "ENDE : "
if errorlevel 1 goto weiter
echo.
echo x:\allegro\acon hat  mit x:\allegro\update.job einen fehler
echo produziert. man schaue in der datei x:\allegro\"UPRO" nach!
pause
pause
pause
rem evtl kann man sich hier einen notbehelf ausdenken, wie man das
skript oder befehl erneut startet

:weiter
rem die batch läuft sauber vorschriftsmässig weiter!
blabla.exe

alos: nochmal: ich bin SEHR froh, diese lösugn gefunden zuhaben.
nicht ist schlimmer, alswiewenn allegro nach einem fehler einfach
weitermacht, und wir werden nicht gewarnt

ich habe ca 2 volle tage nach DEM fehler gesucht, und ich den fall b.
erlebte, und nicht "gecheckt" habe, wo steckt der fehler genau?!
den fehler IN der datenbank durfte ich DANN erleben, als alles zu spät war....

zur finder.exe:
man benötigt eine "finder".exe, die doch recht große datei durchsuchen
kann. und errorlevel anbietet.
kann perl sowas?
kann das gnutool find sowas?
unter dos gibt es den (internen?) befehl find....
meine werkzeuge können das, sind aber nicht oppensurze.

ich hab das da oben schon mal in mein großes skript reingemacht, und
der erste testlauf hat gut geklappt.

viele grüße zum abend,
ihr klaus 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?
* 2016: allegro-imd.Die weltgrößte(?) Filmdatenbank nur für Filmbibliotheken
Lesen Sie auf http://portal.allegronet.de/allegrowerkstatt/allegro-windows die
Wahrheit zur Zukunft von allegro-C. Bilden Sie sich Ihre eigene Meinung! Lesen Sie!

Am Mittwoch, 18. Mai 2016 um 17:55 schrieben Sie:
> Guten Tag allerseits,

> im letzten jahr hatte ich schön öfters mein leid geklagt.
> avanti stürze ab, und ich könne nix dagegen tun. besser: das skript
> macht weiter, als ob nix geschehen sei. evtl auch so: als ob avanti
> keine errorlevel kenne.

> ich denke, ich habe einen (sehr) entfernten lösungsansatz....
> meien gedanken mal hier notiert: ....

> bedingung: wir haben eine logdatei
> das wäre der befehl: avanti update.job -L -F0/0 -xUPRO

> -L = es wird eine logdatei geführt
> -F = es wird SEHR fix gearbeitet
> -x = expliciter Name der logdatei

> [mit wäre: kein -L lieber und kein -x, dann wäre avanti mit dem job
> schneller fertig.... oder?]
> [aber wir wollen ja den fehlern auf die spur kommen, die beim updaten
> auf die datenbank lauern...]

> DAS gute an der logdatei:
> sie wird pro verarbeitete datenzeile geschrieben. also schreiben,
> sofort speichern. wenn da wer abstürzt, dann geht nicht alles den
> bach herunter. allerdings: NICHT immer wird sofort gespeichert!
> m.M. nach fehlen NIE mehr als die letzte 20 datenzeilen...

> DAS gute an (meinen?) vorkommenden fehlern:
> avanti macht nicht sofort "ZICK" und schliesst den laden, es macht
> öfters "ZACK". will sagen: es stürzt SEHR leise ab, und die script
> datei macht einfach BLÖDE weiter!

> (ich denke es jedenfalls so:]
> avanti notiert den ersten fehler der
> datenzeile IN die logdatei, dann kommt der zweite fehler. er wird
> ebenfalls notiert. irgendwann beim x-ten fehler macht avanti "ZICK",
> stürzt ab, UND ZWEI dinge können JETZT passieren:

> 1. das betriebssystem bemerkt die choose, bringt zwei fehlerfenster
> (s.a. die listenmail von mir heute dazu!)
> UND stoppt damit das system!
> (nebenbei gefragt: immer?)
> dann gibt es evtl fehlerhinweise durch das betr.system.
> ABER diese kann ich NICHT aus meinem skript abfangen.

> ODER
> 2. [das ist viel fataler! in "meinem" fall:]
> avanti logt alles. der "ZICK" kommt. der nächste "ZICK" kommt. durch
> die vielen(?) "beinahmeabstürzen" wird im avanti-log was
> mitgeschrieben.
> DIESE gilt es nun herauszubekommen. WAS/WELCHE genau sind die
> Schlüsselworte in der avanti-log, die auf einem Absturz hindeuten.
> [ich habe DERZEIT keine avanti-log, die solche fehler notiert hat...]
> also: WENN man diese worte weiss, kann man externen tools (perl,awk
> usw) rangehen, die nach einem absturz geschlossene avanti.log nach
> diesen worten abfragen, wenn sie gefunden werden, könnte man eine
> pause mit einigen echoes VORHER aktivieren.

> somit hätte man endlich KEIN avanti, was per skript fehlerhaft
> durchrast, und mann weiss nicht, wo man ist!

> CLARO?

> ich halte das für einen brauchbaren ansatz.

> nochmal: avanti rast und stürzt, ohne das man es merkt, ab. UND das
> skript macht weiter. das ist fatal. mit einem externen tool müsste man
> das abfangen können....

> das jetzt WIEDER mal keiner denkt, icke will wat für lau:
> ich werde die lösung hier präsentieren, wenn ich entsprechende hinweise in
> der avanti.log habe, und diese auswerten zu vermag.

> grüße von k.l.