View Full Version : Wie lange "lebt" ein QZDASOINIT-Job?
dschroeder
11-12-12, 15:05
Hallo Forum,
bei uns greifen einige PC-Anwendungen (Java-Programme) per SQL auf selbstgeschriebene SQL-Funktionen (UDFs) zu. Wir sind etwas unsicher, wieweit die Kapselung und Wiederverwendung dieser prestarted Jobs geht. Wenn ich das richtig sehe, gibt es doch einen Pool dieser prestarted Jobs. Wenn ein PC eine SQL-Anfrage startet, greift sich ein Job aus dem Pool die Anfrage und bearbeitet sie. Ist es möglich, dass danach ein ganz anderer PC mit einem anderen User denselben prestarted Job benutzt? Falls ja, sind dann z.B. die Inhalte der QTEMP noch erhalten oder wird jede Anfrage so ausgeführt, als wäre es ein ganz "frischer" Job?
Vielen Dank in Voraus.
Dieter
Logic IT-Services
11-12-12, 19:21
Hi,
Soweit ich das verstanden habe, wird bei einer Freigabe des Jobs (disconnect) dieser erhalten und gleichzeitig ein Reset auf die Jobumgebung gemacht, sprich auch die QTEMP gesäubert. Damit kann sich ein anderer Job diesen Prestarted Job krallen, sofern frei. Eine ähnliche Mechanik kannst Du auch mit ProfoundUI HTTP-Serverjobs beobachten, die im Serverpool auf Anfragen warten.
Guckst du hier: Use of prestart jobs (http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzaii/rzaiimstprestrtjob.htm)
dschroeder
12-12-12, 08:41
Vielen Dank für die Antworten. Soweit ich die IBM-Dokumentation verstanden habe, kann man sich nicht darauf verlassen, dass ein prestarted job sauber ist. Zitat IBM: "Prestart jobs can be reused, but there is no automatic cleanup for the prestart job once it has been used and subsequently returned to the pool."
Vielleich kann ich ja noch einmal etwas genauer beschreiben, wo unser Problem damit genau liegt: Wir haben sehr viele RPG-Programme, die wir gerne unseren Java-Kollegen zur Verfügung stellen würden. Die Java-Seite greift immer mit dem gleichen User auf die iSeries zu. Meistens rufen die Java-Programme selbstgeschriebene SQL-Funktionen auf, die dann unsere RPG-Programme nutzen. Die RPG-Programme benötigen an vielen Stellen den User, der das Programm nutzt (z.B. für Berechtigungsprüfungen). Der Jobuser oder der Current User des Jobs bringt uns aber nichts, da es ja immer der gleiche "Java"-User ist. Wir müssen also viel Aufwand treiben, um den User bei allen Java-Calls bis in das letzte Programm per Parameter durchzuschleifen oder wir müssen uns den User beim
"obersten" Java Call zwischenspeichern und dann in den weiteren Programm auf den Zwischenspeicher zugreifen. Dann müssen wir natürlich sicherstellen, dass nach jedem call immer ordentlich aufgeräumt wird.
Wir macht Ihr das denn bei Aufrufen von PC-Systemen auf die iSeries? Nutzt Ihr auch für jeden call denselben User?
Dieter
Richtig ist das nicht.
Wenn ein User benötigt wird sollte auch die Anmeldung mit diesem erfolgen.
Da der Job-Name immer mit QUSER läuft kann man sich in RPG nicht auf die SDS-Einstellung verlassen, da hier nur der Jobuser eingetragen ist.
Bei der Anmeldung per ODBC wird der Current User durch SQL entsprechend gesetzt, so dass die API-Aufrufe nicht den Job-User greifen und das SQL-Schlüsselwort "USER" den angemeldeten User liefert.
Durch die Wiederverwendung der QZDA-Jobs bleibt die QTEMP erhalten, ODP's geöffnet und falls RPG-Programme aufgerufen wurden auch deren Status und ACTGRP's unverändert.
Möchte man wirklich saubere Job's sind 2 Aktionen erforderlich:
In der SBS-Beschreibung den Reuse auf Max(1) setzen und allerdings die Anzahl Neustarts hochsetzen, sonst ist nach 200 Verbindungen Schluss.
Zusätzlich muss in Java das Connection-Pooling abgeschaltet werden, da ja sonst auch hier die Verbindungen geöffnet bleiben.
Diese Maßnahmen gehen jedoch ggf. nicht unerheblich zu Lasten der Performance.
Die RPG-Programme müssen natürlich auch neben Mandantenwechsel auch User-Wechsel erkennen können um ggf. Stati und Prüfungen zu erneuern.
dschroeder
14-12-12, 08:48
Vielen Dank für die HInweise. Ich habe im Information Center noch etwas nachgelesen. Der Link von Pikachu verweist auf das Release V5R3. In der IBM-Doku für V7R1 schreibt IBM, dass in den prestarted jobs für Remote Commands und Calls das Standardverhalten für Reuse bereits auf 1 steht und man warnt davor, das einfach zu ändern.
Ich denke auch, dass es im Endeffekt das sauberste wäre, nicht immer mit dem gleichen User durchzugreifen. Am besten wäre es, wenn jeder User den Durchgriff mit seiner originären Benutzerkennung durchführt. Ich fürchte nur, dass das nicht so einfach umzusetzen sein wird. Es bedeutet sicherlich Codeänderungen in vielen Java-Programmen.
Vielen Dank nochmal an alle.
Dieter
RMTCMD's und Calls werden ja nicht im QZDASOINIT ausgeführt sondern nur eben SQL-Befehle.
dschroeder
14-12-12, 09:57
Ja, richtig. Ist mir jetzt auch gerade bewusst geworden. Es bleibt uns wohl nichts anderes übrig, als unsere SQL-Funktionen so anzupassen, dass sie ganz sauber ihre Umgebung wieder aufräumen.
Was aber bei wiederholten Aufrufen über die selbe verbindung ggf. Performancenachteile bringt.