View Full Version : Inhalt eines Pointers ermitteln mit SQL
MyFeld char(16000000)
eval myFeld = %str(BlackboxPointer)
... da wird Dir der Rest bereits abgeschnitten und gegebenen Falls mit blanks hinten aufgefüllt. Das solltest Du schon so machen, wie von mir skizziert.
was kriegst Du denn mit %len(%str(BlackboxPointer)) ?
D*B
Hallo D*B,
ich habe jetzt einen Test durch mit der wahrscheinlich größten Nachricht und die kommt auf eine Länge von 3.487.283. Also denke ich das die 16.000.000 reichen werden.
Viele Grüße
Jörg
... ich bin mir aus dem Kopf auch nicht sicher, ob man überhaupt so ohne weiteres mehr als 16 MB zusammenhängenden Speicher auf dem Heap allokieren kann. Bei Deiner Variante mit dem %str wäre da ein varying Feld die bessere Wahl (da kann man dann auf die Länge zugreifen.
D*B
Hallo D*B,
das Feld hatte ich schon auf varying geändert. Ich denke wenn die vermeintlich größte Datei (Artikelstamm) mit 3,4MB auskommt und ich max. 16MB habe und die nicht reichen sollten, muss ich sowieso mit dem Kunden in Kontakt treten. Vielleicht kann er ohne gr0ßen Aufwand logische Einheiten bilden, die ich dann auch verarbeiten kann.
Aber nicht mehr in diesem Jahr.
Ich wünsche allen Usern einen guten Rutsch.
Jörg
Zumindest laut Doku kann man mit Teraspace max. 4GB am Stück zuordenen, im SingleLevel nur 16MB.
Allerdings bedarf es da entsprechender H-Einstellungen, damit %alloc() auf Teraspace zugreift.
Warum man dann keine Variablen >16MB (und dann auch nur im Full-Free > 1MB) definieren kann, entzieht sich mir, das hat die IBM dann wohl wieder vergessen.
Zumindest laut Doku kann man mit Teraspace max. 4GB am Stück zuordenen, im SingleLevel nur 16MB.
Allerdings bedarf es da entsprechender H-Einstellungen, damit %alloc() auf Teraspace zugreift.
Warum man dann keine Variablen >16MB (und dann auch nur im Full-Free > 1MB) definieren kann, entzieht sich mir, das hat die IBM dann wohl wieder vergessen.
... die Variablengröße ist eigentlich Banane, der Speicher ist ja schon allociert und man kriegt einen Pointer darauf ins Programm und man kann dann ja ein Fenster drüberschieben, indem man jeweils die Länge der Fenstervar auf den based Pointer draufaddiert. Bleibt noch, dass man eventuell Einstellungen für die Kompatibilität des RPG Schinkens mit dem C Programm braucht und dass man an die Länge des allocierten Speichers drankommen muss, damit man nicht in Probleme rennt, wenn man drüber hinausgreift - habe ich aber auch nicht im Kopf und würde ich nachschauen, falls ich das wirklich mal brauche (und dann würde ich wahrscheinlich gleich bei der leistungsfähigeren Programmiersprache bleiben...
D*B
und dann auch nur im Full-Free > 1MB definieren kann
Natürlich kann man auch in den Fixen D-Bestimmungen Variablen bis 16 MB definieren. Die Längenangabe wird mit Schlüssel-Wort LEN() definiert!
Birgitta
Da nun mal ILERPG native nicht mehr als 16MB für eine einzelne Variable/DS zulässt, sich per Teraspace durchaus aber 4GB am Stück allokieren lässt, kommt man dann um Pointer nicht herum.
Verwendet man SQL muss man mit LOB_LOCATOR arbeiten. Dies ist leider kein Pointer (10U) und man muss mit SUBSTR die Teildaten per SQL extrahieren, das geht auch vom bereits geladenen LOB_LOCATOR.
Bis max. 16MB kann man per SQLTYPE(CLOB:16000000) die Daten auch direkt per Fetch auslesen.
Man erhält dann eine DS mit 2 Feldern:
D*X1 S SQLTYPE(CLOB:16000000)
DX1 DS
DX1_LEN 10U 0
DX1_DATA A LEN(16000000)
so dass man in X1_LEN direkt die Länge von X1_DATA bekommt und keine zusätzlichen Funktionsaufrufe benötigt.
Ansonsten:
1 DS/Variable kann max. 16MB groß werden, aber davon kann man durchaus mehrere definieren.
Nachtrag:
Da die Quelle ja wohl XML ist und XML meist in UTF-8 daherkommt, muss man beim Laden ins CLOB auf die CCSID achten. Sonst knallt es ggf. bei der XML-Auswertung.