In Anwendungen, speziell bei der Halleschen, werden Datenzugriffe für denselben Schlüssel mehrfach, teilweise zig-fach ausgeführt. Dabei entstehen Performance-Probleme aufgrund der relativ langen Ausführungszeiten für SQL-Aufrufe.
Ziel ist es, dass Anwendungen sich bereits gelesene Ergebnisse merken, um wiederholte Lesezugriffe zu vermeiden.
Zur Zeit gehen Anwendungsmodule hin und speichern das letzte gelesene Ergebnis manuell in statischen Speicherbereichen. Dabei gibt es Probleme, da Anpassungen an Datenstrukturen und Längen nicht automatisch berücksichtigt werden.
Wunsch ist, dass Generator und Infrastruktur eine Technik zur Verfügung stellen, um Inhalte von lokalen Objekte für ein bestimmtes Modul für die Dauer einer Gevo-Instanz 1) aufzubewahren und bei Wiedereintritt in das Modul wieder verfügbar zu machen.
Zur Definition eines lokalen statischen Objekts wird die Syntax bei der Objektdeklaration erweitert um die Angabe STATIC:
Von einer Unterstützung in CTV-Modulen und Visual Basic wird zunächst abgesehen, um unnötigen Aufwand zu vermeiden, solange die AL die lokalen statischen Objekte nicht nutzt bzw. die Hallesche keine CTV-Module erstellt. Beides wäre aber kurzfristig realisierbar, nachdem die Grundlage in der Infrastruktur geschaffen wurde.
Das lokale statische Objekt wird als lokales Objekt mit längerer, aber begrenzter Gültigkeitsdauer angelegt. Die Gültigkeit endet spätestens bei Gevo-Ende, möglicherweise aber vorher.
Da wir eine TAA-übergreifende Definition für die Gültigkeit finden müssen, und die Transaktionsgrenzen plattformspezifisch sind, können wir nicht definieren, dass das Objekt gültig ist bis Transaktionsgrenze. Wir legen deshalb fest, dass die Dauer der Gültigkeit des Objekts prinzipiell undefiniert ist: Die Anwendung muss zu jeder Zeit davon ausgehen, dass kein Objektinhalt (mehr) zur Verfügung steht. Das Verschwinden des Objektinhalts kann unter CICS durch eine Transaktionsgrenze bedingt sein, im LAN z.B. durch Prozesswechsel, oder durch Plattformwechsel (LAN→Host). Das Objekt wird auch bei Workflow-veranlasster Unterbrechung nicht im Kontext gesichert. Wenn man sicher sein will, dass ein Objektinhalt über all diese Grenzen erhalten bleibt, muss man ein globales Objekt definieren.
Im LAN wird für das Objekt intern ein Name gebildet aus Objektname, Modulname und BC-ID. Die Namenskonvention auf dem Host dürfte entsprechend nachzubilden sein.
Beim Unregister des Moduls, das dieses Objekt deklariert hat, erfolgt – wie bei Parameterobjekten – ein automatischer PUT auf Record-Objekte, damit der aktuelle Objektinhalt gesichert werden kann. Ebenfalls wie bei Parameterobjekten, muss bei LST-Objekten der Put durch die Anwendung selbst erfolgen.
Es gibt eine konzeptionelle Auswirkung von lokalen statischen Objekten, die zumindest erwähnt werden sollte:
Man kann nicht mehr davon ausgehen kann, das TAA-Module prinzipiell reentrant sind. Anwendungslogisch gesehen, besteht ein Unterschied, ob innerhalb der Anwendung das Modul zum ersten Mal aufgerufen wird, oder es sich um einen Folge-Aufruf handelt. Bisher konnte die Anwendung davon ausgehen, dass der Zustand des Moduls immer gleich ist, d.h. die Working-Storage und Objektbereiche immer gleich initialisiert sind, egal ob ein Aufruf vorher erfolgte oder nicht; dies ist bei Verwendung von lokalen statischen Objekten nicht mehr der Fall.
Bei Plattformwechsel, z.B. Start der Anwendung im LAN, weitere Bearbeitung unter MVS, ist zu beachten, dass bei Ausführung desselben Moduls auf unterschiedlichen Plattformen das statische lokale Objekt nur innerhalb einer Plattform zur Verfügung steht.
Die Unterstützung in AL/MVS ist nicht unbedingt erforderlich, zumal die AL keinen Bedarf für diese Funktionalität hat.
Die Unterstützung in der LAN-Infrastruktur ist notwendig, auch wenn daraus kein unmittelbarer Nutzen für die Hallesche entsteht, weil
a) sonst keinerlei Test des Features außerhalb der Hallesche möglich ist.
b) Auch die Hallesche auf dem PC testet, und das Verhalten von Datenzugriffsmodulen für sinnvollen Test gleich sein sollte.
c) Nicht auszuschließen ist, dass, wenn die LAN-Infrastruktur statische lokale Objekte nicht kennt, unerwartetes Verhalten auftritt aufgrund des veränderten Generats.
d) eine Vereinbarung besteht, dass die LAN-Infrastruktur sämtliche Funktionalitäten prinzipiell unterstützen soll, d.h. alle Module, die auf dem Host laufen, müssen mit gleicher Funktionalität im LAN ausführbar sein.