[Allegro] Vb.258 Vorabdruck. "set a" in FLEX / Offline-Sp. abschalten?

Mo Mär 17 09:48:07 CET 2014

Wir haben mal schnell zusammengefaßt, was die V34.1 bringen soll und was
programmtechnisch auch schon realisiert ist.
Vielleicht fällt dem einen oder der anderen noch was auf, was uns
entgangen ist. Obwohl wir hoffen, daß keine groben Denk- oder Schreib-
fehler mehr drin sind, kann es doch sein, daß wir den einen oder
anderen Aspekt noch übersehen oder falsch eingeschätzt haben.
Ob die Version diese Woche noch kommen kann, steht deshalb dahin, auch
weil noch Testreihen nötig sind.

***********************************************************************
Vorabdruck!

Verlautbarung 258 der Entw.Abt.                              2014-03-??
-------------------------------

a99 Index-Marginalia
--------------------
Es konnte passieren, und zwar beim Umschalten auf ein Register einer
anderen Indexdatei (z.B. cat.aex) sofort nach dem Start, ohne zuerst
ein "normales" Register (in cat.adx) aufzublaettern, dass es zu einer
Endlosschleife kam und a99 nur ueber den Task-Manager noch zu
beseitigen war. Das konnte behoben werden.

Ferner war aufgefallen, dass beim Bewegen des Balkens zeilenweise nach
unten mit der Cursortaste am Ende der Seite das Weiterschalten nicht
funktionierte - es kam dann immer dieselbe Zeile. Dies zwar nur in den
symbolischen Registern (mit Praefix), aber gleichwohl war's untragbar
und wurde behoben.

FLEX avanti: first r, next r, ...  jetzt auch in acon
-----------------------------------------------------
Diese in a99 schon lange existierenden Befehle gibt es nun auch in
acon. Damit bewegt man sich in einer Ergebnismenge zu einem anderen
Datensatz, ohne dass dieser selbst geladen wird. Statt dessen wird
nur die Kurzzeile aus der STL in die iV geholt und die Satznummern-
variable i (aber nicht die interne Satznummer des aktuellen Satzes!)
auf die Nummer des zugehoerigen Satzes gesetzt. Nutzbar ist dies, wenn
man z.B. fuer einen Webkatalog eine Erg.Menge nur mittels der
Kurzzeilen praesentieren will - dazu braucht man nicht jeden einzelnen
Satz in einer Schleife zu laden und abzuarbeiten.
Ausgenutzt wird das im a35-Job  a35erg.job, falls dieser die Parameter
a35erg.Xpr nicht findet. Er nutzt dann die neutralen (fuer jede CFG
funktionierenden) Parameter  a35ers. at pr.
Dies erleichtert den Einstieg in a35, weil man nicht zuerst eine eigene
Parameterdatei a35erg.Xpr machen muss, sondern man bekommt auch ohne
diese sofort eine brauchbare Ergebnis-Kurzliste. (Empfohlen wird
natürlich, fuer eine aussagekraeftigere Kurzliste eine a35erg.Xpr
zu erstellen, doch erfordert dies Exportkenntnisse.)

Exportparameter:  i4   (siehe Handbuch Kap. 10.2.6.8)
--------------------
Nur wichtig, wenn die Datenbank mit V14-Technik arbeitet, also mit
Normdatensaetzen fuer Namen, Schlagwoerter etc.
Den Wert i4 kann man in den Exportparametern auf einen der Werte
1 bis 5 setzen, um unterschiedliche Arten der Ersetzung von IdNummern
einzuschalten (sog. V14-Ersetzungstechnik).
Insbes. muss der Wert in den Indexparametern gesetzt werden, damit
statt der Nummern die Namen bzw. Schlagwoerter etc. im Klartext im
Index erscheinen. Der sinnvolle Wert ist dann  i4=1.
Bei einem Export dagegen kann es noetig sein, eine andere Art der
Ersetzung vorzunehmen oder aber keine - um die Nummern als solche
erscheinen zu lassen und sonst nichts. Um das letztere zu erreichen,
setzt man i4 in den betr. Parametern NICHT ein. Nur dann macht das
Programm *keine* Ersetzung. Intern hat i4 dabei den Wert -1. Das war
bisher allenfalls intimen Kennern der Quellprogramme bekannt.
Ein Problem entstand, als die Moeglichkeit geschaffen wurde, mit
#bi4=n   (n=1...5)    siehe 10.2.6.8
innerhalb einer Parameterdatei den Wert zu veraendern. Hier kann
der Wunsch aufkommen, die Ersetzungen auch mal abschalten zu koennen,
waehrend der Laufzeit eines Exportes.
Kann das jedoch, so wird man fragen, ueberhaupt eine Wirkung haben?
Denn das Programm arbeitet so: Es fuehrt die V14-Ersetzungen und die
globalen Ersetzungen (falls vorhanden) aus, bevor es beginnt, die Daten
auszugeben, also bevor es zum ersten Ausgabebefehl schreitet (d.h. zur
ersten Zeile, die mit # oder ! beginnt). Zu dem Zeitpunkt sind also
die Ersetzungen gelaufen und sind auch nicht waehrend der Bearbeitung
des aktuellen Satzes in fliegendem Wechsel wieder rueckgängig zu
machen oder auf eine andere Art zu aendern. Es ist, klarer gesagt,
von daher unmoeglich, einfach mittendrin  #bi4=-1  zu sagen und dann
zu erwarten, dass ab der naechsten Zeile keine Ersetzung mehr
stattfindet - denn die Ersetzungen sind alle schon erledigt, basta.
Aber auch  #bi4=1  bewirkt nichts, wenn vorher kein i4 gesetzt war.
Denn der gesetzte Wert wirkt sich erst dann aus, wenn der *naechste*
Satz exportiert werden soll, d.h. bevor's dann neu von vorn losgeht
mit der Abarbeitung der Parameter fuer den naechsten Satz.
Noch anders gesagt: Alle Befehlszeilen des Exports finden die Daten
des Satzes bereits im ersetzten Zustand vor, sie werden nicht einzeln,
feldweise, waehrend des Exports der Ersetzung unterworfen.
Es wurde dennoch jetzt die Moeglichkeit geschaffen,  #bi4=-1  zu
schreiben. Aus wirkt sich das dann eben nur ab dem naechsten Satz, denn
fuer den aktuellen ist in dem Moment die Ersetzerei schon getan! Es sei
denn - Export-Experten ahnen es - man macht eine Nachladung, d.h. man
holt eben diesen Satz nochmals frisch in den Arbeitsspeicher, dann
liegt ab der naechsten Parameterzeile der Satz wieder unveraendert vor.
Wirklich? Nein, tut er nicht, direkt nach dem Nachladen erfolgt ganz
automatisch die V14-Ersetzung mit dem eingestellten Modus i4. Also:
vor dem Nachladen des Satzes i4 umstellen! Und hier kommt NEU hinzu der
Befehl  i4=-1,  um V14 unwirksam zu machen.
Braucht man hernach wieder ein Datenfeld mit vollzogener Ersetzung:
rueckschalten mit  #<  und bei Bedarf mit  #<^ wieder den unbehandelten
Satz einschalten. Im Prinzip nicht wirklich kompliziert also. Fuer den
Experten! Der weiss, dass ein nachgeladener Satz den eingestellten
Ersetzungen unterzogen wird, bevor die naechste Exportzeile ausgefuehrt
wird.

Mit FLEX hat man nun deutlich leichteres Spiel, da ist der fliegende
Wechsel gar kein Problem! Denn da gibt es die Moeglichkeit, den
aktuellen Satz VOR dem Export mit
copy obj 1 2  in das Objekt 2 zu kopieren. Da liegt er dann und ändert
sich nicht, egal was mit dem Objekt 1 angestellt wird.
Mit  copy obj 2 1  holt man ihn zurueck ins Objekt 1, falls man darin
was veraendert hatte - und hat ihn wieder im Originalzustand vor sich.
Eine FLEXsequenz kann demnach so aussehen:

copy obj 1 2
... irgendwelche Aenderungen am Satz
export
copy obj 2 1   // Originalsatz wieder hervorholen
... irgendwelche Aktionen mit dem unveraenderten Satz,
..  z.B. write- oder export-Befehle
copy obj 2 1   // das Original nochmals hervorholen
...

Aber in den Parametern, das ist ganz wichtig, *keinen* Befehl i4=...
(Der Wert in den Indexparametern war und ist in den Exportparametern
ohne Wirkung!) Aber wie kriegt man die Ersetzungen hin?
Nun, die V14-Ersetzungen macht man explizit im FLEX, das gehoert dann
zu "irgendwelche Aenderungen", und zwar mit dem Befehl

set a1    // um die Ersetzungen im Modus 1 *auszufuehren*
           // (nicht, um den Wert i4 in den Parametern zu *setzen*)
Dies geht nun auch in a99, wo man bislang nur mit  export R  die
Ersetzungen im i4-Modus 1 vornehmen konnte. Dieses sehr alte Konstrukt
war wenig gluecklich, bleibt aber bestehen (Bestandswahrung).

Aber aufgepasst: Wenn man nach einem  set aN  ein put folgen laesst!
Dann waeren im gespeicherten Satz die IdNummern alle weg und durch die
Klartexte ersetzt. a99 und acon verhindern dann das Speichern.
Uebrigens: Beim Export ist nichts zu befuerchten, denn nach dem Export
eines Satzes mit Befehl "export" sind die IdNummern wieder da. Das ist
eine eingebaute Automatik, die schon in PRESTO gegeben war.
Grundregel also: "set aN" erst *nach* einem put-Befehl, falls man z.B.
in einem FLEX gewisse Aenderungen an Datensaetzen machen will, damit
kombiniert aber auch irgendwelchen Output mit spezifischen V14-
Ersetzungen, ohne dabei mit Exportparametern zu arbeiten. Es ist also
nebenbei erreicht worden, die Notwendigkeit der kryptischen Export-
sprache weiter zu reduzieren.

Offline-Speicher abschalten?
----------------------------
Es ist die Meinung geaeussert worden, der Offline-Speicher sei eher
problematisch denn hilfreich. Als Desiderat wurde darob dessen
Abschaltbarkeit vorgeschlagen. Die Machbarkeit wurde geprueft. Das
Ergebnis ist negativ. Eine gaenzliche Abschaffung waere leichter,
kommt jedoch nicht in Betracht, weil es auch Anwender gibt, die
keinesfalls darauf verzichten wollen und die eine Entmuendigung
darin saehen, auf eine lineare Arbeitsweise mit striktem "eins nach
dem andern" festgelegt zu werden.
Es gibt Betreuer, die den Offline-Speicher als grossen Unsicherheits-
faktor sehen und sich damit behelfen, in ihren FLEXen an allen nur
denkbaren Stellen den Befehl "erase off" einsetzen. Das ist von der
Sache her unproblematisch (sonst haetten wir den Befehl besser nicht
schaffen sollen), praktisch aber doch aufwendig.
Wir haben hier aber im Grunde den alten Konflikt zwischen Freiheit und
Verantwortung aufseiten des Anwenders, und zwischen Gaengelung und
Vertrauen auf den Verstandesgebrauch aufseiten des Betreuers, der
seinen Anwendern nichts Nuetzliches vorenthalten moechte.
Was wir nun probehalber, fuer die Wagehaelse unter den Betreuern und
Anwendern, einfach mal eingebaut haben, ist folgendes:

set k1     (das bedeutet: komplette Unterbindung der Offlinefunktion)

Damit wird das Speichern von Saetzen in den Offline-Speicher komplett
verhindert. Mit

set k0     (0 ist natuerlich Default)

schaltet man es wieder ein.
Man bedenke jedoch: Das schlichte Nebenbei-waehrend-des-Editierens-
eines-Satzes-schnell-mal-eben-im-Index-nachschauen-und-den-einen-
oder-anderen-Satz-betrachten,-um-daraus-vielleicht-was-zu-kopieren,
das hat dann zur Folge, dass der gerade bearbeitete Satz wieder weg
ist, die bereits erfolgten Aenderungen spurlos beseitigt. Und diese
Moeglichkeit des Zwischendurch-schnell-mal-eben-nachschauens, die
laesst sich technisch *nicht* unterbinden - und wer wollte das auch
wirklich fordern!?
Aber gut, wer will, der kann es *auch* als Entmuendigung empfinden,
die Moeglichkeit des Verzichts auf die Offline-Speicherung *nicht*
geboten zu bekommen. Zumal jetzt, in der Fastenzeit.
Sei's drum - der Einsatz von "set k1" ist eigener Verantwortung
anheimgegeben. Jeder bedenke fuer sich die moeglichen Folgen und
teste alle denkbaren Szenarien durch. Sinnvoll erscheint k1 innerhalb
von FLEXen, in denen z.B. Hilfsdatensaetze erzeugt und sofort
gespeichert werden, die im Offline-Speicher den Nutzer irritieren
koennten, ohne ihm was zu bringen.
"Warum nicht umgekehrt?" wird womoeglich jetzt gefragt, d.h. Offline-
Speicherung NUR durch explizite Einschaltung. Erstens, weil das die
Kontinuitaet braeche, aber zweitens, weil die europaeische Aufklaerung
schon 300 Jahre waehrt und wir deshalb auf keinen Fall eine Einstellung
zum Default machen koennen, die den eigenstaendigen  Verstandesgebrauch
aufseiten des Nutzers als hoheitlich zu gewaehrenden Ausnahmefall
erscheinen laesst. Von daher ist es wohl nicht zuviel verlangt vom
Betreuer, den Befehl "set k1" in den _start.flx  zu setzen, wenn er
denn nach gewissenhafter Abwaegung zu der Ansicht gelangt, dies
vertreten zu koennen. Ohne natuerlich seine Pflicht zu versaeumen, die
Nutzer ueber diese Beschneidung ihrer Moeglichkeiten aufzuklaeren, sie
zum Mitdenken zu ermutigen, ihr Verstaendnis der Dinge zu foerdern
sowie eine Funktion bereitzustellen, mit der sie den Befehl "set k0"
ausloesen koennen.