View Full Version : Erste Eindrücke/Fragen eine Java-Newbies
So mein Java-Erstlingswerk (HelloWord-Versionen nicht mitgezählt) ist zu 90% fertig.
Es handelt sich um die 101. Variante von SCS-Spoolfile nach PDF. Bei meiner Variante halt mit dem Firmenbriefpapier im Hintergrund bzw. den Hintergrundstreifen für *STD und A4QUER Spools.
Für die PDF-Erstellung verwende ich die Klassensammlung itext, für das Auslesen der DB-Zwischendatei die Klassensammlung JT400.jar.
Die Entwicklung am PC (DEV:Gel) verlief weitgehend problemlos. Auch der Start auf der AS/400 klappte auf Anhieb.
Mit der eigentlichen Laufzeit bin ich auch zufrieden - aber das "vorkompilieren" dauert deutlich länger als die eigentliche Umwandlung. Ich konnte diese Vorlaufzeit mit CRTJVAPGM deutlich reduzieren.
In diesem Forum wurde schön ofters von den AS/400-Befehlen CRTJVAPGM und RUNJVA abgeraten, welche Nachteile habe ich dadurch?
Außerdem sollte man auf der AS/400 ja mit JT400NTVE.JAR (native Treiber) arbeiten. Aber dann muss ich ja einen anderen JDBC-Treiber registrieren. Damit läuft mein Programm aber nicht mehr am PC. Muss da ein Config-File her, oder gibt es eine bessere Lösung?
Weiters wird hier im Forum vom Mix aus 3GL und Java abgeraten. Abgesehen von der schlechteren Performance, habe ich sonst Nachteile? Da die Outputerstellung bei mir ohnehin schon in "Horchjobs" gebündelt ist, sollten sich die Nachteile in Grenzen halten.
Kleines Detail: wenn die Zwischen-DB-Datei (mit den Spooldaten) CCSID 273 hat, bekomme ich die Daten bereits als sauberes ASCII aus der DB heraus.
Robert P.
Hallo Roebrt,
ad CRTJVAPGM: nur erforderlich, wenn das Programm in vielen JVMs jeweils selten (Regel 1mal) aufgerufen wird. (siehe auch zu Mix). Sinnlos bei den meisten Application Servern (wg. user Classloader). Nachteilig ist das schwierigere Deployment insbesondere bei der Änderung großer Anwendungen (Downtime). Direkt schädlich ist das nicht.
ad RUNJAVA: hat nicht alle Parameter für den Aufruf. Alternative QSH CMD(java.....) ist einfacher und eleganter bei voller Funktionalität.
ad Treiber: Treibereinstellungen gehören eigentlich immer in ein property file, um genau diesen Effekt zu verhindern. Der native Treiber ist nicht per se schneller als der Toolbox Treiber. Bei letzterem ist es allerdings wichtig, dass er mit CRTJVAPGM behandelt ist. Auf der AS400 sind jt400.jar mit und ohne static Compile, da muss man den richtigen nehmen (kann man mit DSPJVAPGM prüfen).
ad Mix: Hauptnachteil ist schlechte Wartbarkeit! die rpg Seite braucht Java Knohhow und umgekehrt. Dazu kommen Design und technische Probleme.
Java hat direkte Schnittstellen mit C eingebaut, die sind gedacht und notwendig für die Implementierung von Java auf unterschiedlichen Plattformen (C Compiler reicht, das ist die Idee). In der Kindergartenzeit von Java riet man manchmal dazu Laufzeit kritische Funktionen in C zu schreiben, das rät und tut heute niemand mehr!!! Wenn man jetzt Java mit 2,5 GL (RPG) mixen will, dann kommen mehrere Probleme dazu. Nehmen wir das mal an deinem Beispiel: Du baust deine Funktion in eines eurer Dialogprogramme als Aufruf ein; das hat zur Folge, dass pro Benutzer, der das benutzt, in seinem Job eine JVM gestartet wird, die jede für sich ein vielfaches an (teurem) Hauptspeicher benötigt, wie die jeweilige Dialogverarbeitung; der einzige der sich da freut ist IBM, die das wohl auch deswegen empfehlen und lehren. Machst du einen SBMJOB draus, dann addiert sich das zwar nicht, aber dafür werden noch mehr JVMs erzeugt, da ja jeder SBM jetzt eine Ex und Hopp JVM startet - jetzt hast du Hauptspeicher gegen CPU getauscht - auch hier freut sich...
Im Application Server kommt noch Multithreading hinzu, was die Stabilität der Anwendungen untergräbt, da die RPG Runtime das nicht kann, was Probleme verursachen könnte.
Wenn Du unter Horchjob, eine Art Server verstehst (never ending Batchjob), dann ist das bereits die richtige Richtung. Bloß warum sollte man hier mixen? Das geht am einfachsten in Java only! Du lässt den Server an einem Socket, einer DTAQ, oder einer MSGQ warten und die RPG Seite stellt einen Auftrag über eine kleine Schnittstellenfunktion ein, der Server erzeugt einen neuen Thread (was die RPG Variante nicht kann) und arbeitet den Auftrag ab.
mfg
Dieter Bender
So mein Java-Erstlingswerk (HelloWord-Versionen nicht mitgezählt) ist zu 90% fertig.
Es handelt sich um die 101. Variante von SCS-Spoolfile nach PDF. Bei meiner Variante halt mit dem Firmenbriefpapier im Hintergrund bzw. den Hintergrundstreifen für *STD und A4QUER Spools.
Für die PDF-Erstellung verwende ich die Klassensammlung itext, für das Auslesen der DB-Zwischendatei die Klassensammlung JT400.jar.
Die Entwicklung am PC (DEV:Gel) verlief weitgehend problemlos. Auch der Start auf der AS/400 klappte auf Anhieb.
Mit der eigentlichen Laufzeit bin ich auch zufrieden - aber das "vorkompilieren" dauert deutlich länger als die eigentliche Umwandlung. Ich konnte diese Vorlaufzeit mit CRTJVAPGM deutlich reduzieren.
In diesem Forum wurde schön ofters von den AS/400-Befehlen CRTJVAPGM und RUNJVA abgeraten, welche Nachteile habe ich dadurch?
Außerdem sollte man auf der AS/400 ja mit JT400NTVE.JAR (native Treiber) arbeiten. Aber dann muss ich ja einen anderen JDBC-Treiber registrieren. Damit läuft mein Programm aber nicht mehr am PC. Muss da ein Config-File her, oder gibt es eine bessere Lösung?
Weiters wird hier im Forum vom Mix aus 3GL und Java abgeraten. Abgesehen von der schlechteren Performance, habe ich sonst Nachteile? Da die Outputerstellung bei mir ohnehin schon in "Horchjobs" gebündelt ist, sollten sich die Nachteile in Grenzen halten.
Kleines Detail: wenn die Zwischen-DB-Datei (mit den Spooldaten) CCSID 273 hat, bekomme ich die Daten bereits als sauberes ASCII aus der DB heraus.
Robert P.
Hallo Robert,
ich bin z.Zt. auf einem ähnlichen Weg. Meine Erfahrungen
in Java sind allerdings noch nicht soweit fortgeschritten.
Aber ich arbeite daran.
Ich hätte aber ein paar Fragen zu dem itext. Könnten wir uns
da evtl. mal per Mail austauschen ?.
Vielen Dank
Michael
@Dieter Bender
Danke für die ausführliche Antwort.
Wenn Du unter Horchjob, eine Art Server verstehst (never ending Batchjob), dann ist das bereits die richtige Richtung.
Genauso läuft das bei uns. Pro Mandant werden 2 Jobs gestartet, welche via DataQ auf Arbeit warten und den ganzen Tag durchlaufen.
Bloß warum sollte man hier mixen? Das geht am einfachsten in Java only!
Wenn ich den "Mixfaktor" außen vor lassen würde, wäre ich jetzt fertig.
Wenn ich den JAVA-Teil von unserem (Eigenbau-Command) SNDSPLF für einen eigenen Serverjob herausbrechen würde, schafft das zusätzliche Probleme/Arbeit, da ich für die Weiterverarbeitung (email/ftp/fax) auf das PDF warten muss.
Ich könnte natürlich gleich den gesamten Command an einen Java-Batchhjob übergeben, aber 1. muss ich kräftig an der 3GL Programmlogik basteln (für Aufrufe "Vor- und Nach" der Javaverarbeitung)
2. wie gut gehen RPG-Aufrufe (nicht ganz schlank, da mit LANSA erstellt) aus Java?
Wobei ich bei 2. den Vorteil habe sollte, den Serverjob auch auf einen Linuxserver verlegen zu können. (RPG-Aufrufe ?)
@mk
robertpic71@onemail.at
Wobei ich mir vorstellen könnte, dass der Austausch auch für andere Java-Anfänger interessant wäre.
@all
So jetzt noch mal ein Lob an das Board und speziell an Dieter Bender, den viele meiner Infos (Links zu Javaeinführung, iText für PDF) habe ich hier aus dem Board.
Hallo Robert,
das ist eigentlich ein exemplarisches Beispiel contra Mix! email und ftp wäre zumindest im Java einfacher und besser machbar als im RPG, bei Fax kenne ich eure Schnittstelle nicht.
RPG Aufrufe aus Java sind wg. der inkompatiblen Ablaufumgebungen nicht ganz so einfach.
- JNI (Java native Interface) davon rate ich eindeutig ab und macht wohl auch kaum einer!
- Toolbox Call erfolgt intern asynchron über ServerJob, ist m.E. aber hakelig zu programmieren und zerklopft einem jegliche Plattform Neutralität
- stored Procedure via JDBC ist meines Erachtens das glatteste und ließe sich sogar in vielen Fällen portieren; externe store Procedures lassen sich auf der AS400 leicht aus (fast) jedem Programm machen.
Ich denke ihr seid da schon auf einem ganz guten Weg.
Was die vorhandenen Infos angeht, ich bin dabei sowas ähnliches wie eine FAQ für Java und AS400 auf meiner WebPage aufzumachen und diese Rubrik dann in meine monatlichen Aktualisierungsaktionen mit aufzunehmen, damit meine Seiten interessant bleiben. Baut sich dann zwar langsam auf, denn meine WebSeite ist mehr der Abteilung Marketing zuzurechnen -<Schleichwerbung> mein Geld verdiene ich mit Projekten, Schulung und Beratung.</Schleichwerbung>
mfg
Dieter Bender
@Dieter Bender
Danke für die ausführliche Antwort.
Genauso läuft das bei uns. Pro Mandant werden 2 Jobs gestartet, welche via DataQ auf Arbeit warten und den ganzen Tag durchlaufen.
Wenn ich den "Mixfaktor" außen vor lassen würde, wäre ich jetzt fertig.
Wenn ich den JAVA-Teil von unserem (Eigenbau-Command) SNDSPLF für einen eigenen Serverjob herausbrechen würde, schafft das zusätzliche Probleme/Arbeit, da ich für die Weiterverarbeitung (email/ftp/fax) auf das PDF warten muss.
Ich könnte natürlich gleich den gesamten Command an einen Java-Batchhjob übergeben, aber 1. muss ich kräftig an der 3GL Programmlogik basteln (für Aufrufe "Vor- und Nach" der Javaverarbeitung)
2. wie gut gehen RPG-Aufrufe (nicht ganz schlank, da mit LANSA erstellt) aus Java?
Wobei ich bei 2. den Vorteil habe sollte, den Serverjob auch auf einen Linuxserver verlegen zu können. (RPG-Aufrufe ?)
@mk
robertpic71@onemail.at
Wobei ich mir vorstellen könnte, dass der Austausch auch für andere Java-Anfänger interessant wäre.
@all
So jetzt noch mal ein Lob an das Board und speziell an Dieter Bender, den viele meiner Infos (Links zu Javaeinführung, iText für PDF) habe ich hier aus dem Board.