Unicode / UTF-8 Streamfile lesen

[dschroeder]

OK,
jetzt habe die Lösung ohne die zusätzliche Text-Variable:

dcl-proc UM_StmfToStrUni export;
   dcl-pi *n varucs2(300000);
      file varchar(2000) const;  //file incl. Pfad
   end-pi;


dcl-s clobFile sqltype(DBCLOB_FILE);
dcl-s clobDS sqltype(dbclob:300000) ccsid(1200);


clobFile_Name = %trim(file);
clobFile_NL   = %len(%trim(clobFile_Name));
clobFile_FO   = SQFRD;  //Read Only


exec sql set :clobDS = :clobFile;


if clobDS_len > 0;
   return %trimr(%subst(clobDS_data:1:clobDS_len));
else;
   return %ucs2('');
endif;


end-proc;

Ich werde jetzt mal verschiedene Tests durchführen, ob auch alle Zeichen korrekt gelesen werden.

[Fuerchau]

Ich arbeite da ein wenig anders.
Als Returnwert verwende ich grundsätzlich einen Indicator, so dass ich die Funktion direkt im IF aufrufen kann:

dcl-pr GetFile ind;
FileName varucs2(256) const;
Record varucs2(8000000);
end-pr;

if GetFile(FileName:Buffer);
// Tu was
endif;

Den Puffer übergebe ich nicht per CONST sondern per Referenz. Somit spare ich mir auch das Kopieren des Inhalts noch mal im Return. Der Parameter ist ebenso Ziel des SQL's.

Somit vereinfacht sich auch das Ergebnis:

exec sql .....
return SQLCODE = *zero;

Wichtig ist natürlich, dass die CCSID der Streamfile umwandelbar ist. Ich habe in einer einderen Anwendung bei einem Fehler, da ich UTF8 erwarte, noch mal den "CHGATR OBJ(...) ATR(CCSID) VALUE(1208)" durchgeführt und den Import wiederholt.

[dschroeder]

Ich hatte eben auch schon einige Probleme mit den CCSIDs meiner Testdateien. Aber es scheint zu laufen.

Das mit der Parameterübergabe per Referenz hat für mich den Nachteil, dass das rufende Programm eine exakt passende Variable bereitstellen muss. Wenn ich den Dateiinhalt als Rückgabeparameter zurückgebe, kann ich direkt die Zuweisung in eine (kleinere) Variable durchführen, z. B. in ein Bildschirmfeld.

Nochmal danke für eure Hilfe.

[Fuerchau]

Das prüft der Compiler über haupt nicht.
Ich hatte schon des öfteren mal Tippfehler bei der Übergabe von DS'n an eine Prozedur. Das hat den Kompiler in keinster Weise gestört ob die DS'n gleich lang definiert sind, geschweige, dass auch noch die Struktur der DS geprüft wurde.
Bei Single-Variablen magst du Recht haben.
Allerdings ist es korrekt, dass die Maximalgröße dann vorgesehen werden muss, aber auch das ließe sich per Parameter (wie bei API's auch) definieren.

[dschroeder]

Ich hätte da ein paar Bedenken. Selbst wenn der Compiler es durchlässt: Besteht nicht die Gefahr, dass man in Speicherbereiche anderer Variablen eingreift? (Wenn man noch weitere Parameter hat)

Aber vielleicht passt es.

[Fuerchau]

Natürlich besteht da die Gefahr, allerdings prüft ja der Compiler bereits nichts, so dass Überschreiber schon immer möglich sind.
Das Schlüsselwort CONST verhindert nur zur Compilezeit ein Überschreiben durch Fehlermeldungen, allerdings nicht den Zugriff auf falsch definierte Speicherbereiche.
Da ein Serviceprogramm ohne Änderung des Aufrufers erneuert werden kann, merkt die Laufzeit hier nichts, da es keine Signaturprüfung gibt.

[Rainer Ross]

Hallo Dieter,

kleiner Tipp mit rtnparm geht es noch etwas schneller

dcl-pi *n varucs2(300000) rtnparm; 

Herzliche Grüße
Rainer Ross

Webanwendungen auf IBM i so schnell wie Greescreen - Hier klicken und testen
http://www.myhofi.com/tms/HTML/MySubfileApp.html

Selektion Umsatz, Kredit und Saldo geht über < oder > oder <= oder >=
siehe https://docs.webix.com/datatable__filtering.html#number

[dschroeder]

Vielen Dank. Dass mit rtnparm kannte ich noch nicht. Trotz des Nachlesens in der RPG Reference bin ich mir noch nicht ganz sicher, was es tut. In der Referenz steht, dass es Vorteile hat, wenn die realen Rückgabewerte klein sind. Dann wird wohl weniger Speicher benötigt. Die Frage ist, ob es immer funktioniert.

[andreaspr@aon.at]

Hi Dieter,

eigentlich ist der Vorteil dann, wenn die Rückgabewerte groß sind.
Normal wird eine Kopie beim Returnwert erstellt. Beim RTNPARM wird lediglich die Speicheradresse (Pointer) vom Wert zurückgegeben.
Das ist dann am schnellsten.

lg Andreas

[Fuerchau]

Dann les dazu mal die Beschreibung:

The RTNPARM keyword specifies that the return value of a procedure is to be handled internally as a
parameter of the same type as the defined returned value, passed by reference.

Da der zusätzliche Parameter unbenannt ist, lässt er sich also nicht direkt ansprechen.
Die Wirkung entfaltet sich erst, wenn man ein Ergebns im Return spezifiziert, da dieses dann nicht in einer Zwischenvariablen sondern direkt übergeben wird.

Es bringt aber keinen Vorteil, wenn man sowieso eine benannte Variable benötigt die dann beim Return den Wert doch wieder kopieren muss.
Ansonsten: laut Doku bringt es besonders bei großen Returnwerten etwas, da der automatische Speicher dadurch nicht belastet wird.

Zu beachten sind aber besonders die Hinweise bzgl. %PARMS und %PARMNUM, da diese Funktionen den Wert um 1 größer melden.

[BenderD]

... das ist wieder so eine typische RPG-Denke. Das sind auf heutigen Rechnern nicht mal Mikrosekunden, die man da vermeintlich einspart und den eigentlichen Pferdefuß übersieht man: die RTNPARM Arie verhindert caching, was in vielen Fällen mehr bringt. Was Speicher sparen angeht: das verträgt sich nicht mit der zunehmenden Verfettung der RPG Runtime durch Gimmicks wie dynamische Feldgruppen (hier sei am Rande erwähnt, dass es schon seit langem Open Source Komponenten gibt, die das besser können).

D*B