Keine Zeichenumsetzung zu CCSID 13488

[Fuerchau]

Hier ist auf jeden Fall eine CCSID in der DB-Tabelle erforderlich.
DBCS-Daten (wie 13488) können NICHT in ein HEX-Feld geschrieben werden (65535).
Ggf. steht auch der Job auf *HEX, so dass das deswegen nicht funktioniert.

Ändere die DB-Tabelle in eine korrekte CCSID, dann klappts auch mit dem Update.

[ah1960]

Ich kann die Tabelle nicht ändern, da sie von einem Fremdsystem als Schnittstelle zur Verfügung gestellt wird.



Wie in meiner letzten Antwort geschrieben, funktioniert die Umsetzung innerhalb eines SQLCBLLE-Programmes.
Dieses habe ich innerhalb des gleichen JOB's erzeugt und ausgeführt.

Das Problem scheint beim interaktiven SQL auf dem 5250-Bildschirm zu liegen.
Der CAST-Befehl soll ja 65535 in 13488 umsetzen.
Könnte eine Umsetztabelle fehlen?

[Fuerchau]

65535 kann nicht in UNICODE umgesetzt werden !
Hierzu ist ggf. ein Doppelcast erforderlich:

cast(cast('2222' as char(30) ccsid 273) as graphic(30) ccsid 13488)

Auf welcher Ebene ist den 65535 definiert ?

[ah1960]

Danke!
Das war der wichtige Hinweis, das 65535 nicht in UNICODE umgesetzt werden kann.

65535 wird vom interaktiven STRSQL definiert/verwendet.
Man hat keinen Einfluss darauf.
Diese CCSID 65535 hat mir schon öfters Probleme bereitet, so z.B auch beim CRTPF in die QTEMP (V5R4), musste man mit CRTDUPOBJ umgehen.

Auf jeden Fall noch mal vielen Dank!!!

[Fuerchau]

STRSQL verwendet die CCSID des Jobs !

Beim CRTPF ohne DDS ist die CCSID immer 65535, mit DDS wieder die JOB-CCSID, wenn diese 65535 ist dann eben auch für CRTPF.
Das hat mit QTEMP nichts zu tun.

Du kannst allerdings beim CRTPF ... CCSID(nnn) angeben.

[ah1960]

Der Job hat definitiv die CCSID 273.

Eine Mutmassung habe ich noch:
Sendet das Terminal die Daten in CCSID 65535 an die AS400 ?!
----------------------------------
Anmerkung zu CRTPF:

Bis (einschliesslich) V5R1 hat uns die CCSID in der QTEMP nicht interesiert. Wir haben einen CRTPF mit Satzlänge gemacht, Daten in die Datei geschrieben, diese mit CPYTOIMPF kopiert.
Ein PC-Serverprogramm hat die Daten dann weiterverarbeitet.
Auch konnte ich eine Datei mit DDS mit CRTPF mit der JOB CCSID (273) in der QTEMP anlegen.

Ab V5R4 funkoniert dies nicht mehr.
Zwar kann ich Daten in die File schreiben, aber der CPYTOIMPF setzt die Daten nicht um. Das PC-Serverprogramm konnte die Daten nicht lesen (keine Zeichenumsetzung)
Ein CRTPF mit DSS (mit PDM,Umwandlung im Stapelbetrieb = J") bringt in der Umwandlungsliste kein Fehler, es steht sogar darin, dass die Datei in der QTEMP erstellt wurde, aber sie ist definitiv nicht vorhanden. Mit interaktiven Umwandeln funktioniert das ganze.
Dieses haben wir auf mehreren Iseries festgestellt.
Wir haben diese Problematik dann aus Zeitgründen "abgehakt", da es mit CRTDUPOBJ sauber funktioniert.

[Fuerchau]

Eine QTEMP ist pro Job.
Wenn du also im Batch in die QTEMP erstellst und der Job sich beendet, ist die QTEMP wieder weg

Deshalb funktionierts ja auch im Dialog.

Möchtest du eine PF mit CCSID aber ohne Quelle, mach doch einen QMQRY:

CREATE TABLE MYTABLE (FIELD CHAR(256) CCSID 273).

Ist dann wie CRTPF mit Satzlänge.

Was ich auch gerne mache, ist eine Musterdatei mit DDS und zur LAufzeit CRTDUPOBJ / CPYF in die QTEMP.
Auch dann hast du eine CCSID.

Für den CPYFRM/TOIMPF gabs mal was mit einer DTAARA in QUSRSYS für altes Verfahren. Ob's das noch für V5R4 gibt weiß ich nicht.

[ah1960]

Das mit der QTEMP ist logisch , habe nicht nachgedacht .

Das mit der Musterdatei mache ich ja inzwischen so.

Das mit dem CREATE TABLE ist auch überlegenswert.

Vielen DANK für die Unterstützung !