Hier wird beschrieben, welche Operationen auf Objekte von der TAA automatisch vorgenommen werden, und zwar einerseits beim Register bzw. Unregister von Modulen, und andererseits beim Aufruf anderer TAA-Bausteine.
Zuerst wird beschrieben, welche Operationen in der PC-Infrastruktur automatisch vorgenommen werden. Diese Angaben gelten für alle Module, die auf dem PC ausgeführt werden, unabhängig von der benutzten Programmiersprache.
Anschließend wird beschrieben, welche Operationen in vom TAA-Preprozessor erstellte COBOL-Module hineingeneriert werden. Diese Operationen erfolgen zusätzlich zu den von der Infrastruktur vorgenommenen Operationen.
Am Ende steht eine Liste von Unterschieden und Eigenheiten, die für die unterschiedlichen Laufzeitumgebungen beachtet werden sollten.
Die folgenden Operationen werden für alle Objekte ausgeführt, welche in der Modulschnittstelle definiert sind und nicht die Rolle NOP haben:
| Objektart | Klasse | Rolle | Operation |
| Global, Parm | alle | CRE | taaOmObjNew |
| Global, Parm | REC | MOD | Falls das Objekt noch nicht angelegt wurde (taaOmObjExists), taaOmObjNew |
| Global, Parm | LST, REF | alle | Wenn die Liste nicht leer ist, aber kein Eintrag current ist, wird auf den 1. Eintrag positioniert |
Falls (was nur beim Modultest vorkommen sollte) ein Parameterobjekt nicht übergeben wurde, wird ein Objekt als Dummy dafür deklariert und angelegt (NEW).
Die folgenden Operationen werden für alle Objekte ausgeführt, welche in der Modulschnittstelle definiert sind und nicht die Rolle NOP haben:
| Objektart | Klasse | Rolle | Operation |
| Global, Parm | REC | DEL | taaOmObjDelete |
| Global, Parm | LST, REF | DEL | taaOmObjReset |
| Lokal | alle | taaOmObjDestroy |
Keine automatischen Operationen. Es werden lediglich die Handles der Objekte des Aufrufers mit dem entsprechenden Objekt des aufgerufenen Moduls verbunden.
Bei der Benutzung von COBOL-Modulen ist es unbedingt erforderlich, den Objektinhalt, der im Programm verändert wurde, über einen PUT an die Infrastruktur zu übergeben bzw. nach einem Modulaufruf über einen GET von der Infrastruktur den aktualisierten Inhalt abzuholen. Der Grund dafür ist, dass bei COBOL der Objektinhalt als programmlokale Kopie (in der Linkage Section) bereitgestellt wird, wohingegen bei der Arbeit mit z.B. C oder VB direkt auf dem Objekt in der Infrastruktur operiert wird. Die dafür in COBOL üblicherweise notwendigen Operationen werden in vom Preprozessor generierten Modulen für den Register, Unregister und Modulaufrufe automatisch erzeugt.
Die Generate des TAA-COBOL-Preprozessors sind für Einsatz unter MVS und PC im wesentlichen gleich. Dennoch vorhandene Unterschiede sind, soweit sie Objektoperationen betreffen, unten vermerkt. Auf dem PC bedeutet dies, dass u.U. Operationen im COBOL-Code wiederholt werden, die auch bereits in der PC-Infrastruktur erfolgten, was aber nicht zu Problemen führt. Beispiele hierfür sind der Initialize, oder NEW und DEL für die Rollen CRE bzw. DEL. Für den Programmierer ist es dadurch hinsichtlich der automatischen Objektoperationen nicht von Bedeutung, ob ein Modul für Nutzung auf PC oder MVS erstellt wird.
Die folgenden Operationen werden für alle Objekte ausgeführt, welche in der Modulschnittstelle definiert sind:
| Objektart | Klasse | Rolle | Operation |
| Parm, Global | alle | CRE | NEW |
| Parm, Global | REC | REF MOD DEL | GET |
| Parm, Global | LST, REF | REF MOD DEL | GET FIRST (abhängig vom Setting AutoGetFirst) |
| Objektart | Klasse | Rolle | Operation |
| Parm, Global | REC | MOD CRE | PUT |
| Parm, Global | REC | DEL | DELETE |
| Parm, Global | LST, REF | DEL | RESETCONTENTS |
Vor dem Aufruf werden für die zugewiesenen Objekte folgende Operationen ausgeführt, es sei denn, das Objekt hat in dem aufgerufenen Modul die Rolle CRE:
| in aufgerufenem Modul | im aktuellen Modul | |||
| Rolle | Objektart | Klasse | Rolle | Operation |
| REF MOD DEL | Parm Global | RC | MOD CRE DEL | PUT |
| REF MOD DEL | Lokal | REC | - | PUT |
| alle | LST | keine | ||
Bei Rückkehr ins aufrufende Modul werden folgende Operationen ausgeführt:
| Objektart | Klasse | Rolle | |
| alle zugewiesenen Objekte | REC | - | GET |
| alle zugewiesenen Objekte | LST | - | keine |
| Global | REC | alle1) | GET |
| Global | LST | alle2) | GET CURRENT (abhängig vom Setting AutoGetFirst) |
*) außer NOP
Das bedeutet, dass prinzipiell alle notwendigen PUTs und GETs für REC-Objekte, die als Parameter übergeben werden automatisch generiert werden. Bei LST-Objekten dagegen muss der Programmierer selbst für die erforderlichen PUTs/GETs sorgen.
Eine häufig auftauchende Frage ist, warum für globale REC-Objekte zwar nach einem Call ein GET gemacht wird, nicht aber vor einem CALL ein PUT. Wenn ein Modul den Inhalt eines globalen Objekts in der Infrastruktur verändert hat, sorgt die Infrastruktur dafür, dass anderen betroffenen Modulen dieser neue Inhalt bekannt gemacht wird. Ob aber ein Modul den lokal veränderten Zwischenstand eines globalen Objekts zum Zeitpunkt eines Modulaufrufs bereits an die Infrastruktur übergeben möchte, entscheidet dieses Modul, sprich der Programmierer.
Es besteht auch keine direkte Beziehung zwischen globalen Objekten und aufgerufenen Modulen: Es ist nicht ohne weiteres erkennbar, ob und wie ein globales Objekt in der Hierarchie des Modulaufrufs benutzt wird. Anders ist es bei Objekten, die als Parameter zugeordnet wurden: Hier besteht eine explizite Beziehung zwischen dem Objekt in dem aufrufenden Modul und dem Objekt in dem aufgerufenen Modul.
Um andererseits sicherzustellen, dass die Änderung in einem globalen Objekt, die in einem aufgerufenen Modul vorgenommen wurde, nicht verloren gehen kann, ist der GET im Anschluss ein einen CALL unbedingt notwendig und liegt deshalb nicht im Ermessen des Programmierers. Würde der GET nach einem CALL nicht durchgeführt, würden Änderungen, die in anderen Modulen durchgeführt wurden, durch Rückkehr in das aufrufende Modul implizit zunichte gemacht, ohne dass irgendjemand davon etwas merken würde.
Da Steuerungen keine Objektoperationen durchführen, enthalten sie auch keine Datenstrukturen für die Objekte, und wird ausschließlich ein GETHANDLE durchgeführt, aber kein GET, PUT o.ä. Ausnahme sind Objekte, die von Steuerungen intern benutzt werden (z.B. SYSTVAR bei Verwendung des START-Konstrukts); für solche Objekte gelten dieselben Regeln wie für Objekte in nicht-Steuerungs-Modulen.
Obwohl wir uns bemühen, das Generat und die Laufzeitumgebungen für COBOL-Module unter MVS und im LAN so zu gestalten, dass sich die Module in beiden Umgebungen gleich verhalten, ist dies nicht immer vollständig möglich. Wir möchten hier auf einige Stellen hinweisen, wo Unterschiede bei der Objektbehandlung auftreten können, damit dies, falls notwendig, bei der Programmierung berücksichtigt werden kann und Probleme und aufwändige Fehlersuchen vermieden werden können.