QZDASOINIT und OLE/DB

[raf.p]

Hallo an allen,
Dies ist mein erster Beitrag und ich bitte gleich um Entschuldigung falls mein Deutsch nicht so gut ist.Ich schreibe aus Frankreich und technische Beiträge sind gar nicht so einfach.

Ich hab ein Problem mit dem Job QZDASOINIT. Ich benutze den OLE/DB Driver DA400 von IBM über ein Dot Net Programm um die AS/400 abzufragen. Der job schickt eine große Menge SQL Instruktionen (bis 30000 und manchmal noch mehr) und nach eine weile geht der job zu „Bruch“ mit der folgenden Meldung : SQL0904, Resource limit exceeded.Type 7 indicates that the maximum size of the prepared statement area has been reached.
Dieses Problem habe ich mit OS/400 V5R1, V5R2 und V5R3.
Es sind SELECT befehle und SELECT DISTINCT befehle und ich benutze nur logical files.
Was ich schon ausprobiert habe :
Ich habe versucht so oft wie möglich den job QZDASOINIT zu erneuern in dem ich öfters die Verbindung unterbreche.
Speicher Pool *BASE und *INTERAC auf *CALC gesetzt (WRKSYSSTS),
Parameter TCPKEEPALV von CHGTCPA von 120 du 10 Minuten herabgesetzt.
Ich habe daran gedacht den Parameter MAXUSE des Befehls CHGPJE von QUSRWRK/QZDASOINIT zu ändern aber ich bin mir nicht sicher ob das irgendwie helfen kann.
Hat jemand eine Idee was ich noch machen könnte damit der job durchkommt ??

Vielen Dank für eure hilfe.
Raphaël.

[Fuerchau]

Tja, das liegt an der Art, wie ich mit den Command-Objekten bzw. Recordsets umgehe.

Wenn du viele identische Select's verwendest und nur die Where-Klausel zu ändern hast, verwende Parameter-Marker !
So benötigst du ggf. nur 1 Command-Objekt pro Abfrage-Typ.
Beispiel: "select .... where feld1=? and feld2=? ....". Jedes "?" ergibt automatisch eine Parameterobjekt, dass vor der Execute-Methode nur gefüllt werden braucht.

Wenn die Daten eines Recordset's nicht mehr benötigt werden, so sollte die Close-Methode verwendet werden und das Objekt gezielt zerstört werden (C++: delete/VB: Nothing).
Das selbe gilt auch bei anderen SQL's:
"insert into myfile (feld1, feld2, ...) values (?, ?, ...)"
"delete from myfile where feld1=? and feld2=? ..."
"call myprocedure parm(?, ?, ..."
usw.

Unter .Net werden neuerdings Resourcen über eine Garbage-Collection verwaltet, und wenn Zeit ist, diese aufgeräumt.
Erstellst du immer ein neues Command-/Recordset-Objekt (bzw. Reader-Objekt), heißt das nicht, dass automatisch alle Resourcen freigegeben werden.
Beispiel:
Im VB6 wurde mit "set myrcd = new adodb.recordset" das vorherige Objekt zerstört und das neue angelegt.
Im .NET wird mit "myrcd = new Recordset()" das alte Objekt in die Garbage-Collection geschickt und ein neues erstellt.
Also vorher "if not myrcd is nothing then set myrcd=nothing" bzw. das Äquivalent dazu.

[raf.p]

Wir sind gerade dabei den code umzuschreiben um nur prepared statements zu benutzen, aber dies ist nicht so einfach da dieser code gleichzeitig auf DB2/I5, SQL/SERVER und PERVASIVE/SQL functionnieren muss und alles getestett werden muss.

Leider drängt es mit der Zeit, deswegen suche ich eine ZwischenLösung mit der ich momentan leben kann.

Raphaël.

[Fuerchau]

Da der IBMDA400 für SQL nicht so geeignet ist, verwende den Provider für ODBC und nimm den ODBC-Treiber des CA. Dort kannst du ein SQLPKG verwenden.
Die AS/400 analysiert dann die SQL's und ersetzt Inhalte selbständig durch Parameter-Marker, so dass tatsächlich identische SQL's auch nur 1 Mal prepared werden.
Da der IBMDA400 erst ab V5R3 SQLPKG's unterstützt und es dort auch explizit definiert werden muss, wird eben jedes Statement prepared.
Wenn nun die Commandobjekte nicht korrekt freigegeben werden, kommt es eben zum Überlauf der Resourcen.

Solange man mit den SQL's im SQL92-Standard bleibt, dürften alle Befehle auch mit Parameter-Markern identisch sein.

CHGPJE ... MAXUSE(1) könnte ggf. was bringen, da der PJE dann tatsächlich beim Close der Verbindung beendet und nicht erneut wiederverwendet wird.
Allerdings gibt normalerweise der PJE-Job beim Close alle Resourcen frei. Da dies bei dir wohl nicht funktioniert (durch fehlende Objekt-Freigaben) könnte MAXUSE tatsächlich funktionieren.

[raf.p]

Besten Dank für den Typ.
Falls jemand noch Ideen über die Frage hat bin ich immer noch Interessiert.

Raphaël.

[Fuerchau]

Achte auch darauf, dass kein Connection-Pooling aktiviert ist, in diesem Fall wird die Verbindung nur logisch aber nicht physisch geschlossen.