%UCS2

[Fuerchau]

Ich denke, %UCS2 ruft intern iconv() auf. Hierzu wird beim erstmaligen Aufruf die Codetabelle geladen.
Solange das Programm aktiv bleibt, ändert sich das dann wohl nicht mehr.

Alternativ verwende folgendes API:
Convert a Graphic Character String (CDRCVRT, QTQCVRT) API

Das kann das auch.

[KM]

Es scheint tatsächlich an der Aktivierung zu liegen. Ich habe dem SRVPGM2 jetzt eine benannte Aktivierungsgruppe gegeben und mache jedesmal vor dem Aufruf der betreffenden Prozedur einen RCLACTGRP und damit funktioniert's. Aber das kann ja nicht so ganz Sinn der Sache sein.

Der iconv() funktioniert ohne Probleme. Das hatte ich schon probiert. Also scheint %UCS2 nicht unbedingt was mit iconv() zu tun zu haben.

Ich denke ich werde jetzt auf iconv() umsteigen, da ich hier längere Felder verwenden kann. UCS2 erlaubt unter V5R4 ja nur 16323 Stellen.

Gruß,
KM

[Fuerchau]

Mittels iconv bildest du ja erst ein Handle um dann die Konvertierung durchzuführen.
Wenn du das Handle dann wieder freigibst, lädst du ja auch die Ressourcen später wieder neu.

%ucs2 merkt sich wohl das Handle nach dem 1. Aufruf und gibt es nicht mehr frei.

[BenderD]

... die SQL Implementierung ist genauso lausig, da kann man zwar beliebig nach CCSID vor, zurück und drumherum casten, muss die CCSID aber zur Compiletime outen (bei static SQL). Da ist der iconv scheints besser, die Handle könnte man ja auch korrespondierend zu einem Array mit CCSIDs cachen.

D*B

Mittels iconv bildest du ja erst ein Handle um dann die Konvertierung durchzuführen.
Wenn du das Handle dann wieder freigibst, lädst du ja auch die Ressourcen später wieder neu.

%ucs2 merkt sich wohl das Handle nach dem 1. Aufruf und gibt es nicht mehr frei.

[Fuerchau]

Bei ODP's (egal ob SQL oder Native) ist das ja wohl das selbe Problem.
Wenn ich zwischen Open und Close die CCSID ändere, hätte ich da auch plötzlich andere Daten.
Insbesonders wenn Daten geblockt werden ist die Codewandlung ja längst erfolgt.
Ausserdem hätte ich bei Parallelverarbeitung (SQL/Threads) ja auch noch unterschiedliche Daten, wenn mir ein Thread plötzlich die CCSID wechselt.

[BenderD]

... das hat mit ODPs und Blockung (interessiert außerhalb des AS/400 Hühnergartens niemanden, innerhalb ist es wohl eines der spannendsten Themen - vielleicht ist das auch schon der Sumpf, der von unten an den Füßen zieht...) nicht die Bohne zu tun. Open und Close ist zur Runtime und die CCSID muss in diesem Fall zur Compiletime vernagelt werden!!! Am Rande sei zum Thema Threads vermerkt: SQL Anforderungen werden immer synchronized implementiert - jede SQL Anforderung muss so abgearbeitet werden, als ob sie in einem Thread verarbeitet worden wäre und sogar so, als ob der Benutzer die Datenbank für sich alleine gehabt hätte (aber auch das wird ja im AS/400 Umfeld zugunsten von vermuteten Performance Vorteilen durch das Prinzip Hoffnung ersetzt, siehe Threads zu FRCRATIO u.ä.)

D*B

Bei ODP's (egal ob SQL oder Native) ist das ja wohl das selbe Problem.
Wenn ich zwischen Open und Close die CCSID ändere, hätte ich da auch plötzlich andere Daten.
Insbesonders wenn Daten geblockt werden ist die Codewandlung ja längst erfolgt.
Ausserdem hätte ich bei Parallelverarbeitung (SQL/Threads) ja auch noch unterschiedliche Daten, wenn mir ein Thread plötzlich die CCSID wechselt.