65k Dateifeld oder wie lese ich eine Datei direkt aus dem IFS ein.

[Fuerchau]

Ich wollte aber LOB-Locator vermeiden, da diese ja wieder Commitsteuerung erfordern.

[B.Hauser]

Nochmal zum Mitschreiben!

Wenn man im embedded SQL LOB-File-Referenz-Variablen (z.B. SQLTYPE(CLOB_FILE)) verwendet und nur mit SQL darauf zugreift kann man bis zu 2 GB große IFS-Dateien verarbeiten und braucht KEINE Commit-Steuerung!

DCL-S MyCLOBFile SQLType(CLOB_File);                                 
  DCL-S MyText     Char(50);                                           
 //********************************************************************
  Exec SQL   Set Option  Commit=*NONE, DatFmt=*ISO, TimFmt=*ISO,       
                         Naming=*SYS,  CloSQLCsr=*EndActGrp;           
                                                                       
    MyCLOBFile_Name = '/home/Dir1/Dir2/YourIFSFile.txt';               
    MyCLOBFile_NL   = %Len(%Trim(MyCLOBFile_Name));                    
    MyCLOBFile_FO   = SQFRD;                            //Read Only    
                                                                       
    Exec SQL Set :MyText = Substr(:MyCLOBFILE, 1, 50);       
    //Check SQLCODE or SQLSTATE

    Dsply MyText;      
    *InLR       = *On;

Birgitta

[Fuerchau]

Ich habe ja auch nichts gegenteiliges beschrieben:
Mit CLOB_FILE benötige ich keinen Commit, wenn ich keinen LOB verwende.
Lese ich CLOB_FILE in einen LOB ein, geht das wieder nur mit Commit.
Will ich mehr als 16MB in ILERPG lesen, klappt dies per SUBSTR(: MyClobFile, 8000000, 8000000).

[harkne]

Ich habe folgenden SQL Befehl ausgeführt

Insert into leasd/www_in3
Values(Get_CLOB_from_file('/leasing/tmpxml/test/lskopie.xml'))
1 Zeilen in WWW_IN3 in LEASD eingefügt.

Hat funktioniert.

Den gleichen Befehl mit meinem anderen Benutzerprofil und er bringt den Fehler den ich oben beschrieben habe.

Weiß jemand an was das Problem liegt, den es funktioniert ja, zumindest mit meinem ersten Benutzer

WICHTIG!
Natürlich löst das für uns erst mal nur das Problem bis 65k. Denn es gibt ja heute schon viele Programme die einen RPG-Parser verwenden und diesen wollten wir im ersten Schritt nicht austauschen. Der Verarbeitet ja nur einen String. Mit den SQL-XML-Anweisungen die Frau Hauser mir gezeigt hat, habe ich ein Programm bereits umgestellt was auch läuft, allerdings etwas Performance-Probleme hat. Aber es funktioniert. Wenn aber jetzt riesige Dateien kommen. Was für Lösungsvorschläge hätten sie dann? Wie oben beschrieben die einzelnen Blöcke einlesen oder so wie ich in einem bereits existierenden Programm, direkt aus dem IFS mit den SQL-XML-Anweisungen die Daten einlesen (also mit View der die Daten aufbereitet und ich lese im RPG den View).
Was machen Sie bei riesigen XML-Dateien?

Vielen Dank für die Hilfe.

Viele Grüße Harald

[geschi_01]

Hallo, ich bin der Kollege , der mit diesem Problem betraut ist .
Nochmals zur Problemstellung . Wir haben einen Prozess , der XML-files aus einem Verzeichnis lädt und weiterverarbeitet . Die Programme verarbeiten bisher eine max. Feldlänge von 30000 Stellen. diese wird seit neustem überschritten , die Datenmenge wurde größer , so dass heute mit einer Feldlänge von über 30000 mit bis zu 48000 Stellen zu rechnen ist . um die Struktur und Logik der Programme nicht zu ändern , möchten wir die Parmlänge auf 65535 erweitern und intern , im ILE , mit der maximalen Feldlänge arbeiten . Dazu benötigen wir diese CLOB-funktion , die es uns ermöglicht über die maxmimale Feldlänge von Feldern zu arbeiten.
Die idee war und ist , in der Datenbibliothek eine neue File mit einem CLOB-Feld zu erstellen, dessen länge auf 65535 zu limitieren und mit SQL in einem SQLRPG-Programm , embedded , die XML-file zu laden , den Datenteil zu speichern und an ein RPG-Programm mit ParmLänge 65535 weiterzureichen , für die weiterverarbeitung . Leider scheitern wir daran , dass der insert in die CLOB-File nicht funktioniert, das weiterreichen an das RPG nicht möglich ist . wir erhalten die Meldung , wie oben beschrieben .

habt ihr eine Idee woran dies liegen kann ?
wir benötigen die Daten einfach nur im RPG in 65535..

[Fuerchau]

Die maximale Feldlänge im ILERPG beträgt 16MB! Solange also diese Länge nicht überschritten wird, gibt es kein Problem mit XML-INTO.
Außerdem löst der LOB das Problem der Verarbeitung ja immer noch nicht, da größere Dateien als 16MB immer nur per SUBSTR verarbeitet werden können.

XML-INTO erlaubt aber auch das teilweise Verarbeiten mit XPath.
Mit der Option "path=...." kannst du dir Teile aus einer XML extrahieren, so dass die 16MB-Grenze nicht gesprengt wird.

Was den Insert in die Datei angeht, so muss es dazu Fehler im Joblog geben. Stelle das Programm mal unter STRDBG, dann gibts ggf. erweiterte Diagnose.
Du kannst mit Embedded SQL auch "Get Diagnostic" zum SQLSTATE erweiterte Fehlermeldungen auslesen.

[geschi_01]

wir haben dies direkt im SQL getestet .. ohne Commit ..
die 16 MB sollten nicht überschritten werden ...

Habt ihr ein Beispiel , in dem ich die XML lade und deren Daten an ein RPG - Programm als einen String weiterreichen kann ? würde ein direktes laden , mit SQL in ein im RPG definiertes Feld mit der Länge 65535 auch funktionieren ?

[B.Hauser]

Wenn wir immer noch beim gleichen Problem sind und der andere Benutzer weiterhin den folgenden Fehler bekommt:
1 -- Das externe Programm oder Serviceprogramm hat SQLSTATE 42926
zurückgegeben. Die vom Programm zurückgegebene Textnachricht ist: LOB- und XML-Lokatoren sind mit COMMIT(*NONE) nicht zulässig.

... liegt es daran, dass in der Umgebung des Benutzers nicht unter Commitment Control gearbeitet wird.

Versuch doch einfach mal am Ende des INSERT Statements WITH CS hinzuzufügen.
Dann sollte das Insert Statement auch bei dem anderen Benutzer unter Commimtent Control ausgeführt werden, auch dann wenn in dieser Umgebung ohne Commitment Control gearbeitet wird.

Da das INSERT-Statement bei Dir funktioniert, gehe ich davon aus, dass die Tabelle in einem Journal hinterlegt ist.

Für die Verarbeitung in RPG würde ich für einen "kleinen" CLOB (65535 Zeichen) eine CLOB-Variable definieren und dann die Daten mit einem SELECT ... INTO, SET oder VALUES(...) INTO in diese CLOB-Variable ausgeben.

DCL-S  CLOBVariableName  SQLTYPE(CLOB: LängederCLOBVariablen)

Die CLOB-Variable wird vom SQL-Precompiler in eine Datenstruktur konvertiert, mit den folgenden Unter-Feldern:
CLOBVariableName_LEN UNS(10) => Datenlänge
CLOBVariableName_DATA (CHAR (LängeDerClobVariablen)) => Daten

Mit dem CLOBVariableName_DATA-Unter-Feld kann man in RPG ganz normal arbeiten und u.a. die Daten als Parameter an die nächste Prozedur durchreichen.

Was vielleicht noch zu bedenken wäre. Bei dem Datentypen XML handelt es sich um keinen String, sondern um eine interne Representation des XML.
Wenn Du das XML als Text (bzw. in RPG als CLOB) brauchst, musst Du das XML zunächst mit XMLSERIALIZE konvertieren.
Wenn Du das XML, so wie es ist in RPG übernehmen willst musst Du die Variable mit dem Datentypen XML_CLOB (und Länge) definieren. Auch hier wird eine Datenstruktur mit den beiden Unterfeldern _LEN und _DATA gebildet ... und _DATA wann mit RPG verarbeitet werden.

Birgitta

[geschi_01]

wir arbeiten ja nicht unter commit , dass ist ja was wir nicht verstehen ...
ist im RPG , die verwendung und nutzung von CLOBs zwingend mit comit verbunden ? gilt dies auch für das direkte SQL ?
habs mit With CS probiert und funktioniert nicht , die Tabelle wird nicht journalisiert , zur Info ...

[Fuerchau]

Wir die Doku schon sagt, LOB's (CLOB/BLOB) setzen Commit-Control voraus. Beim Insert in die Tabelle muss diese journalisiert werden.

[geschi_01]

Dank eurer Hilfe und Unterstützung , vor allem auch von Britta , konnten wir zwischenzeitlich , die Daten aus dem IFS , qualifiziert in eine CLOB-Definierte File laden . Wir haben , nativ ( direkter SQL-Aufruf ) , auch von einem Fileserver , entsprechende XML-files laden und weiterverarbeiten können .
In einem SQLRPG ( embedded ) , klappt der Aufruf , mit entsprechendem qualifiziertem VALUE auch ohne Probleme . siehe hier das Beispiel :
exec sql insert into xx.xx values(get_clob_from_file('/home/geschi/test/clob/xxxxxxx.xml'))
wenn die file aber auf einem fileserver liegt , dessen pfad und filebezeichnung über 100 stellen lang ist, muss der Pfad mit einer Variablen angegeben werden. den pfad mit der entsprechenden File, können wir zusammenknoten. nur wie fügen wir, den Pfad als variable mit variabler länge korrekt in den SQL-Aufruf ein?
danke vorab für eure Hilfe.

[geschi_01]

und noch eine weitere Frage , wie debugge ich das SQLRPG , um die SQL-Anweisung zu prüfen und schrittweise den Programmfortschritt zu prüfen . mit *source in den PRE-compiler , hatte ich lediglich die RPG-Anweisungen prüfen können und , da der aufruf interaktiv erfolgte , im LOG einige Infos ...