Hallo Robert,

wie so ein Server Dienst von der Parameterschnittstelle her aussehen soll? ich bin mir da auch noch nicht so ganz sicher; vielleicht IBMs Arbeit gemacht, ein remote JNI (Java native Interface) geschrieben und einen kleinen Pre Compiler der aus dem ganzen *JAVA Quatsch in RPG die erforderlichen Aufrufe generiert. Für kleinere Sachen würde ich das auch so ähnlich machen, wie du, vielleicht ein bisschen professioneller, ich habe ein wenig Erfahrungs Vorsprung.
Zu den mehreren Diensten und Prioritäten, Java hat das schon, die Server können Multithreaded sein.

mfg

Dieter Bender

Zitat Zitat von RobertPic
Hallo Dieter, Hallo Michael
Um nur ein Beispiel zu nennen: Meine Spool2PDF-Umwandlung dauert beim Erstaufruf ca. 30-40 Sekunden, obwohl alle betoffenen Objekte mit Level 40 optimiert sind.
Die Folgeaufrufe gehen in 2-3 Sekunden über die Bühne.

Meine Serverjobs sind zwar (noch) nicht "Java-rein", aber spätetstens ab dem 2. Javapgrogramm wird es 2 Java-Serverjobs geben. Zwei deshalb, weil wir die Serverjobs zwischen dringend (User wartet auf Eregebnis z.B. Gewicht von Waage) und "darf etwas dauern" (e-mail/fax) unterscheiden.

Natürlich sind neue Serverjobs immer mit Arbeit verbunden (beim Starten aufdrehen, beim Sichern abdrehen bzw. auf das Ende warten ....), deshalb neigt man dazu auch Lösungen ohne neue Serverjobs in Betracht zu ziehen....

Einzig offene Frage für mich: Ob eine Parameterstruktur im DataQueue-Eintrag, der Weisheit letzter Schluss ist. Ich versehe die Dinger zwar immer mit einer Versionsnummer, aber so eine Art Properiesformat in einem DataQueue-Eintrag wäre mir lieber.


Leider lassen sich 16 Jahre (inkl. Schulzeit) prozedurales Programmieren nicht so einfach "ausblenden". Ohne "nachdenken", "sprudelt" es halt nur strukturierte Programme aus dem "Hirn" - aber das gibt sich auch noch....

Im Gegensatz zu VB/VBA/Access ist Java gnadenlos (s.o.) konsequent. Während man in VB... kaum Probleme mit dem "alten Stil" hat, sucht man bei Java z.B. vergeblich nach einem Case für Strings...

LG
Robert P.