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

Zitat Zitat von RobertPic
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.