Diese Seite beschreibt, welche OM-Returncodes von den verschiedenen Objektoperationen gesetzt werden.
Die hier beschriebenen Reaktionen gelten in jedem Fall für die Programmausführung im LAN. Unter MVS kann es, vor allem was die automatische Fehlerbehandlung über Conditions angeht, zu Abweichungen kommen, obwohl wir uns bemühen, dies zu vermeiden. Wenn Sie solche Abweichungen feststellen, bitten wir um Mitteilung, um diese nach Möglichkeit beseitigen zu können.
Um die Tabelle nicht unnötig aufzublähen, gilt, wenn nichts anderes angegeben ist:
| OM-RC-OK | Die gewünschte Operation wurde erfolgreich ausgeführt. |
| OM-RC-NOT-OK | Die gewünschte Operation wurde wegen eines Fehlers abgebrochen; es wurde kein Ergebnis bereitgestellt. Typische Ursachen sind bei Objektoperationen: ungültiger Objekthandle; bei List-Objekten: gewünschter Satz konnte nicht gelesen werden, obwohl die Bedingungen für EOL nicht erfüllt sind. Je nach Operation sind andere Ursachen möglich, auf die her aber nicht weiter eingegangen wird. Eine Information über den aufgetretenen Fehler ist bei NOT-OK i.d.R. über die gesetzten Laufzeitzustände (Conditions) verfügbar. |
| EOL | Wird nur bei List-Objekten gesetzt; Das Ende der Liste bzw. (beim Rückwärtslesen, Previous) der Anfang der Liste wurde erreicht; Das Objekt enthält nicht so viele Sätze, wie als Index angegeben ist (Index > Anzahl Sätze, Lesen hinter Listenende), oder Index = 0 (Lesen vor Listenanfang). |
In der nachfolgenden Tabelle sind Zusatzinformationen zu den Returncodes in der dem Returncode entsprechenden Farbe unterlegt.
Die Operationen sind in alphabetischer Reihenfolge aufgeführt.
| OM-Operation | liefert OM-RC-… | Zusatzinformationen |
|---|---|---|
| ADD | NOT-OK OK EOL | Aus Gründen der Kompatibilität bleibt der Returncode EOL, obwohl der Satz nicht hinzugefügt werden kann. Es wird aber eine „Severe“-Condition gesetzt, aufgrund derer bei automatischer Fehlerbehandlung (s. unten) reagiert wird wie bei NOT-OK. S. auch Registry-Setting CblVerifyAddPosition |
| ADDLIST | NOT-OK OK EOL | Aus Gründen der Kompatibilität bleibt der Returncode EOL, obwohl die Sätze nicht hinzugefügt werden können. Es wird aber eine „Severe“-Condition gesetzt, aufgrund derer bei automatischer Fehlerbehandlung (s. unten) reagiert wird wie bei NOT-OK. |
| CHECK | NOT-OK OK EOL | NOT-OK wird auch gesetzt, wenn die Prüfung ergibt, dass der Satzinhalt nicht den Regeln entspricht. Da die in den Prüfroutinen gesetzten Conditions i.d.R. nicht >= „Severe“ sind, wird auch bei automatischer Fehlerbehandlung das Modul nicht abgebrochen, sondern dieser NOT-OK kann vom Programmierer behandelt werden. |
| COMPLETEREF | NOT-OK OK | OK wird auch gesetzt, wenn bei dem Zugriff kein Satz gelesen wurde (leere Schlüsseltabelle oder Schlüssel in Tabelle nicht gefunden). |
| CONVERT | NOT-OK OK | |
| COPY | NOT-OK OK EOL | Aus Gründen der Kompatibilität bleibt der Returncode EOL, obwohl der Satz nicht kopiert werden kann. Es wird aber eine „Severe“-Condition gesetzt, aufgrund derer bei automatischer Fehlerbehandlung (s. unten) reagiert wird wie bei NOT-OK. |
| COPYLIST | NOT-OK OK | |
| CREATE CURSOR | NOT-OK OK (EOL) | Wenn das Registry-Setting „AutoGetFirst“ eingeschaltet ist, erfolgt nach einem erfolgrechen Create Cursor ein GET FIRST; der gelieferte Returncode ist dann der des GET. Insofern kann also der Create Cursor auch EOL liefern. |
| DECLARE | keiner | (Durchführung im Rahmen des Register, daher keine RC-Abfrage möglich) |
| DECLARE CURSOR | keiner | (Durchführung im Rahmen des Register, daher keine RC-Abfrage möglich) |
| DELETE | NOT-OK OK EOL | Aus Gründen der Kompatibilität bleibt der Returncode EOL, obwohl der Satz nicht gelöscht werden kann. Es wird aber eine „Severe“-Condition gesetzt, aufgrund derer bei automatischer Fehlerbehandlung (s. unten) reagiert wird wie bei NOT-OK. |
| DELETELIST | NOT-OK OK | |
| DESTROY CURSOR | OK | Anweisung liefert immer OK. Wenn der Cursor in Benutzung ist, wrid er freigegeben. Ist er nicht in Benutzung, führt die Operation trotzdem nicht zum Fehler. |
| DUMP | NOT-OK OK | |
| GET | NOT-OK OK EOL | |
| GET BLOB | s. GET | Wenn der Zugriff auf den Satz selbst fehlerfrei ist, bleibt der Returncode OK, auch falls die Blob-Daten nicht ermittelt werden können (der Blobinhalt ist dann NULL). Bei Problemen mit dem Blob-Zugriff werden jedoch Conditions gesetzt, die je nach Serverity bei automatischer Fehlerbehandlung (s. unten) zu Verhalten wie bein NOT-OK führen können. |
| GET USING CURSOR | s. GET | |
| GET WHERE; GET WHERE USING CURSOR | s. GET | Es wurde in der angegebenen Suchrichtung kein Satz mehr gefunden, der der Where-Bedingung entspricht |
| GETINFO | NOT-OK OK | Hier wird bei NOT-OK eine Condition „Warning“ gesetzt, die bei automatischer Fehlerbehandlung nicht zum Modulabbruch führt. |
| INITIALIZE | OK | Anweisung liefert immer OK. |
| INSERT | s. ADD | |
| INSERTLIST | s. ADDLIST | |
| NEW | NOT-OK OK | |
| PUT | NOT-OK OK EOL | Aus Gründen der Kompatibilität bleibt der Returncode hier EOL, aber es wird eine „Severe“-Condition gesetzt, aufgrund derer bei automatischer Fehlerbehandlung (s. unten) reagiert wird wie bei NOT-OK. |
| PUT BLOB | s. PUT | |
| RESETCONTENTS | NOT-OK OK | |
| SORT | NOT-OK OK |
Wenn die automatisierte Behandlung von durch die Infrastruktur gesetzten Conditions eingeschaltet ist, wird das Modul bei schweren Fehlern automatisch beendet, sodass im Programm keine Reaktion auf den Returncode NOT-OK mehr ausprogrammiert werden muss.