Unicode-Umstellung

Unicode-Umstellung

Moin,

ich frag ja selten, aber wenn, dann richtig

Was muss man wissen um eine Unicode-Umstellung durchzuführen?

Was sollte man gelesen haben?

Wie ist die grundsätzliche Vorgehensweise bei der Umstellung?

Was ist zu beachten / Welche Probleme sind zu erwarten?


Ralf *dankbar für Antworten und hilfreiche Links - je ausführlicher umso besser

RSUNISCAN ist in aktuellen Releases anscheinend durch RSUNISCAN_FINAL ersetzt. Jedenfalls ist das der Report, der in 6.20 und 7.00 hinter Transaktion UCCHECK hängt.

Informationen findet man erst mal unter "ABAP und Unicode" auf help.sap.com, dann natürlich in der F1-ABAP-Schlüsselwort-Hilfe und unter https://service.sap.com/sap@unicode (oder war's unicode@sap?).
Man sollte aber keine Probleme mit Englisch haben.

Was man wissen *muss*, hängt von vielem ab. (Nicht nur davon, womit der Kunde sich zufrieden gibt...)

Mit welchem Release soll die Unicode-Umstellung erfolgen?
Welches Ausgangasrelease ist momentan im Einsatz?
Sollen erst mal nur die Programme unicode-fähig gemacht werden, oder soll die DB nach Unicode "migriert" werden?
Wie viele verschiedene Anmeldesprachen werden im System genutzt? Nutzen diese Sprachen alle die gleiche Standard-Codepage?
Wie groß ist die DB?
Welche exotischen SAP-Komponenten sind im Einsatz?
(Die selten genutzrten Programme könnten zwar frei von Unicode-Syntaxfehlern sein, aber zur Laufzeit Unsinn produzieren.)
Wie viele nicht Unicode-fähige AdddOns von Drittanbietern sind im Einsatz?
(Unicode-Fähiggkeit heisst nicht nur, das Unicode-Flag der Rahmenprogramme ist gesetzt und es gibt trotzdem keine Syntaxfehler.)
Oder geht es um die Umstellung eines AddOns, das an Kunden ausgeliefert wird?
(Vie viele Kunden, welche Releases, ...)
Wie viele Eigenentwicklungen gibt es?
(Anzahl Rahmenprogramme und Includes, Anzahl Quelltextzeilen?)
Wie alt sind die Eigenentwicklungen?
(Früher gab es z.B. keine typisterten FORM-Schnittstellen.
Und als es sie gab, wurden oft weiter nicht typisierte FORM-Parameter genutzt.)

Insbesondere nicht typisierte Schnittstellen führen zu massenhaft Warnungen.
Nicht alle davon kann man getrost ignorieren.

Und manche Unicode-Syntaxfehler deuten darauf hin, dass der Code eigentlich auch schon in Nicht-Unicode-Systemen nicht funktioniert haben kann.
(An eine FORM wird eine mit Bezug auf Typ A definierte Struktur übergeben, der formale Parameter ist aber mit Bezug auf Typ B definiert...
So etwas hält dann schon etwas länger auf al bei DESCRIBE FIELD ... LENGTH ... zu prüfen, ob da ein IN CHARACTER MODE oder IN BYTE MODE hin muss.

Hat schon jemals jemand obsoleten code aus der Eigenentwicklung entsorgt?
(Insbesondere in Uralt-Programmen, Altdaten-Übernahme ... findet sich haufenweise nicht unicode-fähiger Code, den man am besten entsorgt.
Wenn man weiß, wie man nicht benötigten Code identifiziert, kann man *erheblich* Aufwand sparen.)

Wie viele Schnittstellen mit welcher Art von externen Systemen gibt es?

Man sollte wissen, was Big-endian und Little-Endian meint, was Alignment-Lücken sind, wie die verschiedenen Unicode-Kodierungen funktionieren.

Dann sollte man, wenn man selbst den Quelltext anpassen oder andere bei der Anpassung unterstützen soll, fit in allen möglichen exotischen Syntax-Varianten sein.
(Wer weiß schon, dass man in Nicht-Unicode-Programmen in eine mit OPEN DATASET ... FOR INPUT geöffnete Datei auch schreiben kann?
Oder dass der Dateiname in Nicht-Unicode-Programmen am ersten Leerzeichen abgeschnitten wird?)
Welcher der Zusätze IN TEXT MODE bzw. IN BINARY MODE in Nicht-Unicode-Programmen der Default ist, und ob FOR INPUT oder FOR OUTPUT Default ist?
(In der Doku veralteter Releases wird man da noch fündig, in der aktuellen Doku m.E. nicht mehr.)

Und manchmal macht auch SAP Fehler bei der Umstellung.
Nich immer hilft also bei der Anpassung des eigenen Quelltextes, wenn man prüft, wie SAP ein Problem gelöst hat.