Daten einer CCSID 1208 Datei lesen

[hteufl]

Hallo Spezialisten!

Wir mussten unser Archivsystem vor ca. 1 Woche aktualisieren. Datei wurde festgestellt, dass der Softwarehersteller die Datenbankdateien auf CCSID 1208 umgestellt hat (wegen Problemen bei der Stichwortsuche).
Auszug einer Beispieldatei (DSPFFD):
DOK_D00016 CHAR 250 252 3800 Beides DOK_DAT_FELD_16
Alternativer Name . . . . . . . . . . . . :
DOK_DAT_FELD_16
Feld mit variabler Län-- Zugeordnete Länge: Keine
Läßt den Nullwert zu
ID des codierten Zeichensatzes . . . . . : 1208
UCS2- oder Unicode-Konvertierung . . . . : *CONVERT
Daten normalisieren . . . . . . . . . . . : Nein


Wir müssen aber um diverse Aktenverknüpfungen zu aktualisieren bzw. um Dokumente aus dem ERP ins Archiv zu stellen die Datenbankdateien lesen bzw. auch aktualisieren können. Leider funktionieren weder die COBOL Programme mehr noch die RPG Programme.
Die COBOL Programme lesen immer nur den 1. Datensatz mit dem Filestatus 43 und die RPG Programm brechen mit einem Fehler (CPF5035 Datenzuordnungsfehler in Teildatei) ab.

Kann man COBOL bzw. RPG irgendwie dazu bringen Daten in CCSID 1208 zu lesen?

Wir arbeiten in der Betriebssystemversion V7R3M0.

Vielen Dank im Voraus

Hermann

[Fuerchau]

Da musst du die Programme wohl eher auf SQL umstellen, da die Nativeunterstützung ein Problem darstellt.
Bei ILERPG kannst du für die CHAR-Variablen eine Default-CCSID definieren, da i.d.R. deine Variablen mit CCSID(*HEX) definiert sind.
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzasd/hccsidchar.htm

CCSID(*CHAR:*JOBRUNMIX) könnte eine Option sein. Jeder Move/Eval führt zu einer Konvertierung, u.U. mit Verlust "?" wenn Zeichen inkompatibel sind.
Es kommt halt auf einen Versuch an.
Wenn der Compiler Probleme macht müssen u.U. Konvertierungen per %char(UCS2Var) oder %UCS2(CharVar) eingesetzt werden.

COBOL unterstützt ebenso Unicode.
Die Variablen müssen als NATIONAL definiert sein, was zumindest bei COPY-DDx automatisch passiert.
Problematisch sind da halt Work-Variblen, bei denen ein Konvertierung oder Neudefinition gemacht werden muss.
Default wird CCSID 13488 verwendet, mman kann mit der Umwandlungsoption NTLCCSID(1200) auch UTF16 verwenden. Dies kann auch in der PROCESS-Anwesiung in der COBOL-Quelle angegeben werden.
Für Konvertierungen in COBOL gibt es dann die Funktionen NATIONAL-OF (Char to National) und DISPLAY-OF (National to Char).

[hteufl]

Hallo!

Mein Problem scheint gelöst zu sein! Nach Rücksprache mit dem Softwarehersteller sollte es genügen in den Compileroptionen ALLNULL(*USRCTL) für die Nullfelder einzutragen und die *UTF8 Felder in neu definierte Variablen zu übertragen. In meinem Fall habe ich eine Datenstruktur mit Mehrfachvorkommen erstellt um die Datenbank zu lesen und die Daten zu verarbeiten! Die ersten Versuche haben wunderbar funktioniert. Nur erklären kann ich mir das Ganz noch nicht. Denn auch mein Versuch mit einer extern beschriebenen Datenstruktur hat NICHT funktioniert!
So wie es aussieht konvertiert RPG die Daten automatisch aber nur wenn die Felder nichts mit der Ursprungdatei zu tun haben!

Aber trotzdem vielen Dank für die tolle Unterstützung und Gesund bleiben!

Hermann

[Fuerchau]

Schau doch mal die Definition bei der Umwandlung an. Wahrscheinlich sind das CHAR-Felder mit CCSID(UTF8). Das hilft dir wirklich nicht.
Bei der Neudefinition als UCS2(nn) oder CHAR(xx) ccsid(*jobrun) werden die Daten dann für dich beim Lesen konvertiert und beim Schreiben aus der DS ebenso.

Alternativ kann man die CCSID allerdings auch auf der DS-Ebene definieren:
dcl-ds MyDs extname(MyFile) qualified ccsid(*noexact);

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzasd/rpgrelv7r2.htm