[Allegro] a30 / Parallelen zwischen FLEX und JOB

[Bernhard Eversberg]

Am 07.02.2012 12:42, schrieb Thomas Berger:

Vorweg gleich dies als Fazit: Standardanwender sind von dem Thema
unbetroffen.


> ...
>> ... Da ist es effizienter, im Bedarfsfall so zu verfahren:
>>
>> var ...
>> ins #uiV
>> var ... #uiV ...
>>
>> weil dies den Normalfall (das Nichtvorkommen von iV als Variable) nicht belastet.
>
> und das 4MB-Problem dann wegen der deutlich kleineren Grenzen fuer
> Anwendervariable sowieso entfaellt...
> ...
Immerhin gibt's dabei keinen Absturz, und der Mißerfolg eines "ins" ist
mittels vorheriger Verkürzung,  var (0,1000) oder so, verhinderbar und
der Arbeits- sowie Hintergrundspeicher in der CFG konfigurierbar.

> Sonst sind Sie aber nicht so zimperlich, vgl. avjob.cpp (r18) l. 1377f:
>
> char iV[255];
>           strcpy(iV,inpu); // iV sichern!
> ...
> und die haeufigen "strcpy(tsk,inpu)" in avjob.cpp scheinen mir auch
> deutlich auf 64k-iV's begrenzt zu sein...
Da muß man genauer hinschauen, um was es sich jeweils handeln kann.

Erst einmal ein Hinweis zu einer Besonderheit der Sprache C:
Das Kopieren eines Strings geht nicht so vor sich, daß in jedem Fall
seine vordefinierte Länge kopiert wird, sondern kopiert wird nur bis
zum Code 0, der in C das Ende des Strings markiert. Der Code 0 selbst
kann folglich nicht im Innern einer Stringvariablen in C stehen.
(Aus diesem praktischen Grund steht der Code 0 auch in allegro-
Datenbank- und -Grunddateien am Feldende.)
Mehr, und allgemeineres, zu diesem Thema folgt weiter unten.

>
> Tja, wenn acon Anweisungszeilen vor der Ausfuehrung analysieren wuerde,
> wuesste es, ob eine Kopie der iV benoetigt wird. Auf Verdacht hin
> 2MB zu kopieren ist natuerlich unschoen, da haben Sie recht.
>
Zu dem Wort "tja" steht im Duden:
"Interjektion; drückt Nachdenklichkeit, Bedenken, eine zögernde
Haltung, auch Verlegenheit oder Resignation aus"
In Fällen wie diesem scheint auch noch ein Quentchen Schlaubergerei
mitzuschwingen. (Wir melden das mal nach Mannheim.)
Das "Analysieren vor der Ausführung" wäre ein unauslotbar weites Feld,
zumal wenn dabei die aktuellen Inhalte von Variablen mit einbezogen
werden sollten, was in diesem Fall ja geboten schiene, und verbietet
sich aus Effizienzgründen. Wer sich in einem Sumpf bewegt, prüft gern
vor jedem Schritt mit einer Stange, ob er diesen tun sollte, doch wie
schnell kommt er so voran? Auf halbwegs sicherem Terrain läßt er's 
deshalb bleiben. (Genau das ist es aber, nebenbei, was Java wirklich
andauernd macht und gar nicht anders kann, und warum es so lahm ist:
es gibt gar keine Variablen, nur Objekte! Selbst jede Ganzzahl ist ein
Objekt mit einem Rucksack voll Eigenschaften und Methoden, die meisten
davon eher selten nötig. Damit wälzt der Programmierer zwar ein paar
Probleme von sich ab, jedoch auf die Schultern des Endanwenders in
Gestalt von Effizienzminderung.)

> Sie haben allerdings den String ex, der nur geringfuegig kleiner als
> die iV ist, als allgemeines Scratchpad? Wenn Sie "inpu" nicht starr
> fuer die iV benutzen, sondern als Pointer auf abwechselnd einen von
> zwei gleich grossen Bereichen (aktuelles / naechstes), duerfte das
> viele Probleme loesen...
>
Theoretisch, in praxi aber äußerst wenige.

Wird mit langen Inhalten hantiert, ist generell Um- und Vorsicht
geboten. Bibliographische Datensätze, und allemal Katalogdatensätze,
sind in diesem Sinne kaum jemals "lang"; auch MARC und Pica haben
ihre bei 10.000 liegenden Grenzen der SATZlänge, nicht FELDlänge!

Was unsere Standard-FLEXe betrifft, haben wir bei dieser Gelegenheit
alle durchgecheckt (ca. 300) und 16 Fälle gefunden, in denen ein var-
Konstrukt vorkommt, das theoretisch in dem genannten Sinne kritisch
sein könnte. Keins davon ist real kritisch, will sagen, daß die
darin involvierten Inhalte ihrer Natur nach jemals in kritische
Größen gelangen könnten. Sie sind vielmehr allesamt mit Sicherheit
kurz oder sehr kurz. (Liste dieser FLEXe siehe unten)

FLEX als Skriptsprache hat, wie jede echte Programmiersprache auch,
ihre Tücken. Die ernsteren davon liegen real nicht in solchen Dingen,
sondern in der Gefahr der Schleifenbildung, die mit keinem Mittel und
in keiner Sprache verhütbar ist. In acon haben wir da immerhin einen
einstellbaren Zähler, der eine Endlosschleife irgendwann mit Fehler-
meldung abbricht. Ob z.B. Java sowas hat, weiß ich nicht, C jedenfalls
hat es nicht. C und C++ bergen ferner die sehr reale Gefahr der
Bereichsüberschreitung, die zwar vom Betriebssystem i.a.R. abgefangen
wird, aber leider nur mit einer hilflosen Absturzmeldung. So etwas kann
nur Vor- und Umsicht beim Programmieren abmildern. Wie bei FLEX.
Wie in jedem Programmiersystem muß man auch bei FLEX Aufwand und
Effekt mit Augenmaß ins Verhältnis setzen. Unverhältnismäßig wäre in
diesem Sinne, einen zusätzlichen Bereich von 4MB vorzuhalten, der nur
in äußerst wenigen, mit ein wenig Bedacht beim FLEXen vermeidbaren
Situationen ein Problem entschärfen würde. Bergers an sich natürlich
guter Vorschlag grenzt damit letztlich an unproduktive Betulichkeit.
Was uns nicht hindern soll, die reale Machbarkeit bei Gelegenheit noch
zu prüfen.

Hier die Namen der o.g. Standard-FLEXe:

A-MAHNEX.FLX
A-STATK.FLX
ARESQA1.FLX
ASKSOLR.FLX
AUSL.FLX
BEDIT.FLX
CFGB.FLX
O-MKVIEW.FLX
PARAM.FLX
SUMME.FLX
TABCONF.FLX
UVAR.FLX
WEWOTA.FLX
X-SUMME.FLX
Z-EXDAT.FLX
_START.FLX