Ansicht
Dokumentation

ABENOPERANDS_DATA_OBJECTS - OPERANDS DATA OBJECTS

CL_GUI_FRONTEND_SERVICES - Frontend Services   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Datenobjekte an Operandenpositionen

... Schreibpositionen zu unterscheiden. Weiterhin müssen Datentyp und Inhalt der angegebenen Datenobjekte zur Operandenposition passen.

Lesepositionen

An einer Leseposition wird der Inhalt eines Operanden bei der Ausführung der Anweisung nur gelesen, aber nicht geändert. An Lesepositionen können Datenobjekte wie folgt angegeben werden:

• Angabe eines Literals (Textfeldliteral, Stringliteral, Zahlenliteral).
  

• Angabe eines an dieser Stelle sichtbaren Datenobjekts über einen Bezeichner dobj, ein Feldsymbol <fs> oder eine dereferenzierte Datenreferenz dref->* (seit Release 6.10 und falls dref typisiert ist). Zu den Namen von Datenobjekten zählen hierbei auch die Angabe eines Textsymbols über text-###, wobei ### die dreistellige Kennung des Textsymbols ist, oder Verkettungen von Referenzvariablen. Bei Verwendung eines Feldsymbols oder einer Datenreferenz dürfen diese nicht initial sein.
  
  Alternativ zur Angabe eines Textsymbols über text-### kann die dreistellige Kennung eines Textsymbols in runden Klammern an ein Literal angehängt werden:
  
  ... 'Literal'(###) ...
  
  Wenn das Textsymbol in der aktuell gesetzten Sprache vorhanden ist, wird statt des Literals der entsprechende Inhalt des Textsymbols verwendet, ansonsten das Literal.

• Falls das Datenobjekt eine interne Tabelle ist, können auch die Ausdrücke dobj[], <fs>[]oder dref->*[] verwendet werden, wodurch garantiert der Tabellenkörper und keine eventuelle Kopfzeile angesprochen wird. Falls eine interne Tabelle keine Kopfzeile hat, wird auch ihr bloßer Name (ohne []) an allen Operandenpositionen als Tabellenkörper interpretiert. Falls eine interne Tabelle jedoch eine Kopfzeile hat, wird ihr bloßer Name (ohne []) an fast allen Operandenpositionen als Kopfzeile und nicht als Tabellenkörper interpretiert. Nur an Operandenpositionen, an denen eine interne Tabelle erwartet wird (insbesondere in den Anweisungen zur Bearbeitung interner Tabellen), beim Speichern und Lesen von Daten-Clustern mit EXPORT und IMPORT, bei den Anweisungen FREE und SEARCH und allen dynamischen Angaben von Anweisungsteilen in Open SQL (außer bei der Angabe von Datenbanktabellen) wird der Name einer internen Tabelle als Tabellenkörper interpretiert.

• Angabe eines Teilbereichs eines zeichen- oder byteartigen Datenobjekts über das direkte Anhängen einer Offset-/Längenangabe an den Bezeichner, ein Feldsymbol oder eine dereferenzierte Datenreferenz (seit Release 6.10 und falls die Datenreferenz typisiert ist):
  
  dobj[+off][(len)]
  <fs>[+off][(len)]
  dref->*[+off][(len)]
  
  Für die Operanden off und len werden Datenobjekte vom Typ i erwartet, die positive ganze Zahlen enthalten müssen. Es wird das Teilstück des Datenobjekts verwendet, das den in off angegebenen Offset und die in len angegebene Länge in Zeichen hat.
  
  Außer bei der Anweisung ASSIGN darf kein Speicherbereich außerhalb der Feldgrenzen adressiert werden. Bei einer Offsetangabe ohne Länge wird das gesamte Teilfeld ab off Zeichen adressiert, bei einer Längenangabe ohne Offset die ersten len Zeichen. Bei der Anweisung ASSIGN gelten andere Regeln.
  
  Bei der Angabe eines Literals oder eines Textsymbols können keine Offset- und Längenangaben gemacht werden.
  
  Ab 6.10 werden Offset- und Längenangaben bei zeichenartigen Datenobjekten in Zeichen und andernfalls in Byte gezählt. In Nicht-Unicode-Systemen entspricht ein Zeichen einem Byte.
  
  In Unicode-Programmen sind Offset- und Längenangaben nur auf zeichenartige und byteartige Bereiche von Datenobjekten zulässig. Offset- und Längenangaben für Strukturen sind in Unicode-Programmen nur zulässig, wenn diese flach sind und die Offset- und Längenangabe ausschließlich auf das erste Unicode-Fragment der Struktur zugreift und dieses zeichenartig ist.

• Angabe einer eingebauten Funktion. Die eingebauten Funktionen sind verwendbar als Quellfelder der Anweisung MOVE, als Operanden in arithmetischen Ausdrücken der Anweisung COMPUTE, als Operanden in logischen Ausdrücken, als Operanden der Anweisungen CASE und WHEN sowie als Operanden der Zusätze WHERE in den Anweisungen LOOP AT, DELETE und MODIFY für interne Tabellen. Das Ergebnis der eingebauten Funktion wird als Operand verwendet.
  
  Vor Release 6.10 konnten eingebaute Funktionen ausschließlich in der Anweisung COMPUTE angegeben werden.

• Angabe einer funktionalen Methode. Funktionale Methoden können an den gleichen Stellen wie eingebaute Funktionen als Operanden angegeben werden. Die Syntax für keinen, einen oder mehrere Eingabeparameter der Methode lautet:
  
  meth( )
  meth( a )
  meth( p1 = a1 p2 = a2 ... )
  
  Dabei ist meth der Bezeichner einer Methode und kann wie bei CALL METHOD beschrieben angegeben werden. Der Rückgabewert der funktionalen Methode wird als Operand verwendet. Die Syntax entspricht den Kurzformen der Anweisung CALL METHOD. Wenn eine funktionale Methode den gleichen Namen wie eine eingebaute Funktion hat, wird mit dem Ausdruck meth( a ) immer die funktionale Methode aufgerufen.

Schreibpositionen

An einer Schreibposition wird der Inhalt eines Operanden bei der Ausführung der Anweisung geändert. An Schreibpositionen können nur änderbare Datenobjekte # also keine Literale, Textsymbole, Konstanten oder nicht-änderbare Formalparameter # wie folgt angegeben werden:

• Angabe eines an dieser Stelle sichtbaren Datenobjekts über einen Bezeichner dobj, ein Feldsymbol <fs> oder eine dereferenzierte Datenreferenz dref->* (seit Release 6.10 und falls dref typisiert ist). Bei internen Tabellen kann wie bei Lesepositionen [] angehängt werden, um den Tabellenkörper zu adressieren.

• Angabe eines Teilbereichs eines flachen zeichen- oder byteartigen Datenobjekts über das direkte Anhängen einer Offset- oder Längenangabe an den Bezeichner, ein Feldsymbol oder eine dereferenzierte Datenreferenz (siehe oben). Bei Datenobjekten der tiefen Datentypen string und xstring kann an Schreibpositionen keine Offset- oder Längenangabe gemacht werden.

Operandentyp

ABAP-Anweisungen erwarten für jeden Operanden einen bestimmten Datentyp, der z.B. bei Zuweisungen auch von anderen Operanden abhängen kann. Wenn das angegebene Datenobjekt einen anderen Datentyp hat, wird versucht, seinen Inhalt gemäß der Konvertierungsregeln in den geforderten Typ zu konvertieren, womit erhöhte Laufzeitkosten verbunden sind. Falls keine entsprechenden Konvertierungsregeln definiert sind oder der Inhalt nicht konvertierbar ist, gibt es einen Syntaxfehler oder es kommt zu einer Ausnahme.

Hinweis

Zur Optimierung der Programmlaufzeit sollten Operanden möglichst passend angegeben werden. Beispielsweise kann an Operandenpositionen, an denen eine Zahl erwartet wird, wie z.B. bei Indexangaben, ein beliebiges numerisches Datenobjekt angegeben werden. Empfohlen ist aber der passende numerische Datentyp (meistens i).

Strukturen in Operandenpositionen

In Nicht-Unicode-Programmen können flache Strukturen an allen Operandenpositionen verwendet werden, wo elementare Felder erwartet werden. In Unicode-Programmen ist dies nur möglich, wenn die Komponenten der Struktur flach und zeichenartig sind. Die Struktur wird in beiden Fällen wie ein einziges Datenobjekt vom Typ c behandelt (implizites Casting).

BAL_S_LOG - Application Log: Log header data   Addresses (Business Address Services)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 8737 Date: 20240523 Time: 090522     sap01-206 ( 209 ms )