Vielen Dank für die Antwort, Baldur. Eigentlich geht es bei der ganzen Problemanalyse nur darum, dass es bei uns Bedenken gibt, die SYSTOOLS Funktionen, die in Java implementiert sind, massenhaft (also z.B. in jedem interaktiven Job) zu verwenden. Wir haben festgestellt, dass eine JVM den Speicherbedarf eines Jobs um ca. 60 MB steigert. Eben weil die Verwendung von z.B. HTTPGETCLOB eine JVM hochzieht. Und die JVM bleibt ja solange am Leben, wie der Job läuft.

Das heißt, wenn wir 1500 interaktive Sitzungen haben und jede startet eine VM, müsste der Hauptspeicherbedarf um 1500 mal 60 MB steigen. Das sind 90 GB. Unser Hauptspeicher ist zwar fast ein TB groß, aber trotzdem könnte es ja sein, dass die 90 GB (die ja eigentlich unnötig sind - IBM hätte das ja auch in C realisieren können) uns nennenswert Performance kosten.

Deshalb arbeiten wir an Ideen, wie wir die Hauptspeicherbelastung durch die vielen VMs begrenzen können. Möglichst ohne große Umprogrammierung.

Im IBM Developer Forum habe ich die Aussage erhalten, dass bei einem Anwender Performanceprobleme auftraten, nachdem viele VMs gestartet wurden. Die Lösung war dort anscheinend, den Hauptspeicher aufzurüsten. Das geht bei uns nicht mehr. 1 TB ist bei unserer Maschine die physische Grenze.

Vielleicht passiert auch gar nichts schlimmes, wenn wir die VM in jeden Job packen. Es ist nur ein gewisses Risiko, das wir gerne vermeiden möchten.