Java auf iSeries

[Ottersberg]

qsh cmd('java -classpath "/QIBM/ProdData/Java400/jdk14/bin:/MyPath" MyMainClass')

habe jetzt folgendes ausprobiert:

qsh cmd('java -classpath "/QIBM/ProdData/Java400/jdk14/bin:/Java" hello.jar')

Klasse nicht gefunden

Zum Ausführen eines Jar-Files brauche ich ja den Zusatz -jar.
Wir sind dann direkt in die QShell gewechselt und haben dort die Befehle direkt eingegeben.

java -jar -classpath "/QIBM/ProdData/Java400/jdk14/bin:/Java" hello.jar

Programm wurde mit einem $ beendet, aber keine Ausgabe.

Habe dann lokal bei mir das mal ausprobiert und unter java -? gesehen, dass -jar hinter die anderen Argumente kommt, also:

java -classpath "/QIBM/ProdData/Java400/jdk14/bin:/Java" -jar hello.jar

Programm wurde mit einem $ beendet, aber keine Ausgabe.

Bin dann per cd in den Ordner Java gewechselt und hab folgendes ausprobiert:

java -classpath "/QIBM/ProdData/Java400/jdk14/bin" -jar hello.jar

Programm wurde ausgeführt und Ausgabe erschien.

Bin dann wieder per cd nach oben gewechselt und hab folgendes probiert:

java -classpath "/QIBM/ProdData/Java400/jdk14/bin" -jar /Java/hello.jar

Programm wurde ausgeführt und Ausgabe erschien.

Habe dann mal den classpath komplett weggelassen, also:

java -jar /Java/hello.jar

Programm wurde ausgeführt und Ausgabe erschien.

Ein

qsh cmd('java -jar /Java/test.jar')

brachte dann auch außerhalb der QShell den gewünschten Erfolg.

Der Ordner "Java" muss aber immer mit angegeben werden. Ohne den geht es nicht.

[Ottersberg]

Ich habe ein erstes Programm für ein einfaches Lesen und Ausgeben von Daten geschrieben. Es wird je eine Tabelle der iSeries und des MSSQL-Servers gelesen und auf der Konsole ausgegeben. Lokal bei mir auf dem Rechner funktioniert das. Auf der iSeries kommt keine Verbindung zum MSSQL-Server zustande. Es kommt die Meldung:

com.microsoft.sqlserver.jdbc.TDSChannel enableSSL
WARNUNG: TDSChannel ( ConnectionID:1 TransactionID:0x0000000000000000) SSL handshake failed: null
com.microsoft.sqlserver.jdbc.SQLServerException: Der Treiber konnte keine sichere Verbindung mit SQL Server über die SSL (Secure Sockets Layer)-Verschlüsselung herstellen. Fehler: null.

Im ConnectionString habe ich extra ein "encrypt=false" hinzugefügt, was eigentlich bewerkstelligen soll, dass kein SSL erforderlich ist. Weiß da jemand Rat, da es sich ja scheinbar um eine spezifisches Sache der iSeries handelt.


Weiterhin scheint das mit dem Classpath irgendwie nicht zu klappen. Egal ob ich die Systemvariable unter WRKENVVAR setze oder -classpath beim Aufruf übergebe, es wird scheinbar immer ignoriert. Die Datenbankverbindungen klappten erst, als ich die entsprechenden jar-Files in den Ordner QIBM\ProdData\OS400\Java400\jdk\lib\ext kopiert habe. Dort wird ja halt standardmäßig nach Dateien gesucht.


Außerdem wollte ich Fragen ob der Geschwindigkeitsunterschied zwischen iSeries und lokal stimmt. Lokal brauche mein Programm etwa 4 Sek. Auf der iSeries etwa 60 Sekunden für das Auslesen der iSeries-Daten und dann etwa nochmal 60 Sekunden bis zum Programmabbruch beim Versuch die Verbindung zum MSSQL-Server herzustellen. Oder liegt das daran, dass er die jar-Dateien suchen muss?

[Fuerchau]

jar's sind wie Verzeichnisse zu sehen.
Sie gehören also in den Classpath hinein:

java -classpath "/QIBM/ProdData/Java400/jdk14/bin:/Java/hello.jar" Hello

"Hello" wenn dies deine Main-Klasse ist.

Desgleichen gehören auch die Treiberkomponenten für den JDBC-Treiber in den classpath.

Ich mache z.B. eine Verbindung zu einer Oracle-DB mit:

"...:/Home/Fuerchau/Java/Driver/classes12.zip"

somit findet er den Treiber in der classes1.zip (auch hier wieder wie ein Verzeichnis).

Was die SSL-Verschlüsselung angeht, so bestimmt ggf. der SQL-Server, dass SSL nötig ist.
Hierfür sind bestimmt doch einige Konfigdateien in deiner Eclipse-Umgebung vorhanden, die du auch ggf. in dein Home-Verzeichnis auf der AS/400 kopieren musst.

Ohne SSL wird mit Sicherheit ein anderer Port für die Verbindung mit dem SQL-Server einzustellen sein.

Was die Geschwindigkeit angeht, so gibt es viele Faktoren.
Ich kann mit Java und SQL aus der AS/400 relativ schnell Daten lesen, das Schreiben nach Oracle dauert dafür etwas länger, so dass ich ca. 1000 Sätze pro Minute übertragen kann.
Hier könnte das Netz, die Leitung oder auch Oracle Schuld haben.

Die 60 Sekunden bis zum Abbruch liegen ggf. am ConnectionTimeout.

[Ottersberg]

jar's sind wie Verzeichnisse zu sehen.
Sie gehören also in den Classpath hinein:
java -classpath "/QIBM/ProdData/Java400/jdk14/bin:/Java/hello.jar" Hello.

Da hab ich jetzt wieder was dazu gelernt. Ich wußte nicht, dass man das bis auf die Datei nach unten angeben muss. Ich dachte immer der Ordner würde reichen.

Hallo,

ad java, javac, ...
- das steht in jeder Java Doku drin (Tooldocs)
- einen guten Einsteiger Kurs hier:
Java Einfuehrung - Kursunterlage
- soweit es As400 Spezifika gibt, findet man die hier:
http://publib.boulder.ibm.com/infoce...zaha/rzaha.pdf

ad oracle und co:
auch das ist kein Hexenwerk, was stimmen muss ist classpath, Treibername und url (und die Versionen von Treiber Datenbank und Java müssen passen).
Auch hierzu gibt es wie überall im Bereich Java massig Information (mit Tutorial und JDBC mr. Google fragen) und die Doku des Treibers enthält neben den Infos über url und Treibername auch elementare Beispiele.
Im übrigen ist es sinnvoll bei solchen Fragen ein wenig Code mit beizufügen, damit man sieht, wos klemmt.

mfg

Dieter Bender

Danke dir. Ich werd mir das mal ansehen. Ich hatte zu dem Thema AS/400 auch noch das Redbook "Building Java Applications for the iSeries Server" gefunden. Ist zwar schon was älter hatte aber doch ein paar nützliche Hinweise.



Ich möchte aber nochmal zur Geschwindigkeit kommen. Die hat sich nicht verbessert.

Die erste Ausgabe "Inhalt der AS/400" kommt nach 30 Sekunden.
Die zweite Ausgabe "Treiber geladen" nach 60 Sekunden gefolgt von der Datenbankausgabe und der Ausgabe "Inhalt von MSSQL".
Die Ausgabe "Treiber geladen" und die zweite Datenbankausgabe dann nach 90 Sekunden.
Die Tabellen sind identisch und haben jeweils 23 Zeilen.

Ich starte das mit folgendem Befehl:

java -classpath "/QIBM/ProdData/HTTP/Public/jt400/lib/jt400.jar:/Java/jtds-1.2.2.jar:/Java/Lesetest.jar" Lesetest

Das bezieht sich auf folgenden Code:

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class Lesetest {

	public static void main(String[] args)
	{
		String system   = "[i5-Name]:80";
		String userId   = "[user]";
		String password = "[passwort]";
		String url      = "jdbc:as400://" + system + ";translate binary=true";
		try {
			System.out.println("Inhalt der AS/400:");
			Class.forName("com.ibm.as400.access.AS400JDBCDriver");
		 	Connection conn = DriverManager.getConnection(url,userId, password);
		 	System.out.println("Treiber geladen");
		 	Statement stmt=conn.createStatement();
		 	ResultSet rs=stmt.executeQuery("select * from [Tabelle]");
		 	while (rs.next())
		 	{
		 		System.out.print(rs.getString(1)+" - ");
		 		System.out.print(rs.getString(2)+" - ");
		 		System.out.print(rs.getInt(3)+" - ");
		 		System.out.print(rs.getString(4)+" - ");
		 		System.out.print(rs.getInt(5)+" - ");
		 		System.out.print(rs.getInt(6)+" - ");
		 		System.out.print(rs.getInt(7)+" - ");
		 		System.out.print(rs.getInt(8)+" - ");
		 		System.out.print(rs.getInt(9)+" - ");
		 		System.out.print(rs.getInt(10)+" - ");
		 		System.out.print(rs.getInt(11)+" - ");
		 		System.out.println(rs.getInt(12));
		 	}
		 	conn.close();
		 	
		 	System.out.println("");
		 	System.out.println("Inhalt von MSSQL:");
		 	Class.forName("net.sourceforge.jtds.jdbc.Driver");
		 	String typ			= "sqlserver";
		 	system				= "[System-Name]";
		 	String datenbank	= "[DB-Name]";
		 	userId				= "[User]";
		 	password			= "[Passwort]";
		 	url					= "jdbc:jtds:" + typ
		 						+ "://" + system
		 						+ "/" + datenbank
		 						+ ";user=" + userId
		 						+ ";password=" + password;		 	
		 	Connection conn2 = DriverManager.getConnection(url);
		 	System.out.println("Treiber geladen");
		 	Statement stmt2=conn2.createStatement();
		 	ResultSet rs2=stmt2.executeQuery("select * from [Tabelle]");
		 	while (rs2.next())
		 	{
		 		System.out.print(rs2.getString(1)+" - ");
		 		System.out.print(rs2.getString(2)+" - ");
		 		System.out.print(rs2.getInt(3)+" - ");
		 		System.out.print(rs2.getString(4)+" - ");
		 		System.out.print(rs2.getInt(5)+" - ");
		 		System.out.print(rs2.getInt(6)+" - ");
		 		System.out.print(rs2.getInt(7)+" - ");
		 		System.out.print(rs2.getInt(8)+" - ");
		 		System.out.print(rs2.getInt(9)+" - ");
		 		System.out.print(rs2.getInt(10)+" - ");
		 		System.out.print(rs2.getInt(11)+" - ");
		 		System.out.println(rs2.getInt(12));
		 	}
		 	conn2.close();
		} catch (ClassNotFoundException e) {
			e.printStackTrace();
		} catch (SQLException e) {
			e.printStackTrace();
		}
	}
}

[BenderD]

ad classpath: jar Dateien müssen bei standalone Anwendungen bis zur Datei angegeben werden, einzelne class files mit dem root Verzeichnis ihrer package Hiewrarchie

ad redbooks: gewöhne dir deren Stil nicht an, das ist Java ala RPG

ad Geschwindigkeit: je nach Alter des Prozessors ist das ziemlich normal und selbst bei neueren Prozessoren ist die AS/400 insbesondere im laden der JVM kein Rennpferd (Speicherverwaltung lässt grüßen!) - deswegen sollte man auf der AS/400 alles als Serverdienst implementieren, dann schnurrt das bei neueren Prozessoren recht ordentlich. Ein paar Hinweise dazu findest du auch auf meiner Webseite in den Java auf AS/400 FAQ.

D*B

[Ottersberg]

ad classpath: jar Dateien müssen bei standalone Anwendungen bis zur Datei angegeben werden, einzelne class files mit dem root Verzeichnis ihrer package Hiewrarchie

Ja das habe ich jetzt auch bemerkt und verstanden.

ad redbooks: gewöhne dir deren Stil nicht an, das ist Java ala RPG

Ich hab mir nur ein paar Hinweise bzgl. Starten von Programmen und Classpath dort geholt. Weiter vertiefen wollte ich das gar nicht.

ad Geschwindigkeit: je nach Alter des Prozessors ist das ziemlich normal und selbst bei neueren Prozessoren ist die AS/400 insbesondere im laden der JVM kein Rennpferd (Speicherverwaltung lässt grüßen!) - deswegen sollte man auf der AS/400 alles als Serverdienst implementieren, dann schnurrt das bei neueren Prozessoren recht ordentlich. Ein paar Hinweise dazu findest du auch auf meiner Webseite in den Java auf AS/400 FAQ.

Also unter WRKACTJOB kommt kaum ein Ausschlag, vielleicht 1-2 %. Hauptspeicher stehen 5.000 MB zur Verfügung, wenn ich das richtig gesehen habe. Wenn man sich die Beobachtung der Zeiten so angeguckt scheint ja das Laden der Treiber recht lange zu dauern.

Im FAQ steht ja, dass JIT verwendet werden soll, was ja scheinbar auch Standard ist. Da wir da nichts anderes haben sollte das dann auch wohl bei uns benutzt werden. Wie man etwas als Dienst implementiert auf der iSeries weiß ich zwar nicht, aber vielleicht unser iSeries-Mann. Bislang haben wir das implementiert wie hier vorgeschlagen: http://www.bender-dv.de/Sourcen/QCLSRC.TFRDTA

[BenderD]

Hallo,

mit Dienst ist hier gemeint, dass man einen Hintergrundjob startet, der eine JVM und alle teuren Objekte (wie auch Treiber) vorab lädt und an einer DataQ oder MessageQ auf Aufträge wartet, die aus AS/400 Programmen in Form von Nachrichten in die AnforderungsQ gestellt werden. Ich plane mit Common für den Herbst einen Workshop zu diesem Thema mit Teilnehmerübungen.

mfg

Dieter Bender

Also unter WRKACTJOB kommt kaum ein Ausschlag, vielleicht 1-2 %. Hauptspeicher stehen 5.000 MB zur Verfügung, wenn ich das richtig gesehen habe. Wenn man sich die Beobachtung der Zeiten so angeguckt scheint ja das Laden der Treiber recht lange zu dauern.

Im FAQ steht ja, dass JIT verwendet werden soll, was ja scheinbar auch Standard ist. Da wir da nichts anderes haben sollte das dann auch wohl bei uns benutzt werden. Wie man etwas als Dienst implementiert auf der iSeries weiß ich zwar nicht, aber vielleicht unser iSeries-Mann. Bislang haben wir das implementiert wie hier vorgeschlagen: http://www.bender-dv.de/Sourcen/QCLSRC.TFRDTA

[RobertPic]

...Wie man etwas als Dienst implementiert auf der iSeries weiß ich zwar nicht, aber vielleicht unser iSeries-Mann.

Damit ist gemeint, dass das Javaprogramme 1x Tag gestartet und auf seine Arbeit wartet. Dadurch entfällt der ganze JIT-Teil bei den Folgeaufrufen.

Der einfachste Weg mit dem Javaprogramm (aus RPG/CL/Cobol) zu kommunzieren, ist über DataQueues.

Komplizierter wird es, wenn es nicht die Kommunikation keine Einbahnstrasse sein soll. Leider gibt es kein "Rahmenwerk" für die Java zu 3GL Kommunikation, sodass wohl jeder seine eigene Lösung hat.

Noch ein Vergleich:
Wenn eine Java-PDF-Wandlung vom "Stand aus" aufrufe, braucht sie ca. 30 Sekunden für das Umwandeln der Spooldatei. Der vorgestartete Serverdienst (über DataQueue) macht das in Sekundenbruchteilen!

/Robert

[BenderD]

vielleicht sollten wir das mal ändern und eine Opensource Projekt hierzu aufmachen, ich würde meinen Java DataQ Listener einbringen - ich plane eh' den unter GNU License zu stellen

D*B

Leider gibt es kein "Rahmenwerk" für die Java zu 3GL Kommunikation, sodass wohl jeder seine eigene Lösung hat.
/Robert

[Ottersberg]

Ich habe das Prinzip verstanden. Das wäre auf jeden Fall besser, als das Programm jedesmal aufzurufen, wenn es etwas tun muss. Ich werde mich da mal einlesen und das Programm später umstellen. Fürs erste reicht das regelmäßige aufrufen aus.

[LindnerSpezial]

Hallo!

Ich bekomme auch folgenden Fehler:
com.microsoft.sqlserver.jdbc.TDSChannel enableSSL
WARNUNG: TDSChannel ( ConnectionID:1 TransactionID:0x0000000000000000) SSL handshake failed: null

Ich habe schon verschiedenste Treiber ausprobiert, aber keiner funktioniert.
(1.1 , 1.2 , JTDS)

Enweder kommt die Fehlermeldung von oben, oder "Fehler bei der Anmeldung von Benutzer".

Eigentlich müssten doch alle Zusatzprogramme installiert sein, um eine SSL Verbindung zu dem SQL Server 2005 herzustellen:

5722AC3 *INSTALLED Crypto Access Provider 128-bit
5722JC1 *COMPATIBLE Toolbox for Java
5722JV1 *COMPATIBLE Developer Kit for Java
5722JV1 *COMPATIBLE Java Developer Kit 1.3
5722JV1 *COMPATIBLE Java Developer Kit 1.4
5722JV1 *INSTALLED Java Developer Kit 1.5
2MEBEFF *INSTALLED Signature/Encryption


Hier der Code usw.
MC Press Online - Query Remote Database Tables from the iSeries Using SQL and Java

Gruß und Frohes Neues Jahr,
Henning

[BenderD]

... das sieht nach einem Problem aus, dass mit dem verwendeten Treiber und der Java Umgebung zusammenhängt. Das sollte mit einer älteren Treiber Version oder einem alternativen Treiber eines anderen Herstellers zu lösen sein. (Auch Treibereinstellungen beim Connect könnten helfen, wenn man Diskussionen in anderen Foren glauben darf).
Ansonsten wäre es natürlich sinnvoller den eigenen Code und die verwendete URL zu posten statt eines Artikels!
Dennoch rate ich von solchen Wackelhaufen ab, das krankt an den selben Ecken wie die direkten RPG Aufrufe:
- erster Aufruf im Job Grotten langsam
- skaliert miserabel, da pro Job eine eigene JVM aufgemacht wird
- Java Umgebung nicht zuverlässig steuerbar, da implizit gestartet
- spätestens wenn man das mit RPG Java Calls mixt, fällt der Haufen um
- Fehler Analyse nahezu unmöglich

mfg

Dieter Bender

Hallo!

Ich bekomme auch folgenden Fehler:
com.microsoft.sqlserver.jdbc.TDSChannel enableSSL
WARNUNG: TDSChannel ( ConnectionID:1 TransactionID:0x0000000000000000) SSL handshake failed: null

Ich habe schon verschiedenste Treiber ausprobiert, aber keiner funktioniert.
(1.1 , 1.2 , JTDS)

Enweder kommt die Fehlermeldung von oben, oder "Fehler bei der Anmeldung von Benutzer".

Eigentlich müssten doch alle Zusatzprogramme installiert sein, um eine SSL Verbindung zu dem SQL Server 2005 herzustellen:

5722AC3 *INSTALLED Crypto Access Provider 128-bit
5722JC1 *COMPATIBLE Toolbox for Java
5722JV1 *COMPATIBLE Developer Kit for Java
5722JV1 *COMPATIBLE Java Developer Kit 1.3
5722JV1 *COMPATIBLE Java Developer Kit 1.4
5722JV1 *INSTALLED Java Developer Kit 1.5
2MEBEFF *INSTALLED Signature/Encryption


Hier der Code usw.
MC Press Online - Query Remote Database Tables from the iSeries Using SQL and Java

Gruß und Frohes Neues Jahr,
Henning