PDA

View Full Version : GRAPHIC-Feld im RPG



CHGVAR
17-12-15, 12:55
Ich hab im Forum hier zu diesem Thema viele Informationen gefunden aber irgendwie ist der Groschen bei mir nicht gefallen. Vielleicht kann mir jemand sagen, wo der Haken ist :
Ich hab mit RTVDIRINF ein Verzeichnis im IFs ausgelesen und will den Inhalt der Datei jetzt verarbeiten. Das gewünschte Feld ist QEZOBJNAM, Datenart GRAPHIC.
Versuch 1 : mit Standard CCSID 65535 bei STRSQL : Select QEZJOBNAM from MYlib/Myfile -> lustige nicht lesbare Zeichen.
Versuch 2 : CHGJOB CCSID(37) , STRSQL + gleicher select --> QEZJOBNAM in allen Sätzen lesbar.
Versuch 3: CHGJOB CCSID(37) CALL MyPGM (Art = SQLRPGLE) unter V6
C/exec sql
C+ declare mainCursor Cursor
C+ for
C+ select qezobjnam as ONAME from mylib/myfile
C/end-exec
C/exec sql
C+ open mainCursor
C/end-exec
C DOW SQLSTT = '00000'
C/exec sql
C+ fetch next from mainCursor
c/end-exec
C EVAL VGL_FLD = %SUBST(ONAME: 1: 8)

QEZJOBNAM und ONAME sind leer.
Was hab ich nicht verstanden?

Bitte um Hilfe....

Fuerchau
17-12-15, 14:50
Diese Felder sind als Unicode definiert.
Wenn du dein RPGLE-Feld vom Typ "C" deklarierst kannst du direkt Unicode verarbeiten.
037 ist ggf. nicht korrekt wenn du auf einem deutschen System arbeitest.

Ansonsten sehe ich hier Begriffsdiskrepanzen:
QEZOBJNAM versus QEZJOBNAM?

Wenn du ein Unicodefeld im RPG in ein Zeichenfeld konvertieren willst, geht das normalerweise nur mit %CHAR(), zurück zu Unicode per %UCS2().
Ggf. deklariert der Compiler das SQL-Feld als "C" (Siehe Spool) und macht einfach einen MOVE des SQL-Feldes in deine Variable.
Dies geht so nicht.
Dafür musst du dann schon in SQL das Unicodefeld per CAST(Unicodefeld as char(nn) ccsid 273) umwandeln.

CHGVAR
18-12-15, 06:36
Guten Morgen Fuerchau,
Begriffsdiskrepanzen gibt es nur in der Nachricht, nicht im Programm. Das Feld heißt immer QEZOBJNAM. (Also tipp-Fehler meinerseits, tschuldigung)

Die Umwandlungsliste des Programms weist das Feld als :
1200 *VAR C 5 1030 QEZOBJNAM
QEZOBJNAM C(512)
VARYING(2)
CCSID(13488) aus.
Select ist jetzt so :
select CAST(QEZOBJNAM as CHAR(512)) as oname
from mylib/myfile
CCSID auf 273 geändert-----Ergebnis wie vorher :
bei STRSQL ONAME lesbar, im RPG ausgeführt ist das Feld leer.
Bitte noch mal um Hilfe.

Fuerchau
18-12-15, 07:35
Du hast da was vergessen:
CAST(QEZOBJNAM as CHAR(512) ccsid 273)

Schau dir mal im Compiler-Listing die generierte SQLnnnn-Variable an sowie den "Move" nach dem Fetch.
Die Variable kannst du auch im Debugger ansehen.

Wie hast du deine Hostvariable deklariert (Type C oder leer oder extern)?

B.Hauser
18-12-15, 08:04
Wohin werden die gelesenen Felder überhaupt ausgegeben?
Im Fetch in Deinem Beispiel ist nichts zu sehen.
Bitte den Fetch mit Ausgabe-Feldern und den zugehörigen D-Bestimmungen für die Ausgabe-Felder angeben.
Normalerweise konvertiert SQL schon richtig.
Wenn Du im SQL einen expliziten CAST auf entweder VARCHAR(Länge) (in RPG LängeA Varying) oder VARGRAPHIC(Länge) CCSID 13488 machst (in RPG LängeC Varying), wird das Ganze auch korrekt konvertiert und in die RPG Variablen ausgegeben.

CCSID 65535 läst sich meist nicht konvertieren.

Birgitta

CHGVAR
18-12-15, 08:46
Hallo B.Hauser/Hallo Fuerchau
jetzt tuts :-)
ONAME S 1024C varying
....
select CAST(QEZOBJNAM as CHAR(512) ccsid 273)
...
fetch next from mainCursor into :ONAME
ONAME ist lesbar gefüllt
Vielen Vielen Dank...

Fuerchau
18-12-15, 09:15
Wenn deine variable vom Typ C ist, ist der CAST im SQL überflüssig da das Quellfeld doch vom Typ C ist!
Mir entzieht sich da, was du falsch machst.

CHGVAR
18-12-15, 09:41
Ich hab den CAST beim select jetzt wieder rausgenommen und QEZOBJNAM ist immer noch gefüllt.
Liegt das Geheimnis vielleicht daran, dass ONAME nicht mehr im select als as-Feld
sondern im fetch into angegeben ist ?

Fuerchau
18-12-15, 10:04
Eine Umbenennung eines Feldes ist beim embedded SQL meist irrelevant.
Sie ist halt nur bei "CTE" und "derived" Table zur Identifizierung nötig.
Beim Fetch zieht ausschließlich die Reihenfolge der Felder zum Ergebnis-Select.