View Full Version : Java-Datenbank-Treiber JT400 unter V6R1
Auf den PCs, NICHT auf der AS400 laufen mehrere unterschiedliche Java-
Anwendungen, die auf die AS400-Datenbank zugreifen.
Auf AS400 ist dzt. V5R4.
Bei Java-Anwend. sind auch mehrere Internet-Anwend. (auf Tomcat deployt- aber eben NICHT auf AS400) darunter , Rest sind
etliche Konsole-anwendungen.
Beim letzten Betriebssystem-Update 2007 auf V5R4 habe ich mich um diese
Thematik nicht gekümmert.
Zentrale "Schnittstelle" ist der Datenbank-Treiber JT400.
Gibt es Erfahrungswerte, ob Probleme durch V6R1 auftreten können?
... der Treiber ist eigentlich immer lokal installiert, sprich dort, wo die Java Anwendung läuft und da ergibt sich erst mal keine Änderung von V5R4 nach V6R1.
Wichtiger ist da erst mal ein aktuelles Patchlevel für die Datenbank.
D*B
Danke für die Info.
Da der Treiber die Daten aus der DB bereitstellen muss, wäre es grundsätzlich möglich, dass sich hier durch V6R1 etwas geändert hat. Offenbar war meine Befürchtung erfreulicherweise unbegründet.
... das ist leider nur die halbe Wahrheit. JDBC Geschäft ist komplett dynamic SQL und da kann es schon zu erheblichen Änderungen bei Laufzeit und Ressourcenverbrauch einzelner Queries kommen. Zumal da zwei Query Engines parallel wursteln und im Übergang der beiden einiges an fehlerhaften Implementierungen aufgeschlagen ist.
D*B
Was passieren kann ist, dass bis V5R4 der eine oder andere SQL akzeptiert bzw. toloriert wurde.
Ab V6R1 kann es sein, dass durch die genauere Syntaxprüfung mal was nicht mehr akzeptiert wird.
Hat man sich aber an die SQL-Syntax gehalten passiert eigentlich nichts.
andreaspr@aon.at
16-11-11, 10:00
Was passieren kann ist, dass bis V5R4 der eine oder andere SQL akzeptiert bzw. toloriert wurde.
Ab V6R1 kann es sein, dass durch die genauere Syntaxprüfung mal was nicht mehr akzeptiert wird.
Beispiel von uns (7.1)
Der Job hatte als Dezimalformat COMMA hinterlegt.
Wenn im SQL nun eine Dezimalspalte mit einer Characterspalte verglichen wurde und den Char-Wert '1234.55' enthielt (=> mit Dezimalformat PERIOD), hatte die DB bei V5R4 dennoch eine korrekte Konvertierung vorgenommen.
Bei 7.1 (und 6.1?) gibt die DB (zurecht!!) einen Konvertierungsfehler zurück.
Danke für die wertvollen Hinweise.
Ich hatte beim Wechsel auf V5R4 sogar mit einem QMQRY einen extremen Fall, wo eine Auswertung plötzlich mehr als die doppelte Zeit beanspruchte.
Hoffentlich gibt es keine Probleme mit jener Anwendung, wo die Statements vom OR-Mapper Hibernate erzeugt werden. Da hätte ich nämlich keinen Einfluss darauf.
Das andere sollte in den Griff zu bekommen sein.
Ein wenig "Bauchweh" bereiten die vielen UDFs, die aber leider notwendig sind, um die notwendigen Daten zu erhalten.
andreaspr@aon.at
16-11-11, 13:29
SP und UDFs sollten nach einem Releasewechsel generell neu erstellt werden.
Der Grund ist die Performance. Mit jedem Release können mehr Anweisungen in C-Code konvertiert werden.
Speziell Vergleichsoperationen und Wertzuweisungen könnten im neuen Release besser verarbeitet werden. (Wenn sie neu erstellt werden)
lg Andreas
Wir haben unsere Systeme mit V5R4 gegen neue i7 mit V7R1 ausgetauscht. Wir haben zahlreiche Javaapplikationen (meistens Tomcat) - aber die Treiber nicht extra aktualisert. Das ging soweit ohne problemlos.
Probleme mit nicht aktuellen JDBC-Treibern sind nicht ganz auszuschließen - aber eher die Ausnahme bei der AS/400 (da kenne ich schlimmeres z.B. Oracle).
Das Problem, dass manche Statements je nach Release unterschiedlich performen, hält sich bei der AS/400 auch in Grenzen.
Probleme hatten wir nur mit ein paar QM-Queries und erst jetzt mit dem letzten DB2 PTF Group (SF99701 #11) . Hier erzeugte die Paginglogik von Hibernate einen internen SQL-Systemfehler....
Noch zur Performance (viele Änderungen DB-Engine kamen schon mit V6R1):
Während die SQL-Eingine bei V5R4 teilweise eine "Verschlimmbesserung" war, hat mich V7R1 bislang überzeugt.
Während die nativen Cobol/RPG-Programme "nur" um den Faktor 3-4 schneller wurden, konnte ich bei SQL-Procedures/Selects, Steigerungen im Bereich Faktor 5-10 ausmachen.
(Anmerkung: wir benchmarken und protokollieren Anfragen aus dem Webshop).