Take care of UniCode z/OS Table and DB2

Hallo zusammen,
vielleicht ein interessanes Phänomen. Folgende Situation :

1) Ein DB2 System (Catalog) und Bibliotheken wurde von einer LPAr auf eine andere kopiert. Verwendet wurde DFDSS Dump/Restore mit einem nachgelagertem Binary FTP von Host to Host.

2.) Das System wurde auf der neuen LPAR restored und lauffähig gemacht.

3.) Es sollte eine DB2 V8 Migration von CM auf NFM durchgeführt werden. Die ImageCopy brach ab. Alle Statements die nach dem
COPY TABLESPACE xxx.yy aufgeführt wurden wie z.B. LOG NO etc. wurden nicht erkannt bzw. als Fehler ausgegeben.

4.) Uns gelang der Job erst als wir eine bereits auf der LPAR existierende DB2 Loadlib verwendet haben.

5.) Für die Umstellung läuft ein Check für den Catalog auf die Daten und die dazugehörigen Indizes (DSNTIJCX). Dieser verlief mit der lokalen Loadlib problemlos.

6.) Der Umstellungsjob : DSNTIJNE brach bei dem Reorg für die DSNDB06.SYSVIEWS ab mit Fehlern (Rids) auf einem Index. Ein nachgelagerter Check wie unter Punkt 5 zeigte auf einmal auch
Probleme mit dem Index.

7.) Ein Rebuild Index verlief erfolgreich, jedoch fehlten nun Daten !!

Diese Aktion konnte mehrfach reproduziert werden.

Es stellte sich herraus das es Unterschiede in der Unicode Definition im z/OS gab. So hatte die original Installation eine CodePage von 273. Die target installation arbeitete mit 1141. In der Übersetzungstabelle existierte jedoch keine übersetzung von 273 nach 1141. Mit dem Befehl D UNI,ALL läßt sich die entsprechend anzeigen.

Ich nehme an das ist unser Problem gewesen. Allerdings ist das Verhalten auch sehr bemerkenswert. Der Check konnte das Problem offensichtlich nicht erkennen, da Daten gelesen werden, jedoch keine Übersetzung erfolgte. Auch bei dem Verhalten mit dem Loadmodul muss eine Veränderung zur Laufzeit/Ladenzeitpunkt geschehen sein, zumal keine weiteren Parameter gefunden wurden.

Wir werden auf der Test LPAR nun eine neue Ãœbersetzung einstellen und erneut testen.