[Allegro] Variablen-Lebensdauer / -gueltigketi beim Index-Lauf

[Thomas Berger]

Lieber Herr Eger,


> Naja, Auslöser der ganzen Diskussion war ja die Tatsache, dass bei
> mehreren Anwendern nach Umstieg auf die 32bit-Version der index.exe
> der Index-Neuaufbau nicht mehr funktionierte. Das waren zum größten
> Teil lange unverändert benutzte Datenbanken.
> 
> Die Ursachenforschung ergab, dass die Fehlfunktionen irgendwie mit 
> den verwendeten Variablen zusammenhingen.

also etwa analog den Fischer-Problemen.

Unterschiedliches Verhalten von index16 / index32 in unsauberen
Grenzfaellen kann nicht ausgeschlossen werden, generell ist aber
das prinzipielle Verhalten bzgl. - at 1 / - at 2 bei beiden Programmen
gleich und auch das alte 16bit-INDEX.EXE duerfte ziemlich (aber
evtl. anders) allergisch gegen massive Variablenueberlaeufe sein.

Wo aber auch Unterschiede liegen koennen, ist in der Heuristik,
mit der Cockpit (Routinen -> Organisieren) bzw. org.flx entscheiden,
dass eine zweistufige Indexierung faellig wird.

Oder aber es liegen andere Gruende vor, warum die "lange unveraendert
benutzte" Datenbank funktionierte, etwa weil sie in frueheren
Zeiten mit einer noch viel aelteren Routine immer nur einstufig indexiert
worden ist, oder weil sie damals so klein war, dass die Fehler
sich nicht so aufgeschaukelt haben.

Um es vorsichtiger auszudruecken: Ich kann mich bei index32.exe an
keine Migrationsprobleme (mehr) erinnern, eher noch an Altdatenbanken,
die sich damit dann wieder indexieren liessen (INDEX.EXE konnte
maximal 500 Schluessel pro Datensatz bilden, die letzten Versionen
allerdings 1000, bei index32.exe hingegen ist es "beliebig").
Allerdings habe ich das "Holpern" (16bit INDEX.EXE kann nicht
an QRIX weiterleiten) durch Arbeitsspeicherkorruption auch nie
hingenommen sondern immer fleissig nach eventuellen Ueberlaeufen
gesucht, die sich darin manifestiert haben.


> In einem Fall hat es genügt, die Verwendung der #uty und #utz
> durch direkte Tests und ZT zu ersetzen - und diese Variablen wurden
> immer nur durch =ty und =tz gesetzt - sollten also überhaupt nicht
> überlaufen können.

Phh. =ty etc. sind doch keine Zuweisungsbefehle!


> Vieleicht schlägt hier auch der alte =xx-Fehler zu.
> Ich habe in der Vergangenheit die Stabilität von Export-Parametern
> gegen "unmotivierte" Doppelausgaben alter Arbeitstext-Inhalte
> dadurch erhöhen können, dass ich konsequent 'dxx axx' statt '=xx'
> für einfache Zuweisungen verwendet habe.

Meine Rede. Bei "dxx ... axx" ist (geignetes ... vorausgesetzt)
sogar die Loeschung von #uxx realisierbar, ausserdem ist klar(?),
dass alle dahinter stehenden Manipulationsbefehle definitiv
ignoriert werden und dass ein ggfls. in der Anweisung vorhandener
bedingter Sprung von den Vorgaengen in dieser Zeile abhaengt.
Bei "=xx" hingegen ist keine Loeschung moeglich, und ob dahinter
stehende Manipulationsbefehle ausgefuehrt werden und bedingte
Spruenge stattfinden, erfordert im Einzelfall sehr genaue Analyse.

viele Gruesse
Thomas Berger