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

[Anando Eger]

Hallo Herr Berger,

Sie schrieben u.a.:

> Phh. =ty etc. sind doch keine Zuweisungsbefehle!

Natürlich nicht, jedoch wurde und wird in den mit Allegro-C
ausgelieferten Parametern, die für mich und auch die Anwender
immer so eine Art Referenz darstellen (sollten?), ausgiebig
von =xy-Konstruktionen ohne irgendeinen Sprung oder eine
Zwischenteilangabe Gebrauch gemacht.

Zeilen wie '#8n p"z" e1 =zz' wirken eben wie Zuweisungen.

Viele Grüße
Anando Eger

---------------------------------------------------------------------
Anando Eger Datenverarbeitung
Herr Dipl.-Ing. Anando Eger
Gustav-Voigt-Str. 24
01156 Dresden
Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
---------------------------------------------------------------------


On 7 Dec 2011 at 0:04, Thomas Berger wrote:

> 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
>