Im wesentlichen gar nicht.
GRAPHIC mit entsprechender CCSID ist DBCS, wobei es DBCS gibt, die nicht Unicode sind.
Mit Einführung von Unicode (CCSID 13488) benötigt man die anderen (fast) nicht mehr.
Für Nicht-Unicode-DBCS (z.B. Japanisch) gibt es nämlich spezielle DBCS-5250, die aber leider nicht Unicode unterstützen.

Mit V7 (vielleicht auch schon V6) wurde der SQL-Typ NCHAR/NVARCHAR (N=National) eingeführt, der auch bei vielen anderen Datenbanken schon verwendet wird.
Oracle und SQL-Server speichern die Daten dann allerdings in UTF8, was zur Laufzeit halt ein paar Nanosekunden kostet, dies ständig in WCHAR und zurück zu wandeln.

Zusätzlich wird die CCSID 1200 statt 13488 verwendet.
Die 1200 gilt aber nicht als UCS2 sondern als UTF-16 (also 2/4-Bytes).
D.h., dass NCHAR tatsächlich nur ca. 32K Zeichen als 2-Bytes und alle anderen als 4-Bytes gespeichert werden, während die 13488 eben die 64K Zeichen speichert.
Solange man aber noch nicht mit Codepoints jenseits von 32K zu tun hat, passiert auch nichts, denn die vollständige Unterstützung von UCS4 gibt es auch noch nicht.

Den Unicode-Zeichensatz kann man sich in Windows mal mit der "Zeichentabelle" zu gemüte führen. Da tauchen dann ab Code x'Axxx' dann spezielle Codes auf, die in UTF16 dann 4 Bytes benötigten.

Bei der Umwandlung von UTF-16 in UCS2 gibt es aber bis zu den 64K-Zeichen noch keine Probleme und wann denn vulkanisch oder klingonisch aufgenommen wird steht noch in den Sternen.

Testen kann man das tatsächlich nur mit einer ODBC-Anwendung (Z.B. per Excel, mit MS-Query download, mit meinem Upload/400 upload) oder einer verknüpften Tabelle in Access oder SQL-Server.

Noch ein Tipp zu MS-Query:
MS-Query ist selber keine Unicode-Anwendung (selbst mit Office 2016 noch nicht) und stellt Sonderzeichen eben als Kästchen dar. Trotzdem verarbeitet Excel das dann korrekt.