[Allegro] kleine erkenntnisse ...

So Aug 23 19:00:06 CEST 2015

die  workstation  werkelt  vor  sich hin....
habe bei 5.000.000 updates die reissleine gezogen.

> ...
> nur mal einiges angemerkt.... ;-)
> update.job wird alsbald die 3 mill-marke erklimmern....
> 7 mill'ios liegen noch vor einem....
jetzt sind es noch 5 millio's. STOP!

warum?
der rechner muß mal...

...bebootet werden ;-)
das  cdrom-laufwedrk  ist  nicht  mehr ansprechbar, andere sachen sind
irgendwie komisch...

nach einem reboot wird weitergemacht. dank UPRO kann man genau erkennen, wo
war  er bereits? wo muss weitergemacht werden? das problem ist nur ein
editor,  der  der  alg-datei  "beine  macht",  ihr  5 millionen zeilen
wegnimmt. mit notepad++ gehts definitiv NICHT! aber mit .... ;-)

> interessant(?) ist, was der taskmanager sagt:
> hier  pendelt  ein  prozess  (acon.exe  *32)  von 753.00 bis 769.000 K
> hinundher.    soviel    beansprucht    dieser    process   an   RAM!

mittlerweile ist der ramverbrauch im taskmanager bei 1,5GB.
humpf. ist mir unheimlich! reissleine!

also:  ist  da  ein  speicherloch?  ein  "leak",  wo  acon "irgendwas"
mitschleift? die logdate etwa? sie sie liegt bei ca 1,3GB.
oder was speichert acon da?
neugierig....

> an hardware werkelt rum:
> eine workstation von lenovo, dem nachfolger von IBM:
> es  ist  eine  aufgebohrte  C20x  (mit  SAS-platten, einer SDD für den
> tmp(sic)-bereich,  sowie 48GB ram, weiteraufbohrbar wären es mit 192GB
> ram... [aber das kostet ca €1.000 mehr]
> und  derzeit  mache ich ein expirement mit einer RAMdisk mit der größe
> von 30GB. da erklimmt acon gerade die eiger-nordwand!

um nicht zu vergessen ;-)
> ps:   die  acon-fehler-liste  vom  kollegen  thomas  berger  fand  ich
> HOCHinteressant!  die  sollte  man  unbedingt "abarbeiten". sorry, ich
> nicht, da für bin ich zu dämlich ;-)

grüße von einem milden sonntag, ca 25 grad nur....
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?

Am Samstag, 22. August 2015 um 12:57 schrieben Sie:
>  
> Guten Tag Herr Eversberg,
> danke für Ihre Nachricht.
> Am Freitag, 21. August 2015 um 09:52 schrieben Sie.
> Ihre Nachricht finden Sie am Ende dieser eMail.

> ...
> nur mal einiges angemerkt.... ;-)

>> ... und in solcher Situation ist eine Exklamation wie "What the f---"
>> nicht unüblich und nachvollziehbar.
>> Es sind die Härtesten, lassen Sie mich dies Wort der Anerkennung hier
>> mal sagen, die solche Projekte anpacken und durchziehen, unerwarteten
>> Widrigkeiten zum Trotz, wie sie an der Eiger-Nordwand nicht zu selten
>> begegnen, dort gelegentlich aber fatal in anderem Sinne als hier...

> nachdem  ich  also  alle varianten von "--" (oder 3x- oder 4x- und mehr)
> ausgemerzt habe; besser: ersetzt habe, ergibt ein interessantens bild:

> [allerdings   läuft   hier  ein  "test-einspieler"  ohne  die  gestern
> versprochenen splitting's!]

> update.job wird alsbald die 3 mill-marke erklimmern....
> 7 mill'ios liegen noch vor einem....

> interessant(?) ist, was der taskmanager sagt:
> hier  pendelt  ein  prozess  (acon.exe  *32)  von 753.00 bis 769.000 K
> hinundher. soviel beansprucht dieser process an RAM! soso.

> an hardware werkelt rum:
> eine workstation von lenovo, dem nachfolger von IBM:
> es  ist  eine  aufgebohrte  C20x  (mit  SAS-platten, einer SDD für den
> tmp(sic)-bereich,  sowie 48GB ram, weiteraufbohrbar wären es mit 192GB
> ram... [aber das kostet ca €1.000 mehr]
> und  derzeit  mache ich ein expirement mit einer RAMdisk mit der größe
> von 30GB. da erklimmt acon gerade die eiger-nordwand!

> die UPRO-datei ist mittlerweile 912MB groß geworden.
> zur erinnerung: der acon-aufruf lautet: ....  -L -F0/0 -xUPRO%lst%
> ich habe eine  befürchtung,  was  ist,  wenn  UPRO  die  grenze(?) von 2GB
> ansteuert?

> insofern nachgefragt: kann man die UPRO eingrenzen? nur fehler anzeigen?

> unter:
> // Optionen:
> // Intern - Diese wertet  acon.exe  selber aus und stehen dann
> //          im Job als Sondervariable zur Verfügung: (d.h. $OP_b etc. unnoetig)
> // * -b  Datenbank --> var B  [wird bei Fehlen aus -d entnommen:]
> // * -d  Datenbankpfad\Datenbankname --> var D
> // * -P  Programmverzeichnis --> var P
> // * -k  Konfiguration --> var K und var K1
> // * -l  Language (default ger) --> var L
> // * -L  Logdatei --> var G
> // * -j  Jobdatei (Name dieser Skriptdatei) --> $OP_j
> //
> // Optionen: speziell fuer z.B. update.job:
> // Klassische. optsget.inc  wertet diese aus und macht aus -xabc  $OP_x abc
> // Notwendig sind nur zwei: -f und -u; bei -f gibt es 3 Varianten
> // * -fp    Funktion: Playback
> // * -fc    Funktion: Check (intern: $F.check belegt und $OP_f="c")
> // * -fmxy  Funktion: Merge
> // * -u     Updatedatei = Eingabedaten

> // Nicht alle folgenden stets notwendig: (im Verlauf als $OP_x verfuegbar)
> // * -e     Exportparameter ("/" | "=" | "+") Exportdatei (Logging, Glob. Manipulation)
> // * -F     Verzoegerung in Sekunden zwischen Speichervorgaengen, auch x/y, default -F1/1
> //          mit x, y Dezimalzahlen fuer Speicher- bzw. Nichtspeicher-Pause
> //              daraus wird $pause1 und $pause0
> // * -i     Name der Indexparameter, falls neue Datenbank zu erzeugen ist
> // * -I     Abweichende Indexparameterdatei
> // * -m     manuelle Unterbrechung (obsolet)
> // * -n     Dateinummer fuer Neusaetze, default 1
> // * -N     Modus (0/1/2) fuer Neusaetze
> // * -O     Bearbeiterkuerzel
> // * -R     Aufzeichnungsdatei fuer Konsolmeldungen (noch ungenutzt)
> // * -T     Test: Diagnostische Ausgabe
> // * -U     Vorbesetzung von Anwendervariablen #uxy (wiederholbar)
> // * -x     Protokolldateiname, default upro
> // * -y     Indexparameter (falls nicht default aus -b)
> // * -z     max. Datendateigroesse (falls nicht default lt. Faktor ii in Indexparam)
> // * -v     0|1  Gefundene Saetze anzeigen ja/nein (nur in srch.job)

> // * Ignoriert werden vorerst: -i, -m, -y, -z

> hier  finde  ich  nichts. un  je weniger geloggt wird, desto schneller
> wird der job! oder?

> wichtig:   die   logdatei   will   ich   NICHT  abschalten,  aber  der
> übersichtlichkeit  halber  würde  ich  gerne NUR die fehler sehen.....
> oder bei welchem datensatz eben acon "failt"....

> naja.... mühsam ernährt sich das eichhörnchen... ;-)

> viele grüße, ihr klaus lehmann

> ps:   die  acon-fehler-liste  vom  kollegen  thomas  berger  fand  ich
> HOCHinteressant!  die  sollte  man  unbedingt "abarbeiten". sorry, ich
> nicht, da für bin ich zu dämlich ;-)

>> Was aber tun? Der Steuercode "---" ist nicht, wie beim qrix-Befehl,
>> modifizierbar. Was der Entwickler nicht vorausahnte, ist das Auftreten
>> von "---" am Ende eines Primärschlüssels. Falls kein anderer Vorschlag
>> kommt, müssen wir uns da nochmal drüber 'n Kopf machen.

>> Der Vorschlag könnte kommen, doch den find-Befehl in update.job in
>> "f1nd" zu ändern, dann wird nur 1 Satz gefunden, und im fraglichen
>> Fall sollte es wohl nur einer sein.
>> Dies ist die Stelle:

>> var $pk1 ' "' $pk2 '"'
>> find

>> Das Problem dabei ist, daß dann mit dem nachfolgenden "if g1" nicht
>> mehr getestet werden kann, ob's mehr als einen Eintrag gibt zu
>> dem Primärschlüssel, denn die Größe der Erg.Menge ist dann 0. Abhilfe
>> wäre eine andere Art von Test an der Stelle. Vorschläge?

>> B.E.

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