Sonstige Änderungen 

...

       1.      Bitanweisungen

1.       Addition von Feldfolgen

       2.      Schleifen mit VARY und VARYING

2.       Erzeugung von Unterprogrammen

3.       Abspeichern von Programmen

4.       Typisierung bei GET/SET PARAMETER

5.       Nicht erreichbare Anweisungen

6.       Funktionsbausteine mit falschen Parameternamen

 

1. Bitanweisungen

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.

2. Addition von Feldfolgen

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.

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.

3. Schleifen

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.

4. Erzeugung von Unterprogrammen

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

5. Abspeichern von Programmen

Bei der automatischen Erzeugung von Programmen mittels Anweisung INSERT REPORT prog FROM itab werden wie bisher Default-Werte für den TRDIR-Eintrag gesetzt. Diese Anweisung erhält unter anderem den neuen Zusatz UNICODE ENABLING uc, mit dem das Unicode-Flag des eingefügten Reports den Wert von uc erhält. Fehlt dieser Zusatz, dann wird nach folgendem Muster verfahren:

1.       Ein Unicode-Programm erzeugt ebenfalls ein Unicode-Programm.

2.       Ein Nicht-Unicode-Programm erzeugt wiederum ein Nicht-Unicode-Programm.

3.       Ein Nicht-Unicode-Programm wird zu einem Unicode-Programm, wenn es von einem Unicode-Programm Überschreiben wurde.

4.       Ein Unicode-Programm bleibt ein Unicode-Programm, wenn es von einem Nicht-Unicode-Programm überschrieben wurde.

6. Typisierung bei GET/SET PARAMETER

Bei den Anweisungen GET PARAMETER ID pid FIELD f und GET 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.

7. Nicht erreichbare Anweisungen

Nicht erreichbare Anweisungen führen in Unicode-Programmen zu einem Syntaxfehler. In Nicht-Unicode-Programmen gab dies bisher nur eine Syntaxwarnung.

8. Funktionsbausteine mit falschen Parameternamen

Der Aufruf eines Funktionsbausteins, dessen Parameternamen statisch als Literal oder als Konstante angegeben werden, führt in Unicode-Programmen 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 Nicht-Unicode-Programmen wurde ein falscher Name bisher ignoriert.