AFP to PDF transform Zeichensatzproblem

[20141210]

Guten Tag,

wir nutzen das AS/400 Programm "AFP to PDF transform" um eine PDF Datei auf einem dänischen System (Codepage 277) zu erstellen. Die Printfile wird direkt überschrieben und als PDF ausgegeben. Die Überschreibung dazu sieht wie folgt aus:

OVRPRTF FILE(XXXXXXXXXX) PAGESIZE(29.67 20.99 *UOM) LPI(6) CPI(10) OVRFLW(72) CHRID(697 273) WSCST(*PDF) [...]

Die gesamte Anwendung, sowie alle Jobs laufen mit der Codepage 273. Allerdings steht in dem Systemwert "QCHRID" der Wert 697 (Character ID) und 277 (Codepage). Das System nutzt also den dänischen Zeichensatz.

Obwohl überall die Codepage 273 angegeben wurde, geht "AFP to PDF transform" von der Codepage 277 aus. Somit wird in dem generierten PDF Datei aus "München" ein "Månchen".

Wenn das Dokument als richtige Spooldatei ausgegeben wird, werden die Umlaute korrekt ausgegeben.

Hat jemand eine Idee, wie die Codepage von AFP to PDF transform beeinflusst werden kann?

[Fuerchau]

Der Job muss die Ziel-CCSID des Spools haben.
Zwischen Job und Device (DSPF, PRTF) erfolgt keine Codewandlung. D.h., der Spool erwartet die Daten in der korrekten CCSID.
Also CHGJOB CCSID(277) sollte dann funktionieren.

[20141210]

Hallo Fuerchau,

vielen Dank für die zügige Antwort!

Sofern der gesamte Job mit CHGJOB CCSID(277) geändert wird, funktioniert die Erzeugung des PDF's.
Allerdings haben alle anderen Dateien der Umgebung die CCSID 273. Somit bekommen wir andere Probleme, wenn wir den gesamten Job mit 277 starten.

Wir haben nun versucht vor und nach dem Aufruf des Druckprogramms einen CHGJOB CCSID(277) auszuführen. Allerdings stützt das Programm dann ab, weil Dateien verwendet, die bereits in dem Zeichensatz 273 geöffnet wurden. Eine eigene ACTGRP hat nicht funktioniert, weil der Zugriff auf die Datei über ein altes RPG Programm stattfindet.

Gibt es eine andere Möglichkeit, den Zeichensatz mitzugeben?

Wenn das Dokument als richtige Spool Datei ausgegen wird, werden die Umlaute korrekt dargestellt. Die Spooldatei besitzt dann die CCSID 273. Nun haben wir versucht die korrekte Spool mit einem CPYSPLF mit WSCST(*PDF) zu kopieren. Dies hat mit und ohne vorherigen CHGJOB CCSID(277) nicht funktioniert. Gibt es auf diesem Wege vielleicht eine Möglichkeit?

[TheDevil]

Hallo.
Vorweg muss ich gleich sagen das ich mich mit ACTGRP nicht auskenne :-) Deshalb hier mal eine
Idee die evtl. wegen der ACTGRP nicht "geht", aber vielleicht können die anderen Forumsteilnehmer
dazu mehr sagen.

Vorschlag : Auslagerung des Printjobs mit SBMJOB und DTAARA
Vor dem Aufruf des PGM eine Dtaara füllen mit "PDF WIRD ERSTELLT". Dann das PGM mit SBMJOB und der entsprechenden CCSID submitten, evtl. zu benötigende Parameter wie jobnummer etc... mit übergeben. Den aufrufenden Job in eine "Warteschleife" stellen (rtvdtaara) bis die dtaara "leer" ist. Dies wird im aufgerufenden Druckprogramm erledigt (als letzte Anweisung ... :-) ).

Wie gesagt eine IDEE und ohne Gewähr ... aber besser eine IDEE als gar keine :-)

Wünsche allen ein schönes Wochenende.

Ralf

[Fuerchau]

Gegen Ideen ist ja nichts einzuwenden.
Wenn man das Druckprogramm noch modifizieren kann, so ist die Codewandlung der Druckdaten für die betroffenen Felder relative simpel durchzuführen:

Man ergänze das Programm mit SQL und ersetzt die Move's in die PRTF-Felder mit:
exec sql set : PrtVar = cast(: PgmVar as char(nn) ccsid 277);
Leider ist das nicht dynamisierbar, da die CCSID statisch im SQL angegeben werden muss.

Man verwende das API Character Conversion:
http://www.ibm.com/support/knowledge...is/CDRCVRT.htm

Allerdings verstehe ich nicht, wieso das Druckprogramm beim Ändern der CCSID auf die Nase fällt.
Dies würde ja bedeuten, dass die benötigten Dateien des Programmes per SHARE(*YES) geöffnet sind.
Es könnte allerdings auch sein, dass man mit Filehandler-Programmen arbeitet (wird ja häufig empfohlen) und somit die Dateien bereits geöffnet sind.

Und zum Schluss:
Wieso muss die CCSID 277 sein?
Im westeuropäischen Raum Latin-1 sind alle Zeichen gemeinsam vorhanden, die CCSID 277 ist mit der 273 kompatibel.