-
Keine Zeichenumsetzung zu CCSID 13488
Hallo,
wer kann mir weiterhelfen ?
Ich habe zwei AS400-DB mit einem Connet verbunden. AS4001 V5R1 AS400 2 V5R3.
Ich arbeite auf AS4001 mit STRSQL.
Folgendes funktioniert:
SELECT cast(h2alid as char(30)) FROM lib1/tab1
Nicht aber:
update lib1/tab1
set h2alid = cast('222222222' as graphic(30) )
auch nicht
update lib1/tab1
set h2alid = cast('222222222' as graphic(30) ccsid 13488)
Woran kann das liegen ?
-
WAS funktioniert nicht ?
Gibts eine Fehlermeldung ?
Die Syntax ist OK, was erwartest du genau !
-
Erwartet habe ich, dass der UPDATE ausgeführt wird.
Es kommt eine Fehlermeldung , dass die CCSID 65535 nicht zu CCSID 1200 umgesetzt werden kann im 2.Fall
dass sie nicht zu CCSID 13488 umgesetzt werden kann.
Ich habe aber zwischenzeitlich dieses in ein SQLCBLLE-Programm eingebaut. Da funktioniert die Umsetzung und der UPDATE.
Das Feld h2alid ist ein UNICODE-Feld.
-
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.
-
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?
-
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 ?
-
Das war es !
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!!!
-
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.
-
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.
-
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.
Similar Threads
-
By codierknecht in forum NEWSboard SAP
Antworten: 32
Letzter Beitrag: 09-02-18, 13:00
-
By umeis in forum NEWSboard Windows
Antworten: 3
Letzter Beitrag: 11-08-06, 12:45
-
By schaaf in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 04-05-06, 11:18
-
By Muchi in forum IBM i Hauptforum
Antworten: 7
Letzter Beitrag: 21-04-06, 13:54
-
By Binford in forum IBM i Hauptforum
Antworten: 6
Letzter Beitrag: 07-03-06, 08:58
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks