abnormal program termination (alf und co)

[Klaus Lehmann]

Hi, fans,

einige merkwuerdigkeiten passieren mir mal wieder, und ich weiss mir keinen
 rat. a. experimentiere ich mit dem (nagel)neuen Clienten32 von Novell-Netware
 V2.5, er ist vor kurzem herausgekommen. und zweitens ist bei uns ALF im
 erprobungsstadium. da sind wir eifrig am basteln. ;-)


mir ist einiges aufgefallen:
es gibt einige programm_module, die (mir) probleme bereiten.
es scheint nicht an der modul_version zu liegen (okok, wir reden hier nur ab 
V14a!). einiges kann im zusammenhang mit der verwendeten Netzwerkshell:
Client32 (V2.5) zusammenhaengen, einiges nicht. 
es ist KEIN Muster zu erkennen.


vorfaelle:
1.
ploetzlich, ohne index/qrix ausgetauscht zu haben (wirklich?? ;-) schmiert
 index ab, wenn es zu qrix -automatisch- ueberleiten will.
LOESUNG ist: qrix moechte auf dem schreibgeschuetzten programm-laufwerk 
schreiben! also bekommt protoq veraenderungsrechte IM laufwerk p:.
die allegro-userdaten liegen auf m: (da gibts sowieso netware_maessig ALLE
rechte ;-) WIESO schreibt qrix seine protoq auf p:??? ploetzlich?
denn an den automatischen batchroutinen ist nix geaendert worden (wirklich? ;-)

hier mal ein beispiel fuer sone batsch:
rem log-files DšRFEN NICHT mehr gekillt werden, wenn alf eingesetzt wird
rem alf-batch killt NACH auswertung der log-files die kbg.log selbstst„ndig
rem 
del m:\frh\*.a1d
del m:\frh\frh.stl
index -Pp: -f70 -n0 -kAfrh -lger -d*M:\frh\frh -efrh/M:\frh -h0 -m0
flag m:\frh\*.* +s < C
caston
x


ok. die loesung bestand in den schreibrechten auf protoq, welches ploeztlich
auf p: liegen sollte! versteh ich nicht! jahrelang hat qrix sein zeugs
auf m: abgelagert, OHNE dass es dazu extra befehligt wurde.... hmmmmm...?!
der netware_client spielte uebrigens hier keine rolle!
die index-versionen auch nicht(???).



2. 
folgende update_routine (bei alf) spinnt.
hier spielt der client32 eine rolle!

update -fm41 -n1 -um:\temp\alfexp0.alg -dm:\alf\alf -h0 -m0 -kalfohne
     -L -N0 -lger (=eine zeile!)
update -fm41 -n230 -um:\temp\alfexp1.alg -dm:\alf\alf -h0 -m0 -kalfohne
     -L -N0 (=eine zeile)

wenn obiges update erreicht wird: => blackout! screen blau oder schwarz!
keine fehlermsg: nix. ctrl-alt-del geht nicht! nur noch reset! 
dieses passiert bei workstations, die den client32 geladen haben. 
es spielt uebrigens KEINE rolle ,ob V2.2 oder die neue V2.5!
warum? 
wenn ich auf derselben workstation den VLM-cliente nehme, passiert das
 selbe!. wenn ich auf eine ANDERE schwaechere workstation gehe, z.b. 486'er
(diese haben immer vlm!), passiert das nicht! update schnurrt durch. alles
primstens! ich sehe kein muster drinne!!!! warum????

die update-versionen spielen keine rolle(???).
andere update-routinen laufen! (auch mit dem client32 V2.5) hmmmm....




3. und ebenfalls etwas merkwuerdig, WEIL kein einheitliches fehlerbild:
folgende batchs:

presto -f1 -n1 -a3 -dm:\alf\alf -kalfohne -pd-alf

auf den workstations mit client32 (v2.5) blakcscreen! nix. keine error-msg.
zuhause gluecklicherweise (dank os2!) kann ich den screen abfangen:

Abnormal program termination
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

WER hat das ausgegeben???? die presto.exe oder command.com von os2????
ich tippe auf presto.exe.
je nach presto.version bekommt man obige error-msg oder auch keine!





---> zusammenfassende frage:
kann es sein, dass sich in den cfg's, oder apr's (evtl api's) FEHLERhafte
 spruenge oder aehnliches befinden???? die eben die allegro-module zum
 straucheln bringen????? ich bilde mir ein, sowas schon mal frueher(!)
gesehen zu haben. aber nix genaues weiss man. man ist ja immer froh, wenn
man einen(!) fehler geschafft hat, und hofft, sobald tauchen KEINE neuen
auf. nur wird man SEHR oft einttaeuscht! ;-)
(mit fehler meine ich eher die eigenen a'la parametrisierung. die probleme
liegen weniger bei den allegro_modulen (honich um den bard schmierend....;-)



tja. jungs und maedels...
wat laeuft heute?
dab? bit? oder nur clausthaler....


etwas ratlos.
vielleicht ist es JA etwas VOELLIG anderes....?     ;-)

vielleicht gibts ja den einen oder anderen, der ein aehnliches fehlerbild hat,
und sich nicht traut zu fragen ;-)  (ick traue mir!)
das da oben ist etwas chaotisch! zugegeben. letzten sommer hatten wir auch
3 monate netzprobleme, alles war nicht nachvollziehbar, bis wir auf den
 trichter kamen, dass wir abundzu nur VOLT200 in den server bekommen hatten,
 und einiges DABEI (still!) kaputtging. argh (DAS war ein heisser sommer!) 
 ;-)     nun ist alles heile!




achnochwas: ein letztes:
ALF.exe (letzte erhaeltliche version!)


WIE hoch ist der ram-bedarf???
540k?

ich habe einige probleme mit schwachbruestigen workstations (386'er)...
gibt es einsparungspotiential bei ALF? please, have a look at my cfg:

            * Speicherreservierung
mr256       * Ergebnismenge
  mr3000
mk256       * Kategorienanzahl
mb128       * Hintergrund Anzahl Kategorien
mB4096      * Hintergrund GrӇe BENUTZERVARIABLE
mP4096      * Phrasen und ZWISCHENTEILE und CODIERUNGSTABELLE
wenn ich das richtig sehe, ist da nuescht mehr rauszuholen. gelle?!





Viele Gruesse und herzlichsten DANK! (im voraus)
 Klaus
  Lehmann
   Sysop of Novell-Servers in Kreuzberg
--- timEd/2 1.10.y2k+
--
|Fidonet:  Klaus Lehmann 2:2411/801.502