Anforderungen an ABAP-Programme inUnicode-Systemen

Version: 3. Mai 2007

Inhalt Seite 1. Codes 3

2. ABAP-Entwicklung unter Unicode 4

3. Bezeichnungen und Vereinbarungen 5

3.1 Datentypen 5 3.2 Datenlayout von Strukturen 6 3.3 Unicode-Fragmentsicht 7 3.4 Zulässige Zeichen 7

4. Einschränkungen in Unicode-Programmen 8

4.1 Zeichenartige und numerische Operanden 8 4.2 Zugriffe mit Offset- und Längenangaben 9 4.3 Zuweisungen 11 4.4 Vergleiche 14 4.5 Verarbeitung von Zeichenketten 15 4.6 Typprüfung und Typkompatibilität 16 4.7 Änderungen bei Datenbank-Operationen 17 4.8 Längen- und Abstandsermittlung 18 4.9 Sonstige Änderungen 19

5. Neue ABAP-Anweisungen für Unicode 21

5.1 Stringverarbeitung für Bytefolgen 21 5.2 Längen- und Abstandsermittlung 22 5.3 Zuweisungen an Feldsymbole 23 5.4 Includes mit Gruppennamen 26 5.5 Dynamische Erzeugung von Datenobjekten 27 5.6 Dynamische Feldzuweisungen 28 5.7 Ablage von Daten als Cluster 29 5.8 Dateischnittstelle 30 5.9 Up- und Download von Dateien 32 5.10 Generische Typen für Feldsymbole und Parameter 32 5.11 Aufbereitung von Listen 32

6. Neue Klassen für Unicode 35

6.1 Ermittlung von Feldeigenschaften 35 6.2 Konvertierung von Daten 37

7. RFC und Unicode 38

8. Abrundungsmaßnahmen 38

9. Weitere Beispielprogramme zur Unicode-Umstellung 40

10. Glossar 59

11. Index der Schlüsselworte 60

2

1. Codes Bisher werden bei SAP verschiedene Codes für die Verschlüsselung von Zeichen verschiedener Schriften verwendet, zum Beispiel ASCII, EBCDI oder Double Byte Codepages. �� ASCII (American Standard Code for Information Interchange) verschlüsselt jedes

Zeichen durch 1 Byte = 8 Bit. Damit lassen sich höchstens 28 = 256 Zeichen darstellen, denen die Kombinationen [00000000, 11111111] zugeordnet werden. Gebräuchliche Codepages sind zum Beispiel ISO88591 für westeuropäische oder ISO88595 für kyrillische Schriften.

�� EBCDIC (Extended Binary Coded Decimal Interchange) verschlüsselt ebenfalls

jedes Zeichen durch 1 Byte, womit sich wiederum 256 Zeichen abbilden lassen. EBCDIC 0697/0500 ist ein altes IBM Format, das zum Beispiel auf AS400 für westeuropäische Schriften verwendet wird.

�� Double Byte Codepages benötigen 1 bis 2 Byte je Zeichen. Damit können 216 =

65536 Kombinationen gebildet werden, wobei in der Regel nur 10000 - 15000 Zeichen belegt sind. Als Codepages werden zum Beispiel SJIS für japanische und BIG5 für traditionelle chinesische Schrift verwendet.

Mit diesen Zeichensätzen kann jede für SAP interessante Sprache einzeln abgedeckt werden. Schwierigkeiten ergeben sich allerdings, wenn man in einem zentralen System Texte aus verschiedenen inkompatiblen Zeichensätzen mischen möchte. Auch der Austausch von Daten zwischen Systemen mit inkompatiblen Zeichensätzen kann zu völlig undefinierten Situationen führen. Die Lösung des Problems ist die Verwendung eines Codes, der alle Zeichen dieser Erde umfaßt. Dieser Code heißt Unicode (ISO/IEC 10646) und besteht mindestens aus 16 Bit = 2 Byte, alternativ aus 32 Bit = 4 Byte je Zeichen. Obwohl der Umstellungsaufwand für SAP-Kernel und Anwendungen enorm ist, ergeben sich langfristig durch die Einführung von Unicode große Vorteile: �� Das gesamte Internet (www) und damit auch mySAP.com basieren auf Unicode,

der damit Grundvoraussetzung für internationale Wettbewerbsfähigkeit ist. �� Mit Unicode können alle SAP-Anwender ein zentrales System installieren, das

die Geschäftsprozesse der gesamten Welt abdeckt. �� Auch Firmen mit verschiedenen verteilten Systemen wollen meist weltweite

Konzerndaten verdichtet aufbereiten. Dies ist ohne Unicode nur bedingt möglich.

�� Unter Unicode können gleichzeitig mehrere Sprachen auf einem Frontend verwendet werden.

�� Unicode wird benötigt für einen anwendungsübergreifenden Datenaustausch ohne Datenverlust durch inkompatible Zeichensätze. Als mögliche Form der Darstellung von Dokumenten im World Wide Web (www) kann dabei zum Beispiel XML verwendet werden.

ABAP-Programme müssen überall dort geändert werden, wo eine explizite oder implizite Annahme über die interne Länge eines Zeichens gemacht wird. Dadurch

3

wird eine neue Abstraktionsebene erreicht, die es erlaubt, dieselben Porgramme sowohl in einem herkömmlichen als auch in einem Unicode System ablaufen zu lassen. Außerdem hält man sich damit die Möglichkeit offen, bei einer weiteren Vergrößerung des Unicode-Zeichenvorrates eine interne Darstellung der Unicode- Zeichen mit 2 oder 4 Byte zu wählen. Die Beispiele in den nachfolgenden Kapiteln unterstellen einen Unicode mit einer Verschlüsselung von 2 Byte je Zeichen. 2. ABAP-Entwicklung unter Unicode Ein Unicode-fähiges ABAP-Programm (UP) ist ein Programm, bei dem alle Unicode-Prüfungen wirksam sind. Ein solches Programm liefert in einem Nicht-Unicode- System (NUS) dieselben Ergebnisse wie in einem Unicode-System (US). Um die entsprechenden Syntaxprüfungen durchzuführen, muß das Unicodeflag in den Dynpros der Programm- und Klasseneigenschaften aktiviert werden. In einem US können nur Programme ausgeführt werden, die das Unicodeflag gesetzt haben. Für alle SAP-Programme muß zukünftig das Unicodeflag gesetzt sein, damit sie auf Unicode-Systemen laufen können. Ist das Unicodeflag für ein Programm gesetzt, erfolgt die syntaktische Prüfungen und die Programmausführung gemäß den Regeln, die in diesem Dokument beschriebenen sind. Dies ist unabhängig davon, ob es sich um ein US oder ein NUS handelt. Das Unicodeflag wird zukünftig für alle Programme und Klassen gesetzt, die neu angelegt werden. Ist das Unicodeflag nicht gesetzt, kann das Programm nur in einem NUS ausgeführt werden. Für solche Programme sind die nachfolgend beschriebenen Syntax- und Semantikänderungen nicht wirksam. Es können jedoch alle Spracherweiterungen benutzt werden, die im Zusammenhang mit der Unicode-Umstellung eingeführt wurden.

Die mit dem Unicodeflag verbundenen Änderungen und Einschränkungen bewirken, daß Programme in US und NUS weitestgehend mit gleicher Semantik ausgeführt werden, wobei in wenigen Fällen dennoch Unterschiede auftreten können. Programme, die in beiden Systemen laufen sollen, müssen daher auch auf beiden Plattformen getestet werden.

Zusätzlich wurden im Rahmen der Unicode-Einführung folgende Umstellungen in der Syntaxprüfung an das Unicode-Flag gebunden:

1. Nicht erreichbare Anweisungen führen in UP zu einem Syntaxfehler. In NUP gab dies bisher nur eine Syntaxwarnung.

2. Der Aufruf eines Funktionsbausteins, dessen Parameternamen statisch als Literal oder als Konstante angegeben werden, führt in UP zu einer behandelbaren Ausnahme, wenn ein falscher Parametername angegeben wird. Dies gilt nur für Funktionsbausteine, die nicht via Remote Function Call aufgerufen werden. In NUP wurde ein falscher Name bisher ignoriert.

4

Für die Umstellung von Programmen auf US wird folgendes Vorgehen empfohlen:

�� Zuerst sollte die Transaktion uccheck im NUS gestartet werden, welche die Unicode-relevanten Syntaxfehler für eine kleine Programmenge ermittelt. Sind Syntaxfehler für eine größere Programmenge zu ermitteln, dann kann ein entsprechender SAMT-Scan mit dem Hauptprogramm RSUNISCAN_FINAL und der Unterroutine SAMT_SEARCH eingeplant werden.

�� Bevor im NUS das Unicodeflag in den Eigenschaften des betreffenden Programmes angekreuzt wird, müssen sämtliche Syntaxfehler beseitigt werden.

�� Nach Aktivierung des Unicodeflags im NUS wird immer die Unicode-Syntaxprüfung für dieses Programm durchgeführt. Dazu besteht im Editor unter Hilfsmittel -> Einstellungen -> Editor die Möglichkeit, maximal 50 Syntaxfehler gleichzeitig durch Ankreuzen des entsprechenden Feldes aufzulisten.

�� Wenn alle syntaktischen Anforderungen im NUS erfüllt sind, muß dasselbe Programm anschließend im NUS und im US getestet werden. Testziele sind die Erkennung von Laufzeitfehlern und die Korrektheit der Ergebnisse in beiden Systemen. Um Laufzeitfehler im Vorfeld auszuschließen, sollten Feldsymbole und Parameter immer typisiert werden, damit problematische Stellen bereits von der Syntaxprüfung erkannt werden.

ABAP: Programmeigenschaften VER00778 ändern X

Doku-Check

Attribute

Typ

Status

Anwendung

Berechtigungsgruppe

Paket

Logische Datenbank

Selektionsbildversion

Editorsperre Festpunktarithmetik

Unicodeprüfungen aktiv Start über Variante

Sichern

SABP

Ausführbares Programm

Produktives SAP-Standardprogramm

Basis (System)

Titel

Origibalsprache DE Deutsch

Erstellt 09.06.1999 Schröder

Letzte Änderung 15.01.2000 Schröder

Status aktiv

3. Bezeichnungen und Vereinbarungen 3.1 Datentypen Zu den Datentypen, die in UP als zeichenartig interpretiert werden, gehören:

5

�� C Character (Buchstaben, Ziffern, Sonderzeichen) �� N Numerisch Character (Ziffern) �� D Datum �� T Zeit �� STRING Zeichenkette �� Zeichenartige Strukturen Strukturen, die direkt oder in Unterstrukturen nur

Felder der Typen C, N, D oder T enthalten

Ein Zeichen dieses Typs ist im NUS 1 Byte und im US so lang, wie es der Länge eines Zeichens auf der jeweiligen Plattform entspricht. Nicht mehr unterstützt wird der Datentyp W.

Als byteartig werden Variable der Typen X und XSTRING bezeichnet. Strukturen werden nach folgenden Merkmalen unterschieden: �� Flache Struktur enthalten nur Felder der Elementartypen C, N, D, T, F, I, P und

X oder wiederum Strukturen mit diesen Typen. �� Tiefe Strukturen enthalten zusätzlich zu den Elementartypen Strings, interne

Tabellen und Feld- oder Objektreferenzen. �� Geschachtelte Strukturen sind Strukturen, die wiederum Unterstrukturen als

Komponenten enthalten. �� Nicht geschachtelte Strukturen bezeichnen Strukturen, die keine weiteren

Strukturen enthalten. 3.2 Datenlayout von Strukturen Für einige Datentypen wie I, F oder Objektreferenzen gibt es bestimmte Ausrichtungsanforderungen, die von der jeweiligen Plattform abhängen. Felder mit einem solchen Typ müssen im Speicher auf Adressen beginnen, die durch 4 oder 8 teilbar sind. Zeichenartigen Typen stehen an Speicheradressen, die je nach Unicode-Darstellung durch 2 oder 4 teilbar sind.

Innerhalb einer Struktur werden vor Komponenten mit Ausrichtungsanforderungen gegebenenfalls Bytes eingefügt, um die notwendige Ausrichtung zu erreichen. Diese Bytes werden als Alignment (A) bezeichnet. Grundsätzlich wird eine Unterstruktur gemäß der größten Alignmentanforderung eines der enthaltenen Felder ausgerichtet. Dabei gilt eine enthaltene Unterstruktur als Feld. Includes in Strukturen gelten in diesem Sinne als Unterstruktur.

Bei dem folgenden Beispiel einer Struktur mit drei Feldern werden weder in NUS noch in US Alignments gebildet: BEGIN OF struc1, a(1) TYPE X, b(1) TYPE X, c(6) TYPE C, END OF struc1. Dagegen werden im nächsten Beispiel in US Alignments gebildet, in NUS jedoch nicht. Die erste Alignment-Lücke wird wegen der Ausrichtung der Struktur struc3,

6

die zweite wegen der Ausrichtung des C-Feldes c und die dritte wegen der Adressierung der Intergerzahl d gebildet. BEGIN OF struc2, a(1) TYPE X, BEGIN OF struc3, b(1) TYPE X, c(6) TYPE C, END OF struc3, d TYPE I, END OF struc2.

NUS a b c d

US a A b A c A d

| struc3 | 3.3 Unicode-Fragmentsicht Für Prüfungen in UP, zum Beispiel für die Zulässigkeit von Zuweisungen und Vergleichen, ist das Datenlayout von Strukturen relevant, das sich in der Unicode-Fragmentsicht niederschlägt. Diese Sicht zerlegt die Struktur in Alignmentlücken, in byte- und zeichenartige Bereiche und alle übrigen Typen wie P, I, F, Strings, Referenzen oder interne Tabellen. Nebeneinander liegende zeichenartige Komponenten einer Struktur mit Ausnahme von Strings werden intern genau dann zu einer Gruppe zusammengefaßt, wenn zwischen diesen Komponenten keine Alignment-Lücken liegen. Dabei werden alle möglichen Ausrichtungsanforderungen für Zeichen berücksichtigt. In gleicher Weise werden auch nebeneinander liegende byteartige Komponenten zusammengefaßt. BEGIN OF struc, a(2) TYPE C, b(4) TYPE N, c TYPE D, d TYPE T, e TYPE F, f(2) TYPE X, g(4) TYPE X, h(8) TYPE C, i(8) TYPE C, END OF struc.

Im folgenden Beispiel zeigen F1 - F6 die einzelnen Fragmente der Struktur struc:

a b c d A e f g A h i

| F1 | F2 | F3 | F4 | F5 | F6 |

7

3.4 Zulässige Zeichen In einem Unicode-System werden auch alle ABAP-Programmquellen als Unicode abgelegt. Wie in ABAP Objects sind in Programmen mit Unicode-Flag nur folgende Zeichen für Bezeichner erlaubt: 1. Die Buchstaben a - z und A - Z ohne Umlaute 2. Die Ziffern 0 - 9 3. Der Unterstrich _ Aus Kompatibilitätsgründen sind auch noch die Zeichen %, $, ?, -, #, * und / erlaubt, die aber nur in begründeten Ausnahmefällen verwendet werden sollten. Der Schrägstrich ist allerdings nur zum Abtrennen von Namensräumen in der Form /name/ möglich, wobei zwischen zwei Schrägstrichen mindestens drei Zeichen stehen müssen.

Damit Programme ohne Konvertierungsverluste von einem US in ein NUS transportiert werden können, sollten auch in einem US für Kommentare und Literale keine Zeichen verwendet werden, die in einem NUS nicht darstellbar sind. 4. Einschränkungen in Unicode-Programmen Die für Unicode erforderlichen Anpassungen und Restriktionen wurden seitens der ABAP-Entwicklung auf das Wesentliche beschränkt, um den Aufwand für die Umstellungen der ABAP-Anwender möglichst gering zu halten. Dies hat in einigen Fällen jedoch zu komplexeren Regeln geführt, beispielsweise bei Zuweisungen und Vergleichen zwischen inkompatiblen Strukturen.

4.1 Zeichenartige und numerische Operanden

Bisher galt in ABAP die Regel, daß flache Strukturen als Argumente von ABAP-Anweisungen auch überall dort verwendet werden können, wo Einzelfelder vom Typ C erwartet wurden. In UP ist dies nicht mehr generell erlaubt. In UP kann bei einer beliebigen Anweisung, die nur ein Einzelfeld erwartet, genau dann ein strukturiertes Feld verwendet werden, wenn dieses aus zeichenartigen Elementartypen oder aus rein zeichenartigen Unterstrukturen besteht. Die Struktur wird wie ein Einzelfeld vom Typ C behandelt.

Einschränkungen im Vergleich zu NUS ergeben sich hauptsächlich dadurch, daß flache Strukturen nur noch eingeschränkt und Felder vom Typ X oder XSTRING niemals als zeichenartig betrachtet werden. Flache Strukturen werden auch nur noch dann als numerisch aufgefaßt, wenn sie rein zeichenartig sind. Numerische Argumente sind zum Beispiel Offset- oder Indexangaben wie bei READ TABLE ... INDEX i. Die Zeichenartigkeit von Strukturen zeigen die beiden folgenden Beispiele:

8

BEGIN OF struc1, BEGIN OF struc2, a(2) TYPE C, a(2) TYPE C, b(2) TYPE C, Nicht n(6) TYPE N, Zeichenartig x(1) TYPE X, zeichenartig d TYPE D, i TYPE I, t TYPE T, END OF struc. END OF struc. Ein weiteres Beispiel ist der Gruppenwechsel bei internen Tabellen, veranlaßt durch das Schlüsselwort AT. In NUS werden Felder vom Typ X, die sich rechts vom Gruppenschlüssel befinden, als zeichenartig behandelt und daher mit einem Stern aufgefüllt. Dagegen erhält derselbe Typ in US seinen Initialwert.

4.2 Zugriffe mit Offset- und Längenangaben

Allgemein sind Offset/Längenangaben kritisch, weil die Länge der einzelnen Zeichen plattformabhängig ist und damit zunächst nicht geklärt ist, ob gerade bei gemischten Strukturen die Einheit Byte oder Zeichen gemeint ist. Zum Teil wurden daher erhebliche Einschränkungen erforderlich, jedoch ist ein Offset/Längenzugriff auch weiterhin in dem Umfang möglich, wie er nachfolgend dargestellt wird. Von dieser Regelung betroffen sind Zugriffe auf Einzelfelder und Strukturen, die Übergabe von Parametern an Unterprogramme und schließlich das Arbeiten mit Feldsymbolen. �� Zugriffe auf Einzelfelder

Zugriffe mit Offset/Länge sind auf zeichenartige Einzelfelder, auf Strings und auf Einzelfelder der Typen X und XSTRING zulässig. Offset und Länge werden bei zeichenartigen Feldern und Feldern vom Typ STRING zeichenweise interpretiert. Nur bei den Typen X und XSTRING werden die Werte für Offset und Länge in Byte angenommen.

�� Zugriffe auf Strukturen

Der Zugriff mit Offset und Länge auf strukturierte Felder wird als unerwünschte Programmiertechnik angesehen. Ein solcher Zugriff führt zu Fehlern, wenn in dem mit Offset und Länge überstrichenen Bereich sowohl zeichen- als auch nicht zeichenartige Komponenten liegen. Offset/Längenzugriffe auf Strukturen sind in UP nur zulässig, wenn sie flach sind und die Offset- und Längenangabe nur zeichenartige Felder ab dem Strukturbeginn einschließt. Das nachfolgende Beispiel zeigt eine Struktur mit zeichen- und nicht zeichenartigen Feldern. Ihre Definition im ABAP-Programm und die daraus resultierende Belegung im Hauptspeicher gestaltet sich so:

9

BEGIN OF STRUC,

a(3) TYPE C, "Länge 3 Zeichen b(4) TYPE N, "Länge 4 Zeichen c TYPE D, "Länge 8 Zeichen d TYPE T, "Länge 6 Zeichen e TYPE F, "Länge 8 Byte f(26) TYPE C, "Länge 28 Zeichen g(4) TYPE X, "Länge 2 Byte END OF STRUC. a b c d A e f g

| F1 | F2 | F3 | F4 |F5|

Intern weist die Fragmentsicht fünf Bereiche [F1, F5] auf, wobei hier ein Offset-Längenzugriff nur im Anfangsstück F1 möglich ist. Anweisungen wie struc(21) oder struc+7(14) werden seitens ABAP-Interpreter akzeptiert und wie ein Einzelfeld vom Typ C behandelt. Dagegen ist ein Zugriff struc+57(2) nur noch in NUP zulässig. Ist ein Offset/Längenzugriff auf eine Struktur erlaubt, dann werden in UP sowohl Offset- als auch Längenangaben stets als Zeichen interpretiert.

�� Parameterübergabe an Formroutinen

Die Parameterübergabe bei PERFORM erlaubte bisher, feldübergreifende Offset- und Längenangaben zu verwenden. Das wird zukünftig in UP verboten. Vielmehr führen hier Offset- und Längenzugriffe über Feldgrenzen hinaus zu einem Syntax- oder Laufzeitfehler. Zum Beispiel würden für ein zehnstelliges C-Feld c Zugriffe der Art c+15 oder c+5(10) einen solchen Fehler auslösen. Wird bei einem Parameter nur ein Offset, aber keine Länge angegeben, so wurde bisher die gesamte Länge des Feldes und nicht die Restlänge als Länge für den Zugriff verwendet. Damit sind Parameterangaben nur mit Offset feldübergreifend und lösen daher in UP einen Syntaxfehler aus. Ein PERFORM test USING c+5 ist daher verboten. Auch in UP kann weiterhin bei Parametern in der Form feld+off(*) die Restlänge ab Offset off spezifiziert werden.

�� Ranges für Offset- und Längenzugriffe bei Feldsymbolen

In UP wird sichergestellt, daß Offset/Längenzugriffe bei ASSIGN nur innerhalb eines vorgegebenen Bereichs (Range) zulässig sind. Im Normalfall stimmt der Range bei elementaren Feldern mit den Feldgrenzen und bei flachen Strukturen mit dem rein zeichenartigen Anfangsstück überein. Durch einen speziellen RANGE-Zusatz bei ASSIGN kann der Range auch über diese Grenzen hinaus erweitert werden. Feldsymbolen wird ein für Offset/Längenangaben zulässiger Range zugeordnet. Wird die Quellangabe einer ASSIGN-Anweisung mit einem Feldsymbol angegeben, so übernimmt das Ziel-Feldsymbol den Range der Quelle. Sofern nicht explizit angegeben wird, bestimmt sich der RANGE wie folgt:

10

ASSIGN feld TO <f>.

In UP erhält <f> die Feldgrenzen von feld als Range, wobei feld kein Feldsymbol ist. ASSIGN <g> TO <f>.

<f> übernimmt den Range von <g>. ASSIGN elfeld+off(len) TO <f>.

In UP erhält <f> die Feldgrenzen des Elementarfeldes elfeld als Range. ASSIGN <elfld>+off(len) TO <f>.

<f> übernimmt den Range des elemtaren Feldes elfeld.

ASSIGN struc+off(len) TO <f>. ASSIGN <struc>+off(len) TO <f>.

In UP bestimmt das rein zeichenartige Anfangsstück der flachen Strukturen struc oder <struc> die Range-Grenzen. Kann die Zuweisung an das Feldsymbol nicht erfolgen, weil die Offset- oder Längenangabe den zulässigen Range überschreitet, wird das Feldsymbol in UP auf UNASSIGNED gesetzt. Andere Prüfungen wie zum Beispiel Typ- oder Alignmentprüfungen führen in UP zu einem Laufzeitfehler. Generell werden Offset- und Längenangaben bei den Datentypen C, N, D und T sowie bei flachen Strukturen in Zeichen und sonst in Bytes gezählt.

�� Offset ohne Längenangabe bei Feldsymbolen

Bisher hatte ASSIGN feld+off TO <f> das Sonderverhalten, daß die Feldlänge und nicht die Restlänge von feld genommen wurde, wenn nur ein Offset, aber keine Länge angegeben wurde. Somit ist ein ASSIGN mit feldübergreifendem Offset unter Unicode problematisch und es gelten daher für diese Konstellation folgende Regeln: 1. Mit ASSIGN feld+off(*)... kann weiterhin explizit die Restlänge

spezifiziert werden.

2. ASSIGN <f>+off TO <g> ist nur noch dann erlaubt, wenn der Laufzeit-Typ von <f> flach und elementar ist, also C, N, D, T (Offset in Zeichen) oder X (Offset in Bytes).

3. ASSIGN feld+off TO <g> wird generell syntaktisch verboten, weil hier jeder Offset <> 0 eine Range-Überschreitung bewirken würde. Davon ausgenommen sind Fälle, bei denen ein RANGE-Zusatz angegeben ist.

Mit diesen Regeln ist normalerweise das Weiterschalten eines Feldsymbols mittels ASSIGN <f>+n TO <f> über ein elementares Feld, wie es zum Beispiel in einer Schleife vorkommt, auch in Zukunft möglich.

11

4.3 Zuweisungen Dieser Abschnitt behandelt impizite und explizite Typkonvertierungen mit dem Gleichheitszeichen (=) oder der Anweisung MOVE. Zwei Felder sind konvertibel, wenn der Inhalt des einen Feldes dem zweiten zugewiesen werden kann, ohne einen Laufzeitfehler auszulösen. Bei der Konvertierung zwischen strukturierten Feldern beziehungsweise zwischen einem strukturierten Feld und einem Einzelfeld wurden flache Strukturen bisher wie C-Felder behandelt. Dies ist mit der Einführung von Unicode zu fehleranfällig geworden, da unsicher ist, ob Programme mit plattformunabhängiger Semantik ablauffähig sind. Zwei Felder sind kompatibel, wenn sie in Typ und Länge gleich sind. Bei der Zuweisung von tiefen Strukturen müssen deshalb die Fragmentsichten übereinstimmen. Bei Zuweisung und Vergleich von tiefen Strukturen wurde bisher schon gefordert, daß Typkompatibilität zwischen den Operanden besteht, womit beide Operanden strukturell gleich aufgebaut sein müssen. Diese Forderung wird auch für Unicode-Systeme beibehalten.

�� Konvertierung zwischen flachen Strukturen

Zur Überprüfung, ob die Konvertierung überhaupt erlaubt ist, wird zunächst die Unicode-Fragmentsicht der Strukturen gebildet, indem zeichen- und byteartige Gruppen sowie Alignment-Lücken und sonstige Komponenten zusammengefaßt werden. Wenn die Fragmente von Quell- und Zielstruktur mit Typ und Länge in der Länge der kürzeren Struktur übereinstimmen, ist die Konvertierung erlaubt. Die Zuweisung ist ebenfalls unter folgenden Annahmen zulässig:

1. Beide Strukturen stimmen in allen Fragmenten bis zum vorletzten der

kürzeren Struktur überein. 2. Das letzte Fragment der kürzeren Struktur ist eine zeichen- oder byteartige

Gruppe. 3. Das korrespondierende Fragment der längeren Struktur ist eine zeichen- oder

byteartige Gruppe größerer Länge. Wenn die Zielstruktur länger als die Quellstruktur ist, werden die zeichenartigen Komponenten des Rests mit Leerzeichen gefüllt. Alle anderen Komponenten des Rests werden mit dem typgerechten Initialwert, Alignment-Lücken mit Null-Bytes gefüllt. Da längere Strukturen bisher generell mit Leerzeichen aufgefüllt wurden, ist die Verwendung von Initialwerten bei nicht zeichenartigen Komponententypen inkompatibel. Diese inkompatible Änderung hat allerdings eher den Charakter einer Fehlerkorrektur. Bei zeichenartigen Komponenten wurde aus Gründen der Kompatibilität darauf verzichtet, mit Initialwerten aufzufüllen. BEGIN OF struc1, BEGIN OF struc2, a(1) TYPE C, a(1) TYPE C, x(1) TYPE X, b(1) TYPE C, END OF struc1. END OF struc2.

12

Die Zuweisung struc1 = struc2 ist unter Unicode nicht erlaubt, weil struc1-x im Gegensatz zu struc2-b nur ein Byte belegt.

BEGIN OF struc3, BEGIN OF struc4, a(2) TYPE C, a(8) TYPE C, n(6) TYPE N, i TYPE I,

i TYPE I, f TYPE F, END OF struc3. END OF struc4.

Diese Zuweisung struc3 = struc4 ist zulässig, weil die Fragmentsichten der zeichenartigen Felder und der Integerzahl übereinstimmen.

BEGIN OF struc5, BEGIN OF struc6, a(1) TYPE X, a(1) TYPE X, b(1) TYPE X, BEGIN OF struc0,

c(1) TYPE C, b(1) TYPE X, END OF struc5. c(1) TYPE C, END OF struc0, END OF struc6.

struc5 = struc6 ist wiederum verboten, weil die Fragmentsichten der beiden Strukturen durch die Alignment-Lücken vor struc0 und vor struc0-c abweichen.

BEGIN OF struc7, BEGIN OF struc8, p(8) TYPE P, p(8) TYPE P, c(1) TYPE C, c(5) TYPE C, END OF struc7. o(8) TYPE P, END OF struc8.

Die Zuweisung struc7 = struc8 funktioniert, weil die Fragmentsichten in der Länge der Struktur struc7 übereinstimmen.

Bei tiefen Strukturen wird wie bisher die Typkompatibilität der Operanden gefordert. Als Abrundungsmaßnahme wurde die Konvertibilität bei Objekt-Referenzen und Tabellenkomponenten leicht verallgemeinert.

�� Konvertierung zwischen Strukturen und Einzelfeldern

Für die Konvertierung einer Struktur in ein Einzelfeld und umgekehrt gelten folgende Regeln:

1. Ist eine Struktur rein zeichenartig, dann wird sie bei der Konvertierung wie ein C-Feld behandelt.

2. Ist das Einzelfeld vom Typ C, die Struktur aber nur zum Teil zeichenartig, dann ist die Konvertierung nur erlaubt, wenn die Struktur mit einer zeichenartigen Gruppe beginnt und diese Gruppe mindestens so lang wie das Einzelfeld ist. Die Konvertierung erfolgt nun zwischen der ersten zeichenartigen Gruppe der Struktur und dem Einzelfeld. Wenn die Struktur das Zielfeld ist, werden die zeichenartigen Anteile des Rests mit Leerzeichen und alle anderen Komponenten mit dem typgerechten Initialwert aufgefüllt.

3. Die Konvertierung ist verboten, wenn die Struktur nicht rein zeichenartig und das Einzelfeld nicht vom Typ C ist.

Analog zur Zuweisung zwischen Strukturen ist das Auffüllen nicht zeichenartiger Komponenten mit dem Initialwert inkompatibel.

13

�� Konvertierung zwischen internen Tabellen

Tabellen sind dann konvertierbar, wenn ihre Zeilentypen konvertierbar sind. Die oben beschriebenen Restriktionen wirken sich somit auch auf die Konvertierung von Tabellen aus.

�� Implizite Konvertierungen

Für alle ABAP-Anweisungen, die implizite Konvertierungen entsprechend der MOVE-Semantik verwenden, gelten ebenfalls die obigen Regeln. Dies ist zum Beispiel bei folgenden Anweisungen für interne Tabellen der Fall: APPEND wa TO itab. APPEND LINES OF itab1 TO itab2.

INSERT wa INTO itab. INSERT LINES OF itab1 INTO [TABLE] itab2.

MODIFY itab FROM wa. MODIFY itab ... TRANSPORTING ... WHERE ... ki = vi ...

READ TABLE itab ...INTO wa. READ TABLE itab ...WITH KEY ...ki = vi ... LOOP AT itab INTO wa. LOOP AT itab .... WITH KEY ... ki = vi ... Die selben Einschränkungen wie bei der expliziten Konvertierung gelten auch für die implizite Umwandlung von VALUE-Angaben.

4.4 Vergleiche

Prinzipiell gilt die Regel, daß Operanden, die einander mit der MOVE-Anweisung zugewiesen werden können, auch miteinander vergleichbar sind. Abweichend davon sind Objektreferenzen zwar vergleichbar, jedoch nicht immer zuweisbar.

�� Vergleiche zwischen flachen Strukturen

Ein Vergleich ist auch dann möglich, wenn die Strukturen nicht kompatibel sind. Es muß aber analog zu MOVE gelten, daß die Fragmentsichten in der Länge der kürzeren Struktur übereinstimmen. Sind die Strukturen verschieden lang, dann wird die kürzere Struktur bis zur Länge der anderen Struktur aufgefüllt. Analog wie bei der Zuweisung werden beim Auffüllen alle zeichenartigen Komponenten mit Leerzeichen und alle anderen Komponenten mit typgerechtem Initialwert gefüllt. Der Vergleich erfolgt fragmentweise entsprechend der Fragmentsicht.

�� Vergleiche zwischen Einzelfeldern und Strukturen

Bei Vergleichen zwischen Einzelfeldern und Strukturen gelten folgende Regeln:

1. Wenn eine Struktur rein zeichenartig ist, wird sie beim Vergleich wie ein C-Feld behandelt.

2. Ist das Einzelfeld vom Typ C, die Struktur aber nur zum Teil zeichenartig, dann ist der Vergleich nur erlaubt, wenn die erste zeichenartige Gruppe der Struktur länger als das Einzelfeld ist. Für den Vergleich wird das Einzelfeld zur Laufzeit auf die Länge der Struktur erweitert und mit Initialwerten

14

aufgefüllt. Der Vergleich erfolgt dann wie bei strukturierten Feldern, wobei das Auffüllen selbst analog der MOVE-Anweisung vorgenommen wird.

c0(10) TYPE C. c0 0 BEGIN OF struc, c1(15) TYPE C, i TYPE I, c2(5) TYPE C, c1 i c2 n n(7) TYPE N, END OF struc. In diesem Beispiel wird c0 im Speicher auf die Länge von struc erweitert. Alle Bereiche > 10 werden bei nicht zeichenartigen Komponenten mit typgerechten Initialwerten belegt, ansonsten mit Leerzeichen.

�� Vergleich zwischen tiefen Strukturen

Wie bisher wird bei tiefen Strukturen für den Vergleich im wesentlichen die Typkompatibilität der Operanden gefordert. Der Kompatibilitätstest für die Vergleichbarkeit wurde zur Abrundung dahingehend verallgemeinert, daß analog zu Einzelfeldern Strukturkomponenten mit Referenzen auf Klassen oder Interfaces unabhängig von Klassenhierarchie und Implementierungsrelation miteinander vergleichbar sind. Bei Tabellenkomponenten wird nur die Vergleichbarkeit der Tabellentypen gefordert.

�� Vergleich zwischen internen Tabellen

Tabellen sind dann vergleichbar, wenn ihre Zeilentypen vergleichbar sind. Die oben beschriebenen Restriktionen wirken sich somit auch auf den Vergleich von Tabellen aus.

4.5 Verarbeitung von Zeichenketten Die Zeichenkettenverarbeitung, bei der bisher alle Argumente implizit als Feld vom Typ C interpretiert wurden, wird aufgeteilt in Stringverarbeitung für zeichenartige und byteartige Argumente.

�� Anweisungen zur Zeichenkettenverarbeitung

CLEAR ... WITH CONCATENATE CONDENSE CONVERT TEXT ... INTO SORTABLE CODE OVERLAY REPLACE SEARCH SHIFT SPLIT TRANSLATE ... TO UPPER/LOWER CASE TRANSLATE ... USING

Bei diesen Anweisungen müssen die Argumente Einzelfelder der Typen C, N, D, T oder STRING sein, zudem sind rein zeichenartige Strukturen erlaubt. Werden

15

Argumente eines anderen Typs übergeben, so wird ein Syntax- oder Laufzeitfehler ausgelöst. Für die Verarbeitung von Bytefolgen, also Operanden des Typs X oder X-STRING, wird eine Teilmenge dieser Funktionalität durch den Zusatz IN BYTE MODE bereitgestellt. Eine Anweisung CONCATENATE a x b INTO c ist genau dann nicht mehr möglich, wenn a, b, c zeichenartig sind, x jedoch vom Typ X.

TRANSLATE ... CODEPAGE ... TRANSLATE ... NUMBER FORMAT ...

Diese Anweisungen sind in UP verboten. Als Ersatz werden die neuen Konvertierungsklassen angeboten, die auf Seite 37 näher beschrieben sind.

�� Vergleichsoperatoren für die Zeichenkettenverarbeitung

CO CN CA NA CS NS CP NP Wie bei den Anweisungen zur Stringverarbeitung erfordern diese Operatoren Einzelfelder der Typen C, N, D, T oder STRING als Argumente, außerdem sind wiederum rein zeichenartige Strukturen zugelassen. Für Bytefolgen werden eigene Vergleichsoperatoren angeboten, die durch das Präfix BYTE- definiert werden.

�� Funktionen zur Stringverarbeitung

Die Funktion STRLEN arbeitet nur mit zeichenartigen Feldern und liefert die Länge in Zeichen zurück. Für die Länge von Bytefolgen steht die neue Funktion XSTRLEN zur Verfügung. Die Funktion CHARLEN lieferte unter NUS bisher den Wert 1 für ein Textfeld, das mit einem Single-Byte-Zeichen beginnt. Für ein Textfeld, das mit einem Double-Byte-Zeichen beginnt, wird der Wert 2 zurückgeliefert. Unter US wird CHARLEN den Wert 1 liefern, falls text mit einem einfachen Unicode-Zeichen beginnt. Falls text mit einem Unicode-Doppelzeichen aus der Surrogate Area beginnt, wird 2 zurückgeliefert. Die Funktion NUMOFCHAR liefert die Anzahl der Zeichen eines Strings oder eines zeichenartigen Feldes. In Single-Byte Codepages verhält sich diese Funktion wie STRLEN. In Multi-Byte Codepages werden Zeichen, die mehr als 1 Byte belegen, trotzdem mit der Länge 1 gezählt.

�� Ausgaben in Felder und Listen

Bei WRITE ... TO waren beliebige flache Datentypen als Ziel erlaubt, die wie C-Felder behandelt wurden. In UP gilt nun für WRITE ... TO ... die Einschränkung, daß das Zielfeld zeichenartig sein muß. Bei der Tabellenvariante WRITE ... TO

16

itab INDEX idx muß der Zeilentyp der Tabelle zeichenartig sein. Offset und Längenangaben werden dabei zeichenweise gezählt.

Mit WRITE konnten bisher beliebige flache Strukturen ausgegeben werden. Wenn das Quellfeld bei WRITE eine flache Struktur Ist, dann muß diese in UP rein zeichenartig sein. Folgende Anweisungen sind davon betroffen:

WRITE f.

WRITE f TO g[+off][(len)].

WRITE (name) TO g.

WRITE f TO itab[+off][(len)] INDEX idx.

WRITE (name) TO itab[+off][(len)] INDEX idx.

4.6 Typprüfung und Typkompatibilität Aus historischen Gründen können Feldsymbole und Parameter von Unterprogrammen oder Funktionsbausteinen mit dem Zusatz STRUCTURE typisiert werden. �� Wenn Feldsymbole mit FIELD-SYMBOLS <f> STRUCTURE s DEFAULT wa

typisiert sind und ihnen später mit ASSIGN wa TO <f> ... ein Datenobjekt wa zugewiesen wird, dann wird in NUP in beiden Anweisungen nur geprüft, ob wa mindestens so lang wie s ist und wa die Ausrichtungsanforderungen von s zur Laufzeit erfüllt.

Wenn Parameter in Funktionsbausteinen oder Unterprogrammen mit FORM form1 USING/CHANGING arg STRUCTURE s ... oder FORM form2 TABLES itab_a STRUCTURE s ... typisiert sind und ihnen mit PERFORM form1 USING/CHANGING wa oder PERFORM form2 USING/CHANGING itab_b Aktualparameter übergeben werden, wird in NUP ebenfalls nur geprüft, ob wa oder der Zeilentyp von itab_b mindestens so lang wie s ist und wa beziehungsweise der Zeilentyp von itab_b die Ausrichtungsanforderungen von s erfüllt. Das Gleiche gilt für Parameter von Funktionsbausteinen, die mit STRUCTURE typisiert sind.

In UP werden nach einer Typisierung mit STRUCTURE bei einer Zuweisung von Datenobjekten, also beim DEFAULT-Zusatz der Anweisung FIELD-SYMBOLS, beim ASSIGN und bei der Übergabe von Aktualparametern folgende zusätzliche Regeln überprüft:

1. Ist wa beziehungsweise der Zeilentyp von itab_b eine flache oder tiefe Struktur, dann müssen die Unicode-Fragmentsichten von wa beziehungsweise von itab_b und s in der Länge von s übereinstimmen.

2. Ist wa ein Einzelfeld, dann sind nur die zeichenartigen Typen C, N, D oder T erlaubt und die Struktur s muß rein zeichenartig sein.

Die Überprüfung dieser beiden Regeln erfordert zusätzliche Laufzeit. Deshalb wird empfohlen, die Parameter nach Möglichkeit mit TYPE zu typisieren, weil der Test auf echte Kompatibilität ungleich schneller ist.

17

�� Wurde bei einem Funktionsbaustein ein Argument mit ... LIKE struc typisiert, wobei struc eine flache Struktur ist, so wird in NUP bei der Parameterübergabe nur geprüft, ob das Argument eine flache Struktur gleicher Länge ist. In UP wird zusätzlich geprüft, daß die Fragmentsichten des aktuellen und formalen Parameters übereinstimmen. Aus Performancegründen wird wie im Abschnitt zuvor die Typisierung mit TYPE empfohlen.

�� Außerdem sind zwei Strukturen, von denen eine oder beide Includes enthalten, nur noch dann kompatibel, wenn die durch Include verursachten Alignment-Lücken auf allen Plattformen übereinstimmen. Im folgenden Beispiel sind struc1 und struc2 nicht zueinander kompatibel, weil vor dem INCLUDE im US eine zusätzliche Alignment-Lücke auftritt: BEGIN OF struc1, BEGIN OF struc2, BEGIN OF struc3, a(1) TYPE X, a(1) TYPE X. b(1) TYPE X, b(1) TYPE X, INCUDE struc3. c(1) TYPE C, c(1) TYPE C, END OF struc2. END OF struc3. END OF struc1.

Da sich die Typkompatibilität in UP und NUP unterscheiden kann, gelten in NUS für die Prüfung der Parameter stets die Typkompatibilitätsregeln des Aufrufers. Ruft also ein NUP ein UP auf, dann wird die Typkompatibilität wie im NUP bestimmt. Umgekehrt wird die Unicode-Prüfung eingeschaltet, wenn ein UP ein NUP aufruft.

4.7 Änderungen bei Datenbank-Operationen Bei den nachfolgenden Anweisungen werden bisher in NUP die Daten entsprechend der Struktur des Tabellenarbeitsbereichs dbtab in das Feld wa beziehungsweise in die Tabellenzeile itab übertragen, ohne die Struktur derselben zu berücksichtigen. Allein die Länge und die Ausrichtung werden geprüft. SELECT * FROM dbtab ... INTO wa ... SELECT * FROM dbtab ... INTO TABLE itab ... SELECT * FROM dbtab ... APPENDING TABLE itab ...

FETCH NEXT CURSOR c ... INTO wa. FETCH NEXT CURSOR c ... INTO TABLE itab. FETCH NEXT CURSOR c ... APPENDING TABLE itab.

INSERT INTO dbtab ... FROM wa. INSERT dbtab ... FROM wa. INSERT dbtab ... FROM TABLE itab.

UPDATE dbtab ... FROM wa. UPDATE dbtab ... FROM TABLE itab.

MODIFY dbtab ... FROM wa. MODIFY dbtab ... FROM TABLE itab.

DELETE dbtab FROM wa. DELETE dbtab FROM TABLE itab. In UP gelten nun folgende Regelungen: Ist der Arbeitsbereich beziehungsweise die Zeile der internen Tabelle eine Struktur, dann wird zusätzlich geprüft, ob die Fragmentsichten von Arbeitsbereich und

18

Datenbanktabelle in der Länge der Datenbanktabelle übereinstimmen. Ist der Arbeitsbereich ein Einzelfeld, so muß das Feld zeichenartig und die Datenbanktabelle rein zeichenartig sein. Diese Anforderungen gelten für alle oben aufgeführten Anweisungen.

Bei allen Anweisungen zum Bearbeiten von Datenbanktabellen (READ, MODIFY, DELETE, LOOP), die den Zusatz VERSION verwenden, sind für das Versionsfeld nur noch die Typen C, N, D, T und flache Strukturen derselben Typen zulässig. In NUS wird eine Warnung, in US ein Syntaxfehler ausgelöst. 4.8 Längen- und Abstandsermittlung

Bei der Längen und Abstandsermittlung von Feldern darf die Anweisung DESCRIBE DISTANCE nicht mehr verwendet werden und muß durch eine der neuen Anweisungen DESCRIBE DISTANCE ... IN BYTE MODE oder DESCRIBE DISTANCE ... IN CHARACTERMODE ersetzt werden.

Auch die Anweisung DESCRIBE FIELD ... LENGTH ist obsolet und muß durch eine der neuen Anweisungen DESCRIBE FIELD ... LENGTH ... IN BYTE MODE oder DESCRIBE FIELD ... LENGTH ... IN CHARACTER MODE ersetzt werden.

Die Anweisung DESCRIBE FIELD ... TYPE feld lieferte bisher für flache Strukturen den Typ C zurück. In Unicode-Programmen wird für flache Strukturen jetzt der Typ u zurückgegeben, der im ABAP-Quellcode abgefragt werden kann.

Für die Anweisung DESCRIBE FIELD ... TYPE ... COMPONENTS ... ergeben sich unter Unicode-Systemen keine Änderungen. Ebenfalls unverändert liefert die Anweisung DESCRIBE ... OUTPUT LENGTH ... weiterhin die Ausgabelänge in Zeichen zurück.

4.9 Sonstige Änderungen

Die folgenden Ausführungen betreffen die Dateischnittstelle, Schlüsselangaben bei Tabellen sowie Bit- und Bitmaskenoperationen. Im einzelnen ergeben sich durch die Einführung von Unicode folgende Änderungen:

�� In der Dateischnittstelle wurde der Befehl OPEN DATASET völlig überarbeitet. In UP muß mindestens einer der Zusätze IN TEXT MODE ENCODING, IN BINARY MODE, IN LEGACY MODE oder IN LEGACY BINARY MODE angegeben werden.

Das Lesen und Schreiben von Dateien mittels READ DATASET und TRANSFER kann in US nur noch vorgenommen werden, wenn die zu bearbeitende Datei zuvor explizit geöffnet wurde. Ohne OPEN-Anweisung wird bei diesen Anweisungen ein Laufzeitfehler ausgelöst.

Wurde die Datei im TEXT MODE geöffnet, sind bei READ DATASET dsn INTO f für f nur zeichenartige Felder, Strings und rein zeichenartige Strukturen erlaubt, wobei die Typprüfung erst zur Laufzeit erfolgt.

Der Zusatz LENGTH bestimmt im TEXT MODE die Länge des Datensatzes in Zeichen, in allen anderen Fällen in Bytes.

19

�� Bei den obsoleten Anweisungen LOOP AT dbtab, READ TABLE dbtab und READ TABLE itab wird in UP ein Syntaxfehler ausgelöst, wenn der Schlüssel nicht rein zeichenartig ist.

Bei der Anweisung READ TABLE itab wird ein Syntax- oder Laufzeitfehler ausgelöst, wenn der Standardschlüssel der internen Tabelle die Typen X oder XSTRING enthält. Bei dieser READ-Variante wird der tatsächlich zu verwendende Schlüssel durch Ausblenden aller mit Leerzeichen gefüllten Komponenten ermittelt. Dazu muß in UP sichergestellt sein, daß der Vergleich mit SPACE erlaubt ist.

Ein Syntax- oder Laufzeitfehler wird auch bei Datenbankzugriffen mit generischem Schlüssel ausgelöst, wenn der Schlüssel nicht rein zeichenartig ist. Davon betroffen sind folgende Befehle:

READ TABLE dbtab ...SEARCH GKEQ ... READ TABLE dbtab ...SEARCH GKGE ... LOOP AT dbtab ... REFRESH itab FROM TABLE dbtab.

Bei diesen Anweisungen wird der tatsächliche Tabellenschlüssel dadurch ermittelt, daß schließende Leerzeichen des Datenbankschlüssel abgeschnitten werden. Dazu muß in UP sichergestellt sein, daß alle Bestandteile des Schlüssels mit SPACE verglichen werden können.

�� Bisher wurde bei den Bitanweisungen SET BIT i OF f [TO g] und GET BIT i OF f [INTO g] geprüft, ob das Feld f zeichenartig ist, wobei üblicherweise auch X-Felder, X-Strings und flache Strukturen als zeichenartig betrachtet wurden. Für UP ist dies nicht mehr sinnvoll, da einerseits die Typen X und XSTRING nicht mehr als zeichenartig gelten, anderseits der bitweise Zugriff auf zeichenartige Felder oder Strukturen nicht mehr unabhängig von der Plattform ist. Deshalb muß bei diesen Operationen in UP das Feld f vom Typ X oder XSTRING sein.

Bei den Bitmaskenoperationen f O x, f Z x und f M x waren bisher für den linken Operanden f alle zahlartigen und damit auch alle characterartigen Typen erlaubt. In UP muß der Operand f nun den Typ X oder XSTRING haben.

�� Bei der Addition von Feldfolgen sind in UP Einschränkungen für folgende Anweisungen verbindlich:

ADD n1 THEN n2 UNTIL nz [ ACCORDING TO sel ] GIVING m ... ADD n1 THEN n2 UNTIL nz TO m [ RANGE str ].

1. Die Operanden n1, n2 und nz müssen zueinander typkompatibel sein. 2. Die Distanz zwischen nz und n1 muß ein ganzzahliges Vielfaches der Distanz

zwischen n2 und n1 sein. 3. Ein Syntax- oder Laufzeitfehler erfolgt, wenn die Felder n1, n2 und nz nicht

in einer Struktur liegen. Diese muß entweder statisch erkennbar sein oder deren zulässiger Bereich explizit durch den RANGE-Zusatz gekennzeichnet werden.

4. Zur Laufzeit wird sichergestellt, daß der RANGE-Bereich nicht verlassen wird.

20

ADD n1 FROM i1 GIVING m [ RANGE str ].

1. Feld n1 muß innerhalb einer Struktur liegen. Diese muß durch den RANGE-Zusatz explizit definiert werden, falls dies statisch nicht erkennbar ist.

2. Auch bei dieser Variante wird zur Laufzeit geprüft, ob n1 und die angesprochenen Werte innerhalb der Struktur liegen.

�� Schleifen mit dem Zusatz VARY oder VARYING sind auch für Unicode problematisch, weil einerseits ein typgerechter Zugriff auf Speicherinhalte nicht sichergestellt ist, andererseits Seicher ungewollt überschrieben werden kann.

DO ... VARYING f FROM f1 NEXT f2.

Bei dieser Anweisung müssen die Felder f, f1 und f2 zueinander typkompatibel sein. Um das Überschreiben von Speicherinhalten zu verhindern, wird bei den folgenden Anweisungen implizit oder explizit ein RANGE für zulässige Zugriffe eingeführt:

DO ... TIMES VARYING f FROM f1 NEXT f2 [ RANGE f3 ].

WHILE ... VARY f FROM f1 NEXT f2 [ RANGE f3 ].

Es wird wiederum ein Syntax- oder Laufzeitfehler ausgelöst, falls f1 oder f2 nicht von f3 umfaßt werden. Fehlt der Zusatz RANGE, dann wird dieser aus FROM f1 NEXT f2 implizit so bestmmt:

1. Sind sowohl f1 und f2 statisch erkennbare Komponenten der gleichen Struktur, dann wird der zulässige RANGE-Bereich aus der kleinsten Struktur bestimmt, die f1 und f2 umfaßt.

2. Ein Syntaxfehler wird ausgelöst, wenn statisch erkennbar ist, daß f1 und f2 nicht zur gleichen Struktur gehören.

3. Ein zulässiger Bereich muß explizit mittels RANGE angegeben werden, falls die Zusammengehörigkeit von f1 und f2 statisch nicht erkennbar ist.

Wird als RANGE-Zusatz eine tiefe Struktur angegeben, dann wird bei jedem Schleifendurchlauf geprüft, daß innerhalb des gerade überstrichenen Bereiches keine Feld- und Objektreferenzen, Tabellen oder Strings liegen.

�� Bei der automatischen Erzeugung von Unterprogrammen mittels Anweisung GENERATE SUBROUTINE POOL itab NAME name erbt das generierte Programm den Inhalt des Unicode-Flags des generierenden Programms.

�� Bei der Anweisung INSERT REPORT kann das Unicodeflag durch den Zusatz UNICODE ENABLING uc explizit zur Laufzeit gesetzt werden. Ohne diesen Zusatz wird folgendermaßen verfahren:

1. Ein UC-Programm erzeugt ebenfalls ein UC-Programm 2. Ein NUC-Programm erzeugt wiederum ein NUC-Programm 3. Ein NUC- wird ein UC-Programm nach Überschreiben durch ein UC-Programm 4. Ein UC- bleibt ein UC-Programm nach Überschreiben durch ein NUC-

Programm

21

�� Bei den Anweisungen GET/SET PARAMETER ID pid FIELD f muß f zeichenartig sein. Für die Ablage nicht zeichenartiger Felder und Strukturen können EXPORT- und IMPORT-Anweisungen benutzt werden

5. Neue ABAP-Anweisungen für Unicode 5.1 Stringverarbeitung für Bytefolgen �� Die String-Anweisungen für die Typen X und XSTRINGG werden durch den Zusatz

IN BYTE MODE von den Zeichenkettenbefehlen unterschieden. Für die Varianten der Zeichenketten ist optional der Zusatz IN CHARACTER MODE möglich.

Ist der Zusatz IN BYTE MODE angegeben, sind als Argumente nur X-Felder und X-Strings erlaubt. Werden Argumente eines anderen Typs übergeben, so wird ein Syntax- oder ein Laufzeitfehler ausgelöst.

CLEAR ... WITH IN BYTE MODE

CONCATENATE x1 ... xn INTO x IN BYTE MODE

FIND ... IN BYTE MODE

REPLACE ... IN BYTE MODE

REPLACE f WITH g INTO h IN BYTE MODE

SEARCH x FOR x1 IN BYTE MODE

SHIFT x ... IN BYTE MODE

SPLIT ... IN BYTE MODE

Bei allen String-Befehlen für Bytefolgen werden X-Felder immer in ihrer vollen Länge berücksichtigt, so daß Bytes mit Inhalt X'00' am Ende des Feldes niemals abgeschnitten werden. Für die Anweisungen FIND, SEARCH und REPLACE mit Zusatz IN BYTE MODE gibt es keine Varianten, die Suchmuster verwenden.

�� Die Stringlänge für Bytefolgen kann mit der Funktion XSTRLEN bestimmt werden. XSTRLEN liefert für X-Strings die aktuelle Länge und für X-Felder die definierte Länge in Bytes, wobei Nullbytes am Ende von Feldern mitgezählt werden.

�� Die X-Varianten der Stringvergleichsoperationen werden durch das Präfix BYTE- von den Zeichenkettenvarianten unterschieden. Als Argumente sind für diese Operationen nur X-Felder und Felder vom Typ XSTRING erlaubt.

BYTE-CO

BYTE-CN

BYTE-CA

BYTE-NA

BYTE-CS

BYTE-NS

22

5.2 Längen- und Abstandsermittlung

Mit den Anweisungen DESCRIBE FIELD und DESCRIBE DISTANCE kann die Feldlänge oder der Abstand zwischen zwei Feldern ermittelt werden. Bei folgenden Varianten müssen unter Unicode die Zusätze IN BYTE/CHARACTER MODE angegeben werden:

�� DESCRIBE FIELD f LENGTH len IN BYTE MODE.

Die Länge des Feldes f wird in Bytes ermittelt und in das Feld len übergeben.

Diese Variante liefert für alle intern referenzierten Datentypen (Strings, Feld- und Objektreferenzen) die Länge der Referenz und nicht die Länge des Inhalts. Für derartige Felder ist deshalb nur die Variante IN BYTE MODE erlaubt.

�� DESCRIBE FIELD f LENGTH len IN CHARACTER MODE.

Hier wird die Länge des Feldes f in Zeichen zurückgegeben, falls das Argument rein zeichenartig ist. f darf jedoch nicht vom Typ STRING sein. Die betreffende Prüfung wird statisch und dynamisch durchgeführt und löst je nach Typ einen Syntax- oder Laufzeitfehler aus.

�� DESCRIBE DISTANCE BETWEEN a AND b INTO x IN BYTE MODE.

Diese Anweisung liefert im Feld x den Abstand zwischen den Feldern a und b in Bytes.

�� DESCRIBE DISTANCE BETWEEN a AND b INTO x IN CHARACTER MODE.

Diese Anweisung liefert den Abstand in Zeichen zurück, wobei das Ergebnis stets auf die Feldanfänge bezogen ist. Nur zur Laufzeit wird geprüft, ob der Abstand zwischen den Argumenten durch die plattformabhängige Länge eines Zeichens teilbar ist und die beiden Felder a und b das richtige Alignment besitzen. Anderenfalls wird ein Laufzeitfehler ausgelöst.

5.3 Zuweisungen an Feldsymbole

Die ASSIGN-Anweisung erlaubte es bisher, mit Offset/Längenangaben über Feldgrenzen hinaus zu adressieren. Einen Laufzeitfehler gab es nur dann, wenn über die Grenzen des Datensegments hinaus adressiert wurde. Feldübergreifende Offset/Längenzugriffe bei ASSIGN konnten beispielsweise sinnvoll zur Bearbeitung von Wiederholungsgruppen eingesetzt werden. Mit Unicode ist dies allerdings problematisch, da nicht mehr sichergestellt ist, daß feldüberschreitende Offset- oder Längenangaben sowohl unter US als auch in NUS einheitlich und sinnvoll als Bytes oder Zeichen interpretiert werden können. Aus diesem Grund wurde die ASSIGN-Anweisung um die Zusätze RANGE und INCREMENT erweitert, während der Zusatz CASTING nunmehr alle Varianten dieser Anweisung unterstützt. Der RANGE-Zusatz wird für alle gültigen Varianten von ASSIGN angeboten und kann mit dem Zusatz CASTING kombiniert werden.

23

�� ASSIGN feld1 TO <fs> RANGE feld2.

Dieser Zusatz setzt explizit die Range-Grenzen. Dadurch ist es möglich, über Feldgrenzen hinaus zu adressieren, um beispielsweise mit der Anweisung ASSIGN INCREMENT Wiederholungsgruppen zu verarbeiten.

1. Als Range für <fs> werden die Feldgrenzen von feld2 genommen.

2. In UP müssen die durch die RANGE-Angabe spezifizierten Grenzen die Range-Grenzen umfassen, die sich sonst nach den oben beschriebenen Regeln ergeben würden.

3. Ist der Speicherbereich von feld1 nicht ganz in feld2 enthalten, so wird ein abfangbarer Laufzeitfehler ausgelöst.

4. Das Feld feld2, das den Range bestimmt, darf auch tief sein. Es können somit auch Wiederholungsgruppen mit tiefen Typen verarbeitet werden.

�� ASSIGN feld INCREMENT n TO <fs>.

Das Feldsymbol wird ausgehend von der durch feld bestimmten Position um n mal die Länge von feld weitergesetzt.

Zunächst wird aus der Länge von feld und der INCREMENT-Angabe der Bereich für den Zugriff entsprechend ASSIGN fld+n*sizeof[feld] (sizeof[fld]) TO <fs> bestimmt. Der angesprochene Bereich muß innerhalb der Range-Grenzen liegen. Kann die Zuweisung nicht durchgeführt werden, weil die Range-Grenzen verletzt wurden, so wird SY-SUBRC > 0 gesetzt und das Feldsymbol bleibt unverändert. Die Range-Grenzen für ASSIGN feld INCREMENT n TO <fs> werden genau so wie bei ASSGIN feld TO <f> bestimmt. Die INCREMENT-Angabe hat daher keinen Einfluß auf die Bestimmung der Range-Grenzen. * Schleife über ein elementares Feld

DATA: c(10) TYPE C VALUE 'abcdefghij'. FIELD-SYMBOLS: <cf> TYPE C. ASSIGN c(2) TO <cf>. "Range-Grenzen c = DO 5 TIMES. "Feldgrenzen von cf WRITE / <cf>. ASSIGN <cf> INCREMENT 1 TO <c>. "Gleiche Grenzen <c> * ASSIGN <c>+2 TO <cf>. "Wie ASSIGN INCREMENT ENDDO.

* Strukturierte Wiederholungsgruppe TYPES: BEGIN OF comp, f1 type string, ... END OF comp. DATA: BEGIN OF stru, x1(1) TYPE x, k1 TYPE comp, k2 TYPE comp,

24

k3 TYPE comp, k4 TYPE comp, END OF stru. FIELD-SYMBOLS: <comp> TYPE comp. ASSIGN stru-k1 TO <comp> RANGE stru. * Range-Grenzen feldübergreifend festlegen DO 4 TIMES. ... ASSIGN <comp> INCREMENT 1 TO <comp>. ENDDO.

* Dynamischer Zugriff auf ein * Element einer Wiederholungsgruppe DATA: BEGIN OF stru, x1(1) TYPE x, k1 TYPE comp, k2 TYPE comp, k3 TYPE comp, k4 TYPE comp, END OF stru, incr TYPE i. FIELD-SYMBOLS: <comp> TYPE comp. incr = 4 - 1. ASSIGN stru-k1 INCREMENT incr TO <comp> RANGE stru. ... * <comp> steht jetzt auf stru-k4

�� Bei allen Varianten der Anweisung ASSIGN ist der Zusatz CASTING erlaubt:

ASSIGN feld TO <fs> CASTING.

ASSIGN feld TO <fs> CASTING TYPE type.

ASSIGN feld TO <fs> CASTING TYPE (typename)

ASSIGN feld TO <fs> CASTING LIKE fld.

ASSIGN feld TO <fs> CASTING DECIMALS dec.

Durch ASSIGN ... CASTING ist es möglich, den Inhalt eines Felds über ein Feldsymbol als einen Wert eines anderen Typs zu betrachten. Eine Anwendung dieser Anweisung besteht beispielsweise darin, durch Casts auf verschiedene Typen unterschiedliche Sichten auf eine Struktur zur Verfügung zu stellen.

Eine verbreitete ABAP-Technik besteht darin, C-Felder oder Strukturen als Container zum Speichern von Strukturen verschiedener, oft erst zur Laufzeit bekannter Typen zu verwenden. Die Selektion von Teilkomponenten der Struktur erfolgt dann durch Offset/Längenzugriffe auf den Container. Da diese Technik mit Unicode nicht mehr funktioniert, kann alternativ ein vorhandener Speicherbereich mittels ASSIGN ... CASTING über ein Feldsymbol als Container mit passender Typisierung betrachtet werden. Im nachfolgenden Beispiel wird ein bestimmtes Feld der Datenbanktabelle X031L gelesen, wobei Feld- und Tabellenname erst zur Laufzeit angegeben werden.

25

* Lesen eines Feldes der Tabelle X031L PARAMETERS: TAB_NAME LIKE SY-TNAME, "Tabellenname TAB_COMP LIKE X031L-FIELDNAME, "Feldname ANZAHL TYPE I DEFAULT 10. "Zeilenanzahl DATA:

BEGIN OF BUFFER, ALIGNMENT TYPE F, "Alignment C(8000) TYPE C, "Tabelleninhalt END OF BUFFER.

FIELD-SYMBOLS: <WA> TYPE ANY,

<COMP> TYPE ANY.

* Feldsymbol mit passender Typisierung * auf Pufferbereich setzen

ASSIGN BUFFER TO <WA> CASTING TYPE (TAB_NAME).

SELECT * FROM (TAB_NAME) INTO <WA> UP TO anzahl ROWS.

ASSIGN COMPONENT TAB_COMP OF STRUCTURE <WA> TO <COMP>. WRITE: / TAB_COMP, <COMP>. ENDSELECT.

In der Anweisung ASSIGN feld TO <f> CASTING ... wurde bisher geprüft, daß feld mindestens so lang ist wie der Typ, der dem Feldsymbol <f> zugeordnet ist, indem das Feldsymbol typisiert wurde oder durch eine direkte Typangabe mittels CASTING TYPE. Die bisher schon durchgeführte Längenprüfung wird im Syntaxcheck dahingehend verschärft, daß die Zuweisung nur noch erlaubt ist, wenn das Feld feld sowohl in einem US als auch in einem NUS mindestens so lang ist wie der Typ, der dem Feldsymbol <f> zugeordnet ist. Ist diese Bedingung verletzt, erfolgt ein Syntaxfehler. Zur Laufzeit wird dagegen wie bisher nur geprüft, ob die Längen im aktuellen System passen.

Ist der Typ von feld oder von <f> eine tiefe Struktur, dann wurde außerdem geprüft, ob alle referenzartigen Komponenten bezüglich Offset und Typ im Bereich von feld, der durch <f> überdeckt wird, übereinstimmen. Die Prüfung der referenzartigen Komponenten wird im Syntaxcheck dahingehend verschärft, daß diese auf allen Plattformen mit ein, zwei oder vier Byte langen Zeichen passen müssen. Zur Laufzeit wird wiederum nur geprüft, ob die Referenzkomponenten im aktuellen System passen.

Bei ASSIGN str TO <f> TYPE C/N und bei ASSIGN str TO <f> CASTING TYPE C/N kann in Unicode-Systemen außerdem der Fall auftreten, daß die Länge von str nicht ein Vielfaches der Zeichenlänge ist. In diesem Fall erfolgt ein Laufzeitabbruch.

26

5.4 Includes mit Gruppennamen Durch Redefinition von Strukturen unter Verwendung von INCLUDES mit Gruppen-namen ist es möglich, Teile komponentenübergreifend auf symbolische Weise zu selektieren. Neben der Vereinbarung im ABAP-Programm besteht auch die Möglichkeit, Gruppennamen im Dictionary zu vergeben. Folgende Ausprägungen sind im ABAP verfügbar:

INCLUDE TYPE t1 AS grpname[RENAMING WITH SUFFIX suffix].

INCLUDE STRUCTURE s1 AS grpname[RENAMING WITH SUFFIX suffix].

Durch die Einführung eines Gruppennamens für ein Include im DDIC oder durch den Zusatz AS grpname in ABAP kann der durch das Include definierte Teilbereich der Struktur symbolisch über den Gruppennamen angesprochen werden. Das folgende Beispiel faßt Teile einer ABAP-Struktur zu einer Gruppen zusammen, die an ein Unterprogramm übergeben wird: * Verwendung von Includes mit Gruppennamen

TYPES: BEGIN OF name, vorname(20) TYPE C, nachname(30) TYPE C, END OF name.

TYPES: BEGIN OF person, geschlecht(1) TYPE X. INCLUDE TYPE name AS pname. TYPES: alter TYPE I, gewicht TYPE P, END OF person. DATA: s2 TYPE person. PERFORM use_name USING s2-pname.

5.5 Dynamische Erzeugung von Datenobjekten �� Mittels CREATE DATA ist es möglich, Felder eines vor- oder benutzerdefinierten

Datentyps zu erzeugen. Folgende Varianten werden angeboten:

CREATE DATA dref TYPE typ.

CREATE DATA dref TYPE (typname).

CREATE DATA dref LIKE feld.

CREATE DATA dref TYPE LINE OF itab.

CREATE DATA dref LIKE LINE OF itab.

Im folgenden Beispiel wird wiederum ein bestimmtes Feld der Datenbanktabelle X031L gelesen, wobei Feld- und Tabellenname erst zur Laufzeit bekannt sind.

27

* Lesen eines Feldes der Tabelle X031L PARAMETERS: TAB_NAME LIKE SY-TNAME, "Tabellenname TAB_COMP LIKE X031L-FIELDNAME, "Feldname NUMBER TYPE I DEFAULT 10. "Zeilenanzahl FIELD-SYMBOLS: <WA> TYPE ANY, <COMP> TYPE ANY. DATA: WA_REF TYPE REF TO DATA. CREATE DATA WA_REF TYPE (TAB_NAME). "Passende Workarea ASSIGN WA_REF->* TO <WA>. SELECT * FROM (TAB_NAME) INTO <WA> UP TO NUMBER ROWS. ASSIGN COMPONENT TAB_COMP OF STRUCTURE <WA> TO <COMP>. WRITE: / TAB_COMP, <COMP>. ENDSELECT.

�� Mit einer weiteren Variante von CREATE DATA ist es möglich, zur Laufzeit Tabellenobjekte zu erzeugen. Zeilentyp und Schlüssel der Tabelle können dabei statisch oder dynamisch angegeben werden. CREATE DATA dref (TYPE [STANDARD|SORTED|HASHED] TABLE

OF (LineType | (Name) |REF TO DATA | REF TO Obj)) | (LIKE [STANDARD|SORTED|HASHED] TABLE OF LineObj )

[ WITH (UNIQUE|NON-UNIQUE) ( KEY (k1 ... kn | (keytab) | TABLE_LINE ) | DEFAULT KEY ) ]

[ INITIAL SIZE m ] Für diese Anweisung gelten die nachfolgende Einschränkungen:

1. m ist eine Variable oder eine Konstante ohne Vorzeichen, deren Inhalt zur Laufzeit vom Typ NUMLIKE sein muß.

2. keytab ist eine nicht leere Tabelle des Typs CHARLIKE, deren Komponenten keine Offset/Längen- oder überlappende Key-Angaben enthalten dürfen. Der Zusatz TABLE_LINE ist erlaubt, wenn die Tabelle nur eine Zeile enthält.

3. Ein Syntaxfehler erfolgt, wenn entweder die Typ- oder die Zeilen- und die Schlüsselangabe statisch sind.

4. Ist kein Schlüssel definiert, dann zieht der DEFAULT-KEY.

�� Bei CREATE DATA können auch die generischen Basistypen C, N, X und P

verwendet werden. Durch Zusätze kann die Länge und bei Typ P auch die Zahl der Dezimalstellen spezifiziert werden.

CREATE DATA dref TYPE (t | (typeName))

[ LENGTH len ] [ DECIMALS dec ].

Der Zusatz LENGTH ist nur bei den Typen C, N, X und P erlaubt und muß stets hinter dem Schlüsselwort TYPE stehen. Bei unsinniger Angabe von LENGTH oder DECIMALS wird ein abfangbarer Laufzeitfehler ausgelöst.

28

5.6 Dynamische Feldzuweisungen

Bisher galt bei MOVE-CORRESPONDING struc1 TO struc2 die Einschränkung, daß die Feldtypen der beiden Strukturen zum Zeitpunkt der Generierung bekannt sein mussten. Diese Einschränkung wird unter Unicode aufgehoben.

In NUS war die Zuweisung von Strukturen unterschiedlicher Fragmentsichten mittels MOVE bisher unproblematisch. Unter US führte eine solche Zuweisung jedoch trotz typgleicher Anfangsstücke zu einem Laufzeitfehler. BEGIN OF struc1, BEGIN OF struc2, a(2) TYPE C, a(2) TYPE C, b TYPE I, b TYPE I, c(1) TYPE C, c(1) TYPE C, d(4) TYPE X, g(6) TYPE P, END OF struc1. f(2) TYPE X, END OF struc2. struc1 a b c d

struc2 a b c g f Wurde struc1 = struc2 zum Beispiel durchgeführt, um struc1 den Inhalt des typgleichen Anfangsstückes struc2-[a,c] zuzuweisen, so genügte eine einfache MOVE-Anweisung, wobei das Reststück von struc1 nach der Zuweisung möglicherweise unsinnige Werte enthielt. Da dieselbe Zuweisung unter Unicode aber wegen der unterschiedlichen Fragmentsichten zu einem Laufzeitfehler führt, kann nun ersatzweise mit MOVE-CORRESPONDING struc2 TO struc1 gearbeitet werden. Dasselbe Ergebnis wird unter Unicode genau dann erzielt, wenn die Feldnamen der Anfangsstücke zur Laufzeit in beiden Strukturen namensgleich sind. 5.7 Ablage von Daten als Cluster Zur Unterstützung heterogener Unicode-Umgebungen werden neue Varianten der IMPORT- und EXPORT-Anweisung angeboten. Diese erlauben es, Daten unabhängig vom Format der Plattform als Cluster in einem X-String abzulegen. Folgende Varianten können benutzt werden:

�� EXPORT {pi = dobji | pi FROM dobji } TO DATA BUFFER dbuf.

EXPORT (itab) TO DATA BUFFER dbuf.

Die Objekte dobj1 ... dobjn (Felder, flache und komplexe Strukturen oder Tabellen) werden als ein Cluster im Datenpuffer dbuf abgelegt, der vom Typ XSTRING sein muß.

TYPES: BEGIN OF ITAB_TYPE, CONT TYPE C LENGTH 4, END OF ITAB_TYPE.

29

DATA: XSTR TYPE XSTRING, F1 TYPE C LENGTH 4, F2 TYPE P, ITAB TYPE STANDARD TABLE OF ITAB_TYPE. EXPORT P1 = F1 P2 = F2 TAB = ITAB TO DATA BUFFER XSTR.

�� Neuer Zusatz ... CODE PAGE HINT f1

Mit diesem Zusatz kann für EXPORT obj1 ... objn TO [ DATA BUFFER | DATABASE | DATASET ] bei mehrdeutigen Codepages angeben werden, mit welcher Codepage f1 die Importdaten zu interpretieren sind.

�� IMPORT {pi = dobji | pi FROM dobji } FROM DATA BUFFER dbuf.

IMPORT (itab) FROM DATA BUFFER dbuf.

Import der Datenobjekte dobj1 ... dobjn (Felder, flache und komplexe Strukturen oder Tabellen) aus dem Datenpuffer dbuf, der wiederum vom Typ XSTRING sein muß. Es werden alle Daten eingelesen, die zuvor über EXPORT ... TO DATA BUFFER im Datenpuffer dbuf abgelegt wurden. Auch hier wird die Übereinstimmung der Struktur bei EXPORT und IMPORT nicht geprüft.

Im dynamischen Fall wird die Parameterliste in der zweispaltigen Indextabelle itab übergeben, deren Spalten vom Typ C oder STRING sein müssen. In der ersten Spalte von itab müssen die Namen der Parameter, in der zweiten die Datenobjekte aufgezählt werden. Falls die erste Spalte von itab leer ist, kommt es zu einer unbehandelbaren Ausnahme mit dem Laufzeitfehler DYN_IMEX_OBJ_NAME_EMPTY.

5.8 Dateischnittstelle In der Dateischnittstelle wurde die Anweisungen OPEN DATASET komplett überarbeitet und für US mit folgenden Ergänzungen versehen: �� OPEN DATASET dsn IN TEXT MODE.

Die Datei wird zum zeilenweisen Lesen und Schreiben geöffnet. Schließende Leerzeichen werden in diesem Modus abgeschnitten.

1. Zusatz ... ENCODING (DEFAULT | UTF-8 | NON-UNICODE)

Das Schlüsselwort ENCODING bestimmt den Zeichensatz, mit dem die Daten bearbeitet werden. DEFAULT ist unter US stets UTF-8, unter NUS aber NON-UNICODE. Die Angabe NON-UNICODE bewirkt, dass diejenige Nicht-Unicode-Codepage verwendet wird, die in einem NUS zu der Anmeldesprache oder der durch die Anweisung SET LOCALE LANGUAGE gesetzten Sprache passt oder passen würde.

30

2. Zusatz ... REPLACEMENT CHARACTER rc Dieser Zusatz bestimmt das Ersatzzeichen, welches verwendet wird, wenn ein Zeichen bei der Konvertierung im Zielzeichensatz nicht vorhanden ist. Ohne diese Angabe wird die Raute # als Ersatzzeichen eingesetzt.

�� OPEN DATASET dsn IN BINARY MODE.

Die Datei wird ohne Zeilenumbruch zum Lesen und Schreiben geöffnet, wobei in US und NUS genau der Speicherinhalt übernommen wird.

�� OPEN DATASET dsn IN LEGACY TEXT MODE [(LITTLE | BIG) ENDIAN ] [ CODE PAGE cp ].

Die Datei wird zum zeilenweisen Lesen und Schreiben in einem Format geöffnet, das zum TEXT MODE in NUS kompatibel ist.

Der optionale Zusatz ENDIAN bestimmt, in welcher Byte-Reihenfolge Zahlen der Typen I oder F verarbeitet werden. Fehlt dieser Zusatz, dann legt das Betriebssystem des Applikationsservers die Reihenfolge fest. Unterscheidet sich die angegebene Byte-Reihenfolge von derjenigen des Applikationsservers, dann werden bei den Anweisungen READ DATASET und TRANSFER entsprechende Konvertierungen durchgeführt. Auch hier ist ein REPLACEMENT CHARACTER rc möglich.

Der Zusatz CODE PAGE gibt die Codepage an, in der Texte der Datei dsn dargestellt werden. Fehlt dieser Zusatz, wird diejenige Codepage genommen, die beim Lesen oder Schreiben der Datei gesetzt ist.

�� OPEN DATASET dsn IN LEGACY BINARY MODE [(LITTLE|BIG) ENDIAN)] [ CODE PAGE cp ].

Die Datei wird ohne Zeilenumbruch zum Lesen und Schreiben in einem Format geöffnet, das zum BINARY MODE in NUS kompatibel ist, wobei für den Zusatz ENDIAN und CODE PAGE die obigen Bestimmungen gelten. Der Zusatz REPLACEMENT CHARACTER rc ist auch hier wiederum erlaubt.

Bei allen Varianten ist der Zusatz IGNORING CONVERSION ERRORS möglich, der Laufzeitfehler beim Lesen oder Schreiben der Datei unterdrückt, falls ein Konvertierungsfehler auftritt. Allgemein gilt, daß ein Lesen oder Schreiben einer Datei einen Laufzeitfehler auslöst, wenn diese nicht zuvor mittels OPEN DATASET geöffnet wurde. 5.9 Up- und Download von Dateien Die bisherigen Funktionsbausteine WS_UPLOAD und WS_DOWNLOAD gehören zwar nicht zum Standardbefehlssatz von ABAP, sie stellen aber die Dateischnittstelle auf dem Präsentationsserver dar. WS_UPLOAD und WS_DOWNLOAD sind in einem US nicht ablauffähig und werden daher ersetzt durch die Bausteine GUI_UPLOAD und GUI_DOWNLOAD.

Die neuen Funktionsbausteine GUI_UPLOAD und GUI_DOWNLOAD besitzen eine Schnittstelle, die es ermöglicht, auch Unicode-Formate auf die lokale Platte zu schreiben. Eine Beschreibung der Schnittstellen enthält die Dokumentation zu

31

diesen Funktionsbausteinen, die unter SAP Easy Access -> Entwicklung -> Function Builder -> Springen -> Dokumentation aufgerufen werden kann.

5.10 Generische Typen für Feldsymbole und Parameter

Für die Typisierung von Parametern und Feldsymbolen werden neue generische Datentypen zur Verfügung gestellt:

�� SIMPLE ist kompatibel zu den Typen, die auch zu CLIKE, XSEQUENCE oder NUMERIC kompatibel sind, also zu allen elementaren Typen einschließlich C- und X-Strings. Durch eine Typisierung mit SIMPLE ist sichergestellt, daß Parameter oder Feldsymbole mit WRITE ausgegeben oder in arithmetischen Operationen verwendet werden können. Bei der Verwendung in arithmetischen Operationen kann es allerdings inhaltsabhängig zu Konvertierungsfehlern kommen, wenn zum Beispiel ein C-Feld als aktueller Parameter übergeben wird und der Feldinhalt nicht als Zahl interpretiert werden kann.

�� CLIKE ist kompatibel zu den Typen C, N, D, T und STRING sowie zu rein zeichenartigen Strukturen. In NUP besteht außerdem Kompatibilität zu den Elementartypen X und XSTRING. Durch eine Typisierung mit CLIKE ist sichergestellt, daß Parameter oder Feldsymbole bei allen Operationen zur Zeichenkettenverarbeitung verwendet werden können, zum Beispiel bei den Anweisungen CONCATENATE, FIND oder REPLACE. Außerdem ist garantiert, daß bei Offset- und Längenzugriffe in Zeichen gezählt wird. Zudem sind diese im Bereich des gesamten Feldes und bei Typ STRING in der aktuellen Stringlänge erlaubt.

�� CSEQUENCE ist kompatibel zu den Typen C und STRING

�� XSEQUENCE ist kompatibel zu den Typen X und XSTRING. Durch diese Typisierung ist sichergestellt, daß Parameter oder Feldsymbole in Operationen zur Bytefolgenverarbeitung verwendet werden können, zum Beispiel bei der Anweisung CONCATENATE ... IN BYTE MODE.

�� NUMERIC ist kompatibel zu den Typen I, P, F und zu den nur im Dictionary vorhandenen Typen INT1 (1-Byte-Integer) und INT2 (2-Byte-Integer). Es ist zu beachten, daß Typ N nicht zu NUMERIC kompatibel ist. Durch die Typisierung mit NUMERIC ist sichergestellt, daß Parameter und Feldsymbole in arithmetischen Operationen verwendet werden können, ohne daß Typ- oder Konvertierungsfehler auftreten.

5.11 Aufbereitung von Listen �� Einführung

Die Anweisung WRITE schreibt den Inhalt von Datenobjekten auf eine Liste. Beim Schreiben mit der Anweisung WRITE wird die Ausgabe im Listenpuffer gespeichert und von dort beim Aufruf der Liste zur Anzeige gebracht. Bei jeder Ausgabe eines Datenobjekts mit WRITE wird implizit oder explizit eine Ausgabelänge festgelegt, wobei die implizite Ausgabelänge vom Datentyp abhängt. Mit der Ausgabelänge werden zwei Dinge definiert:

�� die Anzahl der im Listenpuffer für Zeichen zur Verfügung stehenden Stellen (oder Speicherplätze)

32

�� die Anzahl der auf der eigentlichen Liste zur Verfügung stehenden Spalten (oder Zellen)

Wenn die Ausgabelänge kleiner als die Länge des Datenobjekts ist, wird dessen Inhalt beim Schreiben in den Listenpuffer nach bestimmten Regeln verkürzt, wobei ein Wertverlust bei numerischen Feldern durch das Zeichen * angezeigt wird. Bei Anzeige oder Ausdruck einer Liste werden die im Listenpuffer abgelegten Inhalte wie folgt auf die Liste übertragen:

�� In NUS benötigt jedes Zeichen genau soviel Platz im Listenpuffer wie Spalten auf der Liste. In Single-Byte-Systemen belegt ein Zeichen ein Byte im Listenpuffer und eine Spalte auf der Liste, während ein Zeichen, das in Multi-Byte-Systemen mehrere Bytes im Listenpuffer belegt, auch die gleiche Anzahl an Spalten auf der Liste belegt. Deshalb werden in NUS alle im Listenpuffer abgelegten Zeichen auf der Liste dargestellt.

�� In US belegt jedes Zeichen in der Regel eine Stelle im Listenpuffer. Ein Zeichen kann aber auf der Liste mehr als eine Spalte belegen, was insbesondere für ostasiatische Zeichen gilt. Da auf der Liste aber nur genau so viele Spalten wie Stellen im Listenpuffer zur Verfügung stehen, können in diesem Fall nur weniger Zeichen auf der Liste dargestellt werden als im Listenpuffer abgelegt sind. Die Listenausgabe wird entsprechend verkürzt, wobei sich die Seite nach der Ausrichtung richtet und mit einem der Kennzeichen > oder < versehen wird. Auf einer angezeigten Liste kann dann über die Auswahl von System -> Liste -> Unicode-Anzeige der gesamte Inhalt zur Anzeige gebracht werden.

Aus diesen Gründen ist die horizontale Position des Listen-Cursors nur in NUS gleichbedeutend zur Ausgabespalte einer dargestellten oder gedruckten Listen. In US ist dies nur für die jeweils unteren und oberen Ausgabegrenzen der einzelnen Ausgaben garantiert.

�� Regeln für die WRITE-Anweisung

Um ungewolltes Abschneiden so weit wie möglich zu vermeiden, wurden die Regeln für die WRITE-Anweisung in UP angepasst und erweitert.

1. WRITE-Anweisung mit impliziter Ausgabelänge

In UP verhält sich die WRITE-Anweisung ohne explizite Angabe der Ausgabelänge für alle ausgebbaren Datenobjekte mit Ausnahme von Textfeldliteralen und von Datenobjekten des Typs string wie in NUP. Dadurch kann es vorkommen, dass auf der Liste weniger Zeichen dargestellt werden als im Listenpuffer abgelegt sind.

Bei Textfeldliteralen und bei Datenobjekten des Typs string wird davon ausgegangen, dass alle Zeichen dargestellt werden sollen. Deshalb wird die implizite Ausgabelänge anhand der im Datenobjekt enthaltenen Zeichen so berechnet, dass sie der Anzahl der auf der Liste benötigten Spalten entspricht. Wenn diese Ausgabelänge größer als die Länge des Datenobjekts ist, werden überzählige Stellen beim Schreiben in den Listenpuffer mit Leerzeichen aufgefüllt. Bei der Darstellung auf der Liste werden diese Leerzeichen wieder abgeschnitten, da die Darstellung der Zeichen die Ausgabelänge genau ausfüllt.

33

2. WRITE-Anweisung mit expliziter Ausgabelänge

Wenn bei der WRITE-Anweisung ein numerisches Datenobjekt als explizite Ausgabelänge hinter dem Zusatz AT angegeben ist, wird der Wert dieser Zahl sowohl in US als auch in NUS als Ausgabelänge verwendet. In US kann sich die Anzahl der auf der Liste dargestellten Zeichen von der Anzahl der im Listenpuffer gespeicherten Zeichen unterscheiden. Seit Release 6.20 kann die Ausgabelänge außer über numerische Datenobjekte wie folgt angegeben werden:

1. WRITE AT (*) ...

�� Bei Datenobjekten der Typen c und string wird die Ausgabelänge auf die Anzahl der Spalten gesetzt, die auf der Liste zur Darstellung des gesamten Inhalts benötigt werden, wobei keine schließenden Leerzeichen bei Typ c berücksichtigt werden. Bei Datenobjekten vom Typ string ist dies gleichbedeutend zur impliziten Länge.

�� Bei Datenobjekten der Typen d und t wird die Ausgabelänge auf 10 und 8 gesetzt.

�� Bei Datenobjekten der numerischen Typen i, f und p wird die Ausgabelänge auf den Wert gesetzt, der nötig ist, um den aktuellen Wert einschließlich Tausendertrennzeichen auszugeben, wobei der Wert nach Anwendung der eventuellen Zusätze CURRENCY, DECIMALS, NO-SIGN, ROUND oder UNIT betrachtet wird.

�� Bei Datenobjekten der Typen n, x und xstring wird die implizite Ausgabelänge verwendet.

2. WRITE AT (**) ...

�� Bei Datenobjekten der Typen c wird die Ausgabelänge auf die doppelte Länge des Datenobjektes und bei Datenobjekten vom Typ string auf die doppelte Anzahl enthaltener Zeichen gesetzt.

�� Bei Datenobjekten der Typen d und t wird die Ausgabelänge auf 10 und 8 gesetzt.

�� Bei Datenobjekten der numerischen Typen i, f und p wird die Ausgabelänge auf den Wert gesetzt, der nötig ist, um die maximal möglichen Werte dieser Typen einschließlich Vorzeichen und Tausendertrennzeichen auszugeben, wobei der Wert nach Anwendung der eventuellen Zusätze CURRENCY, DECIMALS, NO-SIGN, ROUND oder UNIT betrachtet wird.

�� Bei Datenobjekten der Typen n, x und xstring wird die implizite Ausgabelänge verwendet.

�� Zusätze bei GET/SET CURSOR FIELD/LINE

Die Zusätze DISPLAY OFFSET und MEMORY OFFSET berücksichtigen, dass Datenobjekte bei der Darstellung auf einer Liste (Display) und bei der Zwischenspeicherung im Listenpuffer (Memory) unterschiedliche Längen belegen können. In Unicode-Codepages gibt es zum Beispiel Zeichen, die im Listenpuffer nur eine Stelle belegen, bei der Anzeige aber zwei Ausgabespalten benötigen.

34

Dementsprechend wird der Cursor bei der Anweisung SET CURSOR { FIELD f | LINE l } durch den Zusatz DISPLAY OFFSET off in der Ausgabe und durch den Zusatz MEMORY OFFSET off im Listenpuffer gesetzt.

In gleicher Weise überträgt die Anweisung GET CURSOR { FIELD f | LINE l } bei Verwendung des Zusatzes DISPLAY OFFSET off die Cursorposition innerhalb des angezeigten Feldes in das Datenobjekt off. Dagegen wird bei Verwendung des Zusatzes MEMORY OFFSET off die Cursorposition im Listenpuffer in das Datenobjekt off übertragen. Der Zusatz DISPLAY ist die Standardeinstellung und kann daher auch weggelassen werden.

�� Klasse für die Aufbereitung von Listen

Für die Berechnung von Ausgabelängen, die Konvertierung von Werten aus dem Listenpuffer und die Definition von Feldgrenzen wurde die Klasse CL_ABAP_LIST_UTILITIES eingeführt. Mit den Rückgabewerten ihrer Methoden kann eine korrekte Spaltenausrichtung auf ABAP-Listen programmiert werden, auch wenn ostasiatische Schriften ausgegeben werden.

�� Listeneinstellungen Die Objekte einer Liste können in unterschiedlichen Ausgabelängen angezeigt werden, indem die gewünschte Länge im Menü System -> Liste -> Unicode-Anzeige eingestellt wird. Dies ist für vor allem bei Bildschirmlisten in US vorteilhaft, deren Ausgaben abgeschnitten wurden, was durch die Zeichen > oder < angezeigt wird.

�� Empfehlungen Damit Listen sowohl in US als auch in NUS gleiches Aussehen und Funktionalität besitzen, wird für die Programmierung von Listen die Einhaltung folgender Regeln empfohlen:

�� Angabe einer ausreichenden Ausgabelänge �� Kein Überschreiben von Teilen eines Feldes �� Keine Verwendung von WRITE TO mit RIGHT-JUSTIFIED oder CENTERED mit

nachfolgender WRITE-Ausgabe �� Bei selbstprogrammiertem horizontalen Blättern mit der Anweisung SCROLL

sollten nur die untere oder obere Grenze von ausgegebenen Datenobjekten angegeben werden, da in US die Positionen im Listenpuffer und auf der dargestellten Liste nur für diese Feldgrenzen garantiert übereinstimmen.

6. Neue Klassen für Unicode 6.1 Ermittlung von Feldeigenschaften Die Klasse CL_ABAP_CHAR_UTILITIES bietet Attribute und Methoden an, die Eigenschaften einzelner Zeichen betreffen. Die Komponenten dieser Klasse sind alle statisch und öffentlich. Die Attribute sind schreibgeschützt und werden im Klassenkonstruktor initialisiert.

35

�� Attribut CHARSIZE

CHARSIZE TYPE I.

Das Attribut CHARSIZE gibt die Länge eines C(1)-Feldes in Bytes an, also 1 Byte in einem NUS und 2 oder 4 Byte in einem US.

�� Attribute MINCHAR, MAXCHAR

MINCHAR(1) TYPE C.

MINCHAR enthält in einem NUS das Zeichen mit der Hexadezimaldarstellung X'00', in einem US das Unicodezeichen U+0000.

MAXCHAR(1) TYPE C.

MAXCHAR enthält in einem NUS das Zeichen mit der Hexadezimaldarstellung X'FF', in einem US das Unicodezeichen U+FFFD.

Diese Werte dürfen nur in binären Vergleichen für folgende ABAP-Anweisungen benutzt werden: 1. SORT ohne Zusatz AS TEXT 2. IF mit den Operatoren <, >, <=, >= 3. IF f1 BETWEEN f2 AND f3. 4. IF f in sel.

Bei binären Vergleichen ist allerdings darauf zu achten, daß die Ergebnisse von der Plattform abhängen. So gilt zum Beispiel im Zeichensatz ISO-8859-1 die Reihenfolge 1 < A < Z < a < Ä < ü, in EBCDIC jedoch Ä < a < A < ü < Z < 1.

CLEAR feld WITH CL_ABAP_CHAR_UTILITIES=>MAXCHAR kann benutzt werden, um ein Feld mit einem Wert zu füllen, der größer oder gleich als alle Zeichenketten ist. Dies funktioniert auch auf Multibyte-NUS.

MINCHAR und MAXCHAR sind im allgemeinen keine gültigen Zeichen des gegenwärtigen Zeichensatzes. Insbesonders darf TRANSLATE f TO UPPER CASE nicht auf diese Attribute angewendet werden, weil das Ergebnis undefiniert ist. Die gleichen Einschränkungen gelten für alle Operationen wie zum Beispiel CS, NS, CP, NP oder SEARCH, die implizit in Großbuchstaben wandeln. Außerdem sind Zeichensatzkonvertierungen mit MINCHAR und MAXCHAR nicht zulässig. Darüber hinaus ist nicht garantiert, daß MINCHAR auf Dynpros als Raute (#) ausgegeben wird. In manchen Fällen wird MINCHAR als Ende eines Textfeldes behandelt.

�� Byte Order Die Konvertierung von Zahlentypen und Unicode zwischen Little Endian und Big Endian wird durch die Konvertierungsklassen, die im Zusammenhang mit der Dateischnittstelle eingeführt werden, abgedeckt. Die hier beschriebenen Attribute dienen dazu, Byte-Order-Marks in X-Containern zu erkennen und zu schreiben.

36

Attribut ENDIAN

ENDIAN(1) TYPE C.

Hier wie auch in der klassenbasierten Dateischnittstelle werden in US und NUS die Werte B für Big Endian und L für Little Endian vergeben. Konstanten BYTE_ORDER_MARK_

BYTE_ORDER_MARK_LITTLE(2) TYPE X BYTE_ORDER_MARK_BIG(2) TYPE X BYTE_ORDER_MARK_UTF8(3) TYPE X

Die Werte dieser Konstanten sind für US und NUS dieselben, nämlich X'FFFE' für Little Endian und X'FEFF' für Big Endian. BYTE_ORDER_MARK_UTF8 enthält die UTF8-Darstellung von U+'FEFF'.

Die klassenbasierte Dateischnittstelle wird eine Byte-Order-Mark schreiben, wenn eine UTF16- oder UCS2-Textdatei zum Schreiben geöffnet wird. Wenn eine Textdatei zum Lesen oder Anfügen geöffnet wird, wird die Byte-Order-Mark benutzt, um den Endian zu bestimmen. Dabei wird die Byte-Order-Mark beim Einlesen jedoch nicht in die Zielfelder geschrieben.

�� Attribute NEWLINE, CR_LF und HORIZONTAL_TAB NEWLINE(1) TYPE C CR_LF(2) TYPE C HORIZONTAL_TAB(1) TYPE C Diese Attribute enthalten die jeweiligen plattformspezifischen Steuerzeichen

6.2 Konvertierung von Daten Diese Klassen dienen dazu, ABAP-Daten zwischen dem Systemformat und externen Formaten zu konvertieren. Dabei werden zeichenartige Daten in einen anderen Zeichensatz und numerische Daten möglicherweise in eine andere Bytereihenfolge (Endian) konvertiert. Für Daten in einem externen Format müssen Container der Typen X und XSTRING verwendet werden. Zeichensatz- und Endiankonvertierung werden auch von der Dateischnittstelle (OPEN DATASET mit neuen Zusätzen), dem RFC, den Funktionsbausteinen GUI_DOWNLOAD oder GUI_UPLOAD durchgeführt. Für speziellere Fälle, in denen die Möglichkeiten dieser Hilfsmittel nicht ausreichen, werden die hier beschriebenen Klassen zur Verfügung gestellt. Da diese Klassen mit Containern der Typen X und XSTRING arbeiten, können diese Container von der Dateischnittstelle, dem RFC und den Funktionsbausteinen GUI_DOWNLOAD und GUI_UPLOAD unkonvertiert übertragen werden. Die Klassen ersetzen die beiden folgenden Anweisungen:

TRANSLATE c ...FROM CODE PAGE g1 ... TO CODE PAGE g2 TRANSLATE f ...FROM NUMBER FORMAT n1 ... TO NUMBER FORMAT n2 Eine ausführliche Beschreibung befindet sich in der Klassendokumentation des Class Builders. Im einzelner sind folgende Klassen sind verfügbar:

37

CL_ABAP_CONV_IN_CE: Lesen von Daten aus einem Container und Konvertieren in das Systemformat. Es ist auch möglich, Strukturen mit Daten zu füllen. CL_ABAP_CONV_OUT_CE: Konvertieren von Daten vom Systemformat in ein externes Format und Schreiben in einen Container. CL_ABAP_CONV_X2X_CE: Konvertieren von Daten von einem externen Format in ein anderes externes Format. 7. RFC und Unicode Im Zusammenhang mit der ABAP Unicode Umstellung wird auch die RFC- Schnittstelle geändert. Die folgenden Ausführungen skizzieren in aller Kürze die allgemeinen Vorgaben. Damit der Remote Function Call in US wie auch in NUS funktioniert, wird in der Destination ein zusätzliches Attribut eingeführt, das beschreibt, ob der RFC in einem US oder NUS laufen soll. Benutzt ein ABAP-Programm Funktionsbausteine, die dynamisch Änderungen der RFC-Destination vornehmen, so muß diese neue Eigenschaft in einem weiteren obligatorischen Parameter versorgt werden. Bei der Übertragung von Textdaten in einem RFC-Aufruf können neue Ausnahmen der folgenden Art auftreten:

�� Ein Text kann nicht von der Quellcode- in die Zielcodepage konvertiert werden, weil die entsprechenden Zeichen in der Zielcodepage nicht vorhanden sind.

�� Das Feld im Zielsystem ist kürzer als das Feld im Quellsystem. Dies kann vorkommen, wenn Daten von einem US in ein Multibyte-System übertragen werden.

�� Grundsätzlich kann davon ausgegangen werden, dass Textdaten im sendenden und empfangenden System unterschiedliche Länge haben. Aus diesem Grund wird in erster Linie die Verwendung von Strings empfohlen. Wo immer die Möglichkeit besteht, sollten Längenangaben für Textdaten ausgeschlossen werden. Im Gegensatz dazu können binäre Daten ohne Probleme mit Längenangeben gesendet werden.

8. Abrundungsmaßnahmen Bisher wurde die Klassenhierarchie und die Interface-Implementierungsrelation bei der Prüfung und Konvertierung von Datentypen nur bei Einzelfeldern mit Klassen- und Interface-Referenzen berücksichtigt. Dagegen war dies bei Strukturen, die Referenzen enthalten, nur sehr uneinheitlich geregelt. Bei der Konvertibilität und der Typ- und Vergleichskompatibilität tiefer Strukturen wurden deshalb die nachfolgenden Verallgemeinerungen vorgenommen.

38

1. Konvertibilität und Typkompatibilität für Importing-Parameter:

�� Elementare Komponenten von Strukturen müssen genau übereinstimmen.

�� Die Klassenhierarchie und die Interface-Implementierungsrelation werden auch für Interface- und Klassenreferenzen als Teilkomponenten berücksichtigt.

�� Tabellenkomponenten sind miteinander kompatibel, sofern der Zeilentyp typkompatibel und konvertibel ist. Das bedeutet, daß sich die Zugriffsarten der Tabellen unterscheiden dürfen und die Zeilentypen konvertibel sein müssen. Beispielsweise ist eine Strukturkomponente Tabelle über Integer mit einer Komponente Tabelle über Floats verträglich.

2. Vergleichskompatibilität:

�� Elementare Komponenten müssen genau übereinstimmen.

�� Beliebige Klassen- und Interface-Referenzkomponenten sind zueinander vergleichskompatibel.

�� Tabellenkomponenten sind miteinander vergleichskompatibel, wenn der Zeilentyp vergleichskompatibel ist.

39

9. Weitere Beispielprogramme zur Unicode-Umstellung 9.1 Zuweisung zwischen Strukturen: Umstellung durch Includes mit Gruppenamen Vor der Unicode-Umstellung:

types: begin of T_STRUC, F1 type c, F2 type c, F3 type i, F4 type p, end of T_STRUC. data: begin of STRUC1. include type T_STRUC. data: F5 type x. data: end of STRUC1. data: begin of STRUC2. include type T_STRUC. data: F6 type p. data: end of STRUC2. STRUC1 = STRUC2. � Unicode-Fehler!

Es sei vorausgesetzt, dass in diesem Fall nur der Inhalt des Includes, also die Komponenten F1 bis F4 zugewiesen werden sollen. Es wurde bisher in Kauf genommen, dass die Komponente F5 mit eine unsinnigen Wert überschrieben wird. Nach der Unicode-Umstellung Durch die Einführung von Gruppennamen für die Includes und der Verwendung dieser Gruppennamen bei der Zuweisung kann diese Programmstelle einfach umgestellt werden.

types: begin of T_STRUC, F1 type c, F2 type c, F3 type i, F4 type p, end of T_STRUC. data: begin of STRUC1. include type T_STRUC as PART1. data: F5 type x. data: end of STRUC1. data: begin of STRUC2. include type T_STRUC as PART1. data: F6 type p. data: end of STRUC2.

40

STRUC1-PART1 = STRUC2-PART1. � ok

9.2 Zuweisung zwischen Strukturen: Umstellung durch Offset/Längen-Zugriffe Vor der Unicode-Umstellung:

data: begin of STRUC1, F1(10) type c, F2(20) type c, F3 type i, F4 type p, end of STRUC1, begin of STRUC2, C1(10) type c, C2(20) type c, C3 type x, C4 type f, end of STRUC2. STRUC1 = STRUC2. � Unicode-Fehler!

In diesem Beispiel wird davon ausgegangen, dass nur der Inhalt der ersten beiden Komponenten C1 und C2 bei der Zuweisung an F1 und F2 übertragen werden soll, da die nachfolgenden Komponenten F3 und F4 sowieso durch unsinnige Werte überschrieben werden. Nach der Unicode-Umstellung Da das Anfangsstück der Strukturen, das für die beabsichtigte Zuweisung relevant ist, rein zeichenartig ist, können die Operanden der Zuweisung jeweils durch Offset-/Längenzugriffe selektiert werden: ... STRUC1(30) = STRUC2(30). � ok 9.3 Offset/Längen-Zugriff auf Strukturen bei Zuweisung: Verwendung von Includes Vor der Unicode-Umstellung Durch Offset-/Längenzugriffe werden Teilbereiche von Strukturen selektiert, die einander zugeweisen werden sollen. Da die Strukturen mit nicht zeichenartigen Kompontenten beginnen, sind die Offset-/Längenzugriffe in unicodefähigen Programmen nicht mehr erlaubt.

41

data: begin of STRUC1, F0 type x, F1(10) type c, F2(20) type c, F3 type i, F4 type p, end of STRUC1, begin of STRUC2, C0 type i, C1(10) type c, C2(20) type c, C3 type x, C4 type f, end of STRUC2. STRUC1+1(30) = STRUC2+4(30). � Unicode-Fehler!

Nach der Unicode-Umstellung Durch die Einführung von Includes mit Gruppennamen können die entsprechenden Teilbereiche der Strukturen selektiert und einander zugewiesen werden.

types: begin of PART1, F1(10) type c, F2(20) type c, end of PART1, begin of PART 2, C1(10) type c, C2(20) type c, end of PART 2. data: begin of STRUC1, F0 type x. include type PART1 as PART. data: f3 type i, f4 type p, end of STRUC1, begin of STRUC2, C0 type i. include type PART2 as PART. data: C3 type x, C4 type f, end of STRUC2. STRUC1-PART = STRUC2-PART. � ok

42

9.4 Offset/Längen-Zugriff auf Strukturen bei Zuweisung: Includes-Lösung nicht möglich Vor der Unicode-Umstellung

data: begin of STRUC1, F0(1) type x, F1(10) type c, F2(20) type c, F3 type i, F4 type p, end of STRUC1, begin of STRUC2, C0(1) type c, C1(10) type c, C2(20) type c, C3 type i, C4 type f, end of STRUC2, begin of STRUC3, G0(1) type c, G1(10) type c, G2(20) type c, end of STRUC3. STRUC1+1(35) = STRUC2+1(35). � Unicode-Fehler STRUC3 = STRUC2.

Umstellungsversuch: Einführung von INCLUDEs mit Gruppennamen

types: begin of PART1, F1(10) type c, F2(20) type c, F3 type i, end of PART1, begin of PART2, C1(10) type c, C2(20) type c, C3 type i, end of PART2. data: begin of STRUC1, F0(1) type x. include type PART1 as PART. data: F4 type p, end of struc1. data: begin of STRUC2, C0(1) type c.

43

include type PART2 as PART. data: C4 type f, end of STRUC2, begin of STRUC3, G0(1) type c, G1(10) type c, G2(20) type c, end of STRUC3. STRUC1-PART = STRUC2-PART. STRUC3 = STRUC2. � Neuer Unicode-Fehler!

Durch die Einführung der Includes kann zwar die ursprüngliche Problemstelle Unicode-fähig umgestellt werden, es wird aber bei der danach folgenden Zuweisung ein neues Unicode-Problem erzeugt: Die Zuweisung von STRUC2 an STRUC3 ist nicht mehr möglich, da durch das Include in STRUC2 eine Alignmentlücke vor der Komponente C1 entsteht. Dies führt dazu, daß die Unicode-Fragmentsichten von STRUC2 und STRUC3 nicht mehr zusammenpassen. Nach der Umstellung In diesem Fall bleibt nichts anderes mehr übrig, als die betroffenen Komponenten der Strukturen einzeln einander zuzuweisen:

data: begin of STRUC1, F0(1) type x, F1(10) type c, F2(20) type c, F3 type i, F4 type p, end of STRUC1, begin of STRUC2, C0(1) type c, C1(10) type c, C2(20) type c, C3 type i, C4 type f, end of STRUC2, begin of STRUC3, G0(1) type c, G1(10) type c, G2(20) type c, end of STRUC3. STRUC1-F1 = STRUC2-C1. STRUC1-F2 = STRUC2-C2. STRUC1-F3 = STRUC2-C3. STRUC3 = STRUC2.

44

9.5 Zuweisung zwischen Struktur und Einzelfeld vom Typ N In Unicode-Programmen ist die Zuweisungen zwischen einen nicht zeichenartigen Struktur und einem Einzelfeld vom Typ N nicht mehr zulässig. Vor der Unicode-Umstellung

data: begin of STRUC, NUMBER(20) type n, F2 type p, end of STRUC, NUMBER(20) type n. NUMBER = STRUC. � Unicode-Fehler!

Nach der Unicode-Umstellung

Da hier die erste Komponenten der Struktur an das Einzelfeld zugewiesen werden soll, kann die Programmstelle einfach umgestellt werden, indem die Zuweisung der ganzen Struktur durch eine Zuweisung der ersten Strukturkomponente ersetzt wird.

... NUMBER = STRUC-NUMBER.

9.6 Zuweisung zwischen Struktur und Einzelfeld vom Typ D Vor der Unicode-Umstellung

data: begin of STRUC, YEAR(4) type n, MONTH(2) type n, DAY(2) type n, F4 type p, end of STRUC, DATE type d. DATE = STRUC. � Unicode-Fehler!

In Unicode-Programmen ist die Zuweisungen zwischen einen nicht zeichenartigen Struktur und einem Einzelfeld vom Typ D nicht mehr zulässig. Nach der Unicode-Umstellung Durch einen Offset-/Längenzugriff auf das zeichenartige Anfangsstück der Struktur kann die Problemstelle einfach Unicode-fähig umgestellt weden.

DATE = STRUC(8). � ok!

45

9.7 Zuweisung zwischen Struktur und Einzelfeld: ASCII-Codes Zuweisungen zwischen Strukturen mit Komponenten vom Typ X und Einzelfeldern wurden früher auch dazu verwendet, um trickreich, z.B. wie in folgendem Beispiel, Zeichen zu einem ASCII-Code zu berechnen. Vor der Unicode-Umstellung

data: begin of TAB, X(1) type x value '09', “ASCII horizontal tab end of TAB, C(10) type c. C+5(1) = TAB. � Unicode-Fehler

In Unicode-Programmen funktioniert dieser Trick nicht mehr. Durch die neuen vordefinierten Konstanten in Klasse CL_ABAP_CHAR_UTILITIES ist aber nun eine einfache und saubere Lösung möglich, die auf allen Plattformen funktioniert. Nach der Unicode-Umstellung

class cl_abap_char_utilities definition load. c+5(1) = cl_abap_char_utilities=>horizontal_tab.

Anmerkung: Sollte das verwendete Zeichen nicht als Konstante vordefiniert sein, kann man sich mit der Methode CL_ABAP_CONV_IN_CE=>UCCP beziehungsweise CL_ABAP_CONV_IN_CE=>UCCPI) zu einem Unicode-Codepoint das entsprechende Zeichen geben lassen. Es kann dabei die Eigenschaft ausgenützt werden, dass die Zeichen mit den ASCII-Codes 00 bis 7F den ersten 127 Unicode-Codepoints, also U+0000 bis U+007F) entsprechen. 9.8 Zuweisung zwischen Struktur und Einzelfeld: Containerfelder (1) Häufig wurden lange Felder vom Typ C als "Container" verwendet, in dem Daten unterschiedlicher Strukturen abgelegt werden. Zum Ablegen und Auslesen der Daten konnte direkt die Zuweisung zwischen Struktur und Einzelfeld verwendet werden. In Unicode-Programmen sind diese Zuweisungen nur noch erlaubt, wenn die Struktur rein zeichenartig aufgebaut ist. Vor der Unicode-Umstellung

data: begin of STRUC, F1(3) type x, F2(8) type p, end of STRUC, CONTAINER(1000) type c. “Daten im Container ablegen

46

CONTAINER = STRUC. � Unicode-Fehler ”Daten aus dem Container auslesen STRUC = CONTAINER. � Unicode-Fehler

Die Verwendung von C-Feldern als Container zur Speicherung nicht vollständig zeichenartiger Strukturen funktioniert nur noch dann, wenn sichergestellt ist, dass der Inhalt nur temporär innerhalb eines Applikationsservers verwendet wird. Daher darf der Inhalt des Containerfelds weder in der Datenbank abgelegt noch per RFC verschickt oder auf ein File geschrieben werden1. Außerdem darf nicht mit Offset oder Länge auf das Containerfeld zugegriffen werden, um Komponenten einer Struktur zu selektieren2. Sind diese Voraussetzungen erfüllt, kann das Füllen und Lesen der Daten folgendermaßen umgestellt werden, indem durch Casts Feldsymbole vom Typ X auf das Containerfeld und die Struktur gesetzt werden und danach die Zuweisung zwischen den Feldsymbolen erfolgt. Die Zuweisung bewirkt nun, daß der Rest des Containers mit Hex-00-Werten statt mit Leerzeichen aufgefüllt wird. Wenn das C-Feld nur als Datenablage verwendet wird, sollte das aber kein Problem sein. Nach der Unicode-Umstellung

field-symbols: <X_CONTAINER> type x, <X_STRUC> type x. assign CONTAINER to <X_CONTAINER> casting. assign STRUC to <X_STRUC> casting. “Daten im Container ablegen <X_CONTAINER> = <X_STRUC>. � ok! ”Daten aus dem Container auslesen <X_STRUC> = <X_CONTAINER>. � ok!

Anmerkung: Es gibt die Klasse CL_ABAP_CONTAINER_UTILITIES, die generische Möglichkeiten bietet, um Strukturen in Containern vom Typ C oder STRING abzulegen. Bei Verwendung dieser Klassen ist aber zu berücksichtigen, daß durch die Klassenverschalung und die generische Lösung möglicherweise . Performance-Einbußen in Kauf genommen werden müssen.

1 Beim Ablegen auf beziehungsweise Lesen von der Datenbank oder beim RFC werden eventuell, abhängig von der Bytereihenfolge (little endian/big endian) der Applikationsserver-Hardware, automatisch die Bytes des Zeichenfelds vertauscht. Werden innerhalb des Zeichenfelds nicht zeichenartige Daten abgelegt, dann führt diese automatische Vertauschung dazu, dass der Inhalt verstümmelt wird. 2 Ein Zugriff mit Offset/Länge ist nicht mehr sinnvoll möglich, da die Offset- und Längenwerte auf Nicht-Unicode- und Unicode-Plattformen unterschiedlich sein können. Außerdem wird bei Zugriffen auf C-Felder immer in Zeichen gezählt, in den Strukturen aber auch Komponenten vorkommen können, die auf Unicode-Systemen ungerade Längen oder Offsets besitzen.

47

... class CL_ABAP_CONTAINER_UTILITIES definition load. call method CL_ABAP_CONTAINER_UTILITIES =>FILL_CONTAINER_C exporting IM_VALUE = STRUC importing EX_CONTAINER = CONTAINER exceptions ILLEGAL_PARAMETER_TYPE = 1 others = 2. call method CL_ABAP_CONTAINER_UTILITIES =>READ_CONTAINER_C exporting IM_CONTAINER = CONTAINER importing EX_VALUE = STRUC exceptions ILLEGAL_PARAMETER_TYPE = 1 others = 2.

9.9 Zuweisung zwischen Struktur und Einzelfeld; Containerfelder (2) Ist sichergestellt, dass die Gesamtlänge der Strukturen, die im C-Container abgelegt werden, immer ein Vielfaches der Länge eines Zeichens ist - das ist dann der Fall, wenn die Struktur mindestens eine Komponente vom Typ C, N, D, T, I oder F enthält – dann kann die folgende, einfachere Lösung verwendet werden, die mit nur einem Feldsymbol auskommt. Vor der Unicode-Umstellung

data: begin of STRUC, F1(3) type x, F2(8) type p, F3(10) type c end of STRUC, CONTAINER(1000) type c.

“Daten im Container ablegen CONTAINER = STRUC. � Unicode-Fehler! ”Daten aus dem Container auslesen STRUC = CONTAINER. � Unicode-Fehler!

Nach der Unicode-Umstellung

field-symbols: <C_STRUC> type c. assign STRUC to <C_STRUC> casting. “Daten im Container ablegen CONTAINER = <C_STRUC>. � ok ”Daten aus dem Container auslesen <C_STRUC> = CONTAINER. � ok

48

9.10 Zuweisung zwischen Struktur und Einzelfeld: Nicht lokaler Container In diesem Beispiel wird zunächst eine Tabelle gefüllt, die pro Zeile jeweils den Namen einer DDIC-Struktur und den Inhalt einer solchen Struktur – abgelegt in einem Containerfeld - enthält. An einer anderen Programmstelle wird dann diese Tabelle weiterverarbeitet: Es werden die Werte der Strukturkomponenten ausgegeben, indem über einen Funktionsbaustein die Offsets und Längen der Strukturkomponenten bestimmt werden und dann durch Offset-/Längenzugriffe auf den Container die Komponenten selektiert werden. Vor der Unicode-Umstellung

types: begin of T_VALUE_WA, TABNAME(30) type c, DUMMY_ALIGN type f, CONTAINER(1000) type c, end of T_VALUE_WA, T_VALUE_LIST type table of T_VALUE_WA. data: L_VALUES type T_VALUE_LIST, L_VALUE_WA type T_VALUE_WA, L_D010SINF type D010SINF, L_CO2MAP type CO2MAP. “Ablegen von verschiedenen Strukturen in einer Tabelle: L_VALUE_WA-TABNAME = 'D010SINF'. L_D010SINF-DATALG = 41. L_VALUE_WA-CONTAINER = L_D010SINF. � Unicode-Fehler append L_VALUE_WA to L_VALUES. L_VALUE_WA-TABNAME = 'CO2MAP'. L_CO2MAP-ID = 42. L_VALUE_WA-CONTAINER = L_CO2MAP. � Unicode-Fehler append L_VALUE_WA to L_VALUES. “Verarbeitung der Tabelle L_VALUES an einer “anderen Programmstelle: Generische Ausgabe der “Strukturkomponenten. data: L_DFIES_TAB type table of DFIES. field-symbols: <DT> type DFIES, <VALUE_WA> type T_VALUE_WA, <f>. clear L_VALUES_WA. loop at L_VALUES assigning <VALUE_WA>. “Komponenten mit Offset- und Länge bestimmen call function 'DDIF_NAMETAB_GET'

49

exporting tabname = <VALUE_WA>-TABNAME tables DFIES_TAB = L_DFIES_TAB. “Inhalt der Komponenten ausgeben loop at L_DFIES_TAB assigning <DT>. assign <VALUE_WA>-CONTAINER+<DT>-OFFSET(<DT>-INTLEN) to <F> type <DT>-INTTYPE. write <F>. endloop. endloop.

Der Offset-/Längenzugriffe führen zwar nicht zu einem Syntax- oder Laufzeitfehler, würde aber in einem Unicode-System falsche Daten liefern, da die vom Funktionsbaustein zurückgelieferten Offsets und Längen in Bytes angegeben sind, beim Zugriff auf den C-Container aber in Zeichen gezählt wird. Mit den seit Release 4.6 zur Verfügung stehenden Möglichkeiten, Datenobjekte dynamisch zu erzeugen, kann das Programm deutlich vereinfacht und unicodefähig umgeschrieben werden. Als Container für den Inhalt der Stukturen wird hier ein X-String verwendet, der jeweils mit EXPORT ... TO DATA BUFFER ... gefüllt und mit IMPORT … FROM DATA BUFFER… ausgelesen wird. Damit ist sichergestellt, dass die Daten auch applikationsserverübergreifend verwendet werden können. Nach der Unicode-Umstellung

types: begin of T_VALUE_WA, TABNAME(30) type c, XCONTAINER type xstring, end of T_VALUE_WA, T_VALUE_LIST type table of T_VALUE_WA. data: L_VALUES type T_VALUE_LIST, L_VALUE_WA type T_VALUE_WA, L_D010SINF type D010SINF, L_CO2MAP type CO2MAP. “Ablegen von verschiedenen Strukturen in einer Tabelle: L_D010SINF-DATALG = 41. L_VALUE_WA-TABNAME = 'D010SINF'. export VALUE from L_D010SINF to data buffer L_VALUE_WA-XCONTAINER. append L_VALUE_WA to L_VALUES. L_CO2MAP-ID = 42. L_VALUE_WA-TABNAME = 'CO2MAP'.

50

export VALUE from L_CO2MAP to data buffer L_VALUE_WA-XCONTAINER. append L_VALUE_WA to L_VALUES. “Verarbeitung der Tabelle L_VALUES an einer “anderen Programmstelle: generische Ausgabe der “Strukturkomponenten. data: DREF type ref to data, L_NUMBER type i, L_TYPE type c. field-symbols: <STRUC> type any, <COMP> type any. loop at L_VALUES into L_VALUE_WA. “Erzeugen eines passenden Datenobjekts create data DREF type (L_VALUE_WA-TABNAME). assign DREF->* to <STRUC>. “Datenobjekt mit Inhalt aus dem Container füllen import VALUE to <STRUC> from data buffer L_VALUE_WA-XCONTAINER. “Komponenten der Struktur ausgeben describe field <STRUC> type L_TYPE components L_NUMBER. do L_NUMBER times. assign component SY-INDEX of structure <STRUC> to <COMP>. write <COMP>. enddo. endloop.

9.11 Zeichenverarbeitung Im folgenden Beispiel werden Komponenten vom Typ X verwendet, um Zeichen abzulegen. In Unicode-Programmen ist dies nicht mehr möglich. Vor der Unicode-Umstellung

data: begin of L_LINE, TEXT1(10) type c, MARK1(1) type x value '00', TEXT2(10) type c, MARK2(1) type x value '00', TEXT3(10) type c, MARK3(1) type x value '00', BLANK(100) type c, end of L_LINE,

51

HEX0(1) type x value '00', CRLF(2) type x value '0D0A'. L_LINE-TEXT 1 = 'SYSTEM: '. L_LINE-TEXT 2 = 'USER: '. L_LINE-TEXT 3 = 'CLIENT: '. replace: HEX0 with SY-SYSID into L_LINE, � Unicode-Fehler HEX0 with SY-UNAME into L_LINE, � Unicode-Fehler HEX0 with SY-MANDT into L_LINE. � Unicode-Fehler condense L_LINE. � Unicode-Fehler concatenate L_LINE CRLF into L_LINE. � Unicode-Fehler

*Weiterverarbeitung von L_LINE.

Nach der Unicode-Umstellung Durch die Verwendung der Konstanten aus Klasse CL_ABAP_CHAR_UTILITIES kann die Verwendung von X-Feldern vollständig vermieden werden.

class CL_ABAP_CHAR_UTILITIES definition load. data: begin of L_LINE, TEXT1(10) type c, MARK1(1) type c value CL_ABAP_CHAR_UTILITIES=>MINCHAR, TEXT2(10) type c, MARK2(1) type c value CL_ABAP_CHAR_UTILITIES=>MINCHAR, TEXT3(10) type c, MARK3(1) type c value CL_ABAP_CHAR_UTILITIES=>MINCHAR, BLANK(100) type c, end of L_LINE, HEX0(1) type c, CRLF(2) type c. HEX0 = CL_ABAP_CHAR_UTILITIES=>MINCHAR. CRLF = CL_ABAP_CHAR_UTILITIES=>CR_LF. L_LINE-TEXT1 = 'SYSTEM: '. L_LINE-TEXT2 = 'USER: '. L_LINE-TEXT3 = 'CLIENT: '. replace: HEX0 with SY-SYSID into L_LINE, HEX0 with SY-UNAME into L_LINE, HEX0 with SY-MANDT into L_LINE.

52

condense L_LINE. concatenate L_LINE CRLF into L_LINE. *Weiterverarbeitung von L_LINE.

Anmerkung: Das vorgestellt Programm, das in ähnlicher Weise in einer "echten" Anwendung gefunden wurde, ist unnötig kompliziert und sicher kein Beispiel für einen guten Programmierstil. Eine viel klarere Lösung könnte folgendermaßen aussehen:

class CL_ABAP_CHAR_UTILITIES definition load. data: L_LINE(133) type c.

concatenate `SYSTEM: ` SY-SYSID ` USER: ` SY-UNAME ` CLIENT: ` SY-MANDT CL_ABAP_CHAR_UTILITIES=>CR_LF into L_LINE. 9.12 Öffnen von Dateien Vor der Unicode-Umstellung

data: begin of STRUC, F1 type c, F2 type p, end of STRUC, DSN(30) type c value 'TEMPFILE'. STRUC-F1 = 'X'. STRUC-F2 = 42. * Daten auf Datei schreiben open dataset DSN in text mode. � Unicode-Fehler transfer STRUC to DSN. close dataset DSN. Read from file * Daten aus Datei einlesen clear STRUC. open dataset DSN in text mode. � Unicode-Fehler read dataset DSN into STRUC. close dataset DSN. write: / STRUC-F1, STRUC-F2.

Das Programmbeispiel ist aus zwei Gründen nicht ablauffähig in Unicode. Zum einen muss in Unicode-Programmen bei OPEN DATASET das Dateiformat genauer spezifiziert werden, zum anderen dürfen nur noch rein zeichenartige Strukturen auf Text-Dateien geschrieben werden.

53

Je nachdem, ob das alte Dateiformat weiterhin gelesen werden können muß oder ob es möglich ist, die Daten in einem anderen, neuen Format abzulegen, sind verschiedene Umstellungsvarianten möglich, von denen zwei vorgestellt werden. Nach der Unicode-Umstellung - Fall 1: Neue textuelle Ablage im UTF-8-Format

... data: begin of STRUC2, F1 type c, F2(20) type c, end of STRUC2. * Daten in Textform bringen move-corresponding STRUC to STRUC2. * Daten auf Datei schreiben open dataset DSN in text mode for output encoding utf-8. transfer STRUC2 to DSN. close dataset DSN. * Daten aus Datei einlesen clear STRUC. open dataset DSN in text mode for input encoding utf-8. read dataset DSN into STRUC2. close dataset DSN. move-corresponding STRUC2 to STRUC. write: / STRUC-F1, STRUC-F2.

Durch die textuelle Ablage im UTF8-Format wird sichergestellt, dass die erzeugten Dateien plattformunabhängig sind. Nach der Unicode-Umstellung - Fall 2: Altes Nicht-Unicode-Format muss beibehalten werden

... * Daten auf Datei schreiben open dataset DSN in legacy text mode for output. transfer STRUC to DSN. close dataset DSN. * read from file clear STRUC. open dataset DSN in legacy text mode for input. read dataset DSN into STRUC. close dataset DSN.

write: / STRUC-F1, STRUC-F2. Durch die Verwendung von des LEGACY TEXT MODE ist sichergestellt, daß die Daten im alten Nicht-Unicode-Format abgelegt und gelesen werden. In diesem Modus ist es auch erlaubt, nicht zeichenartige Strukturen zu lesen oder zu schreiben. Es ist aber zu beachten, dass es in echten Unicode-Systemen zu Datenverlust und

54

Konvertierungsfehlern kommen kann, wenn in der Struktur Zeichen enthalten sind, die in der Nicht-Unicode-Codepage nicht repräsentiert werden können. 9.13 Ausgabe von Listen Nachträgliches überschreibendes Positionieren von SY-VLINE

Schlechtes Coding:

WRITE / AT 2 '일이삼'.

WRITE AT 1 sy-vline. WRITE AT 4 sy-vline. WRITE AT 7 sy-vline. WRITE AT 10 sy-vline.

Soll |일|이|삼|

Ist: |일| >| | Empfohlene Lösung: WRITE AT 1 sy-vline.

WRITE AT 2 '일'. WRITE AT 4 sy-vline.

WRITE AT 5 '이'. WRITE AT 7 sy-vline.

WRITE AT 8 '삼'. WRITE AT 10 sy-vline. Rechtsbündige Ausgabe mit RIGHT-JUSTIFIED:

Schlechtes Coding:

DATA text(10) TYPE c.

text = '일이삼'. WRITE text TO text RIGHT-JUSTIFIED. WRITE text. Soll: xxxx일이삼

Ist: xxxxxxx일> Empfohlene Lösung: DATA text(10) type c.

text = '일이삼'. WRITE text RIGHT-JUSTIFIED.

55

Ausgabe des vollständigen Inhaltes

Schlechtes Coding:

DATA text(10) TYPE c. text = 'OTTOS MOPS'. WRITE / text. text = '가갸거겨고교구규그기'. WRITE / text. Soll: OTTOS MOPS

가갸거겨고교구규그기

Ist: OTTOS MOPS

가갸거겨>x Empfohlene Lösung: DATA text(10) TYPE c. text = 'OTTOS MOPS'. WRITE / (*) text. text = '가갸거겨고교구규그기'. WRITE / (*) text.

Blättern:

Schlechtes Coding:

TYPES t_line(100) TYPE c. DATA: line TYPE t_line, tab TYPE table of t_line. PARAMETERS scrolcol TYPE i DEFAULT 14. line = '이름1: xxxxxx 이름2: yyyyyy'. APPEND line TO tab. line = '이름1: 남명희 이름2: 조홍우'. APPEND line TO tab. LOOP AT tab INTO line. WRITE / line+scrolcol. ENDLOOP. Soll: 이름2: yyyyyy

이름2: 조홍우

Ist: 2: yyyyyy

조홍우 Empfohlene Lösung:

56

TYPES t_line(100) TYPE c. DATA: line TYPE t_line, tab TYPE table of t_line. PARAMETERS scrolcol TYPE i DEFAULT 14. line = '이름1: xxxxxx 이름2: yyyyyy'. APPEND line TO tab. line = '이름1: 남명희 이름2: 조홍우'. APPEND line TO tab. LOOP AT tab INTO line. WRITE / line. ENDLOOP. SCROLL LIST TO COLUMN scrolcol.

Vermischen von Ausgabe- und Pufferlänge

Das Beispiel bezieht sich auf die Datenbanktabelle ZCHNUMBERS im ABAP Dictionary, die als Inhalt die Bezeichnungen der Zahlen 1 bis 5 in Englisch und Koreanisch enthält. Schlechtes Coding: SELECT * FROM zchnumbers INTO wa ORDER BY num lang. WRITE wa-lang TO line(2). WRITE sy-vline TO line+2(1). WRITE wa-name TO line+3(5). WRITE sy-vline TO line+8(1). WRITE wa-num TO line+9(3) RIGHT-JUSTIFIED. WRITE / line. ENDSELECT. Soll: KO|하나 | 1 Ist KO|하나 | 1

EN|one | 1 EN|one | 1

KO|둘 | 2 KO|둘 | 2

EN|two | 2 EN|two | 2

KO|셋 | 3 EN|two | 2

EN|three| 3 KO|셋 | 3

KO|넷 | 4 EN|three| 3

EN|four | 4 KO|넷 | 4

KO|다섯 | 5 EN|four | 4

EN|five | 5 KO|다섯 | 5 Empfohlene Lösung:

DATA: offset_tab TYPE abap_offset_tab,

57

disp_line LIKE line. APPEND 3 TO offset_tab. APPEND 8 TO offset_tab. SELECT * FROM zchnumbers INTO wa. WRITE wa-lang TO line(2). WRITE sy-vline TO line+2(1). WRITE wa-name TO line+3(5). WRITE sy-vline TO line+8(1). WRIE wa-num TO line+9(3) RIGHT-JUSTIFIED. CALL METHOD cl_abap_list_utilities=>memory_to_display EXPORTING memory_data = line offset_tab = offset_tab IMPORTING display_data = disp_line. WRITE / disp_line. ENDSELECT.

Missbrauch des Systemfeldes SY-CUCOL als Puffer-Offset

Schlechtes Coding:

DATA: off type i. AT LINE-SELECTION. off = sy-staco + sy-cucol – 3. sy-lisel+off(1) = '-'. MODIFY CURRENT LINE. START-OF-SELECTION.

WRITE / '한국'

WRITE at 50(14) '일-이-삼-사-오'. SCROLL LIST TO COLUMN 20. Wird der Cursor auf die Lücken zwischen den sichtbaren koreanischen Zeichen gestellt und danach ein Doppelklick mit der linken Maustaste ausgeführt, dann erscheint folgende Ausgabe:

Soll: 012345678901234567890123456789일-이-삼-사-오

Ist: 01234567890123456789012345 일 이 -사 - - - Empfohlene Lösung:

DATA: f TYPE string, mo TYPE i.

AT LINE-SELECTION. GET CURSOR FIELD f MEMORY OFFSET mo. sy-lisel+mem_off(1) = '-'. MODIFY CURRENT LINE.

58

...

59

10. Glossar Byteartig Die ABAP-Datentypen X und X-STRING Code Binäre Verschlüsselung von Buchstaben, Ziffern und Sonderzeichen Codepage Auswahl der verschlüsselten Zeichen für eine ausgewählte Umgebung Datencluster Zusammenstellung mehrerer Datenobjekte (Felder, Strukturen, Tabellen) DDIC ABAP Datenverzeichnis Endian Die Byte-Reihenfolge einer Zahl wird im Speicher mit abnehmenden Stellenwerten von links nach rechts (Big Endian) oder von rechts nach links (Little Endian) abgelegt. Frontend Präsentationsserver des Kernel In den Programmiersprachen C und C++ codierte Basisfunktionalität des NUP Nicht-Unicode-Programm: Programm, bei dem das Unicodeflag nicht gesetzt ist NUS Nicht-Unicode-System: -System, in dem Zeichen binär durch 1 Byte verschlüsselt werden. Restlänge Die Restlänge eines Feldes oder einer zeichenartigen Struktur errechnet sich aus der Differenz zwischen Gesamtlänge minus Offset. Surrogate Area Zeichenergänzung für alle Zeichen, die nicht im Standard-Unicode mit maximal 64 k Zeichen enthalten sind. Zu dem Bitmuster aus dem Standard-Unicode werden zwei weitere Bytes aus dieser Area zugelesen. Unicode-Fragmentsicht Einteilung von Strukturen in gleichartige Datenbereiche UP Unicode-Programm: ABAP-Programm, bei dem das Unicodeflag gesetzt ist US Unicode-System: System, in dem Zeichen binär durch 2 oder 4 Byte verschlüsselt werden. UTF-8 Datenformat für Kommunikation und Datenaustausch XML Extensible Markup Language: Auszeichnungssprache zur Darstellung beliebiger Dokumente im Internet Zeichen Buchstabe, Ziffer oder Sonderzeichen Zeichenartig Die ABAP-Datentypen C, N, D, T und STRING

60

11. Verzeichnis der Schlüsselbegriffe Append 14

Assign 10, 11, 23, 24, 25

At 9

Byte- 22

Casting 25

Charlen 16

Clear 22

Concatenate 15, 22

Condense 15

Convert Text 15

Create Data 27, 28, 29

Datentypen 5

Describe 19, 23

Delete dbtab 18

Export 29, 30

Fetch 18

Field-Symbols 11, 17

Find 22

Generate 21

Gen. Datentypen 32

Get Bit 20

If 14, 15

Import 29

Include 18, 27

Increment 24, 25

Insert dbtab 18

Insert itab 14

Insert report 21

Loop at 14, 20

Modify dbtab 18

Modify itab 14

Move 12, 13, 14

61

62

Move-Corresponding 29

Numofchar 16

Offset 9, 10, 11

Open Dataset 19, 30

Operatoren 16

Overlay 15

Perform 10, 17

Range 10, 20, 24

Read Dataset 19

Read Table 20

Refresh 20

Replace 15, 22

Search 15, 22

Select 18

Set Bit 20

Shift 15, 22

Split 15, 22

Stringoperatoren 16

Strlen 16

Structure 17

Transfer 19

Translate 15

Update dbtab 18

Vary 21

Varying 21

Write 17

Write To 17

XStrlen 22