Wie lange "lebt" ein QZDASOINIT-Job?

[Fuerchau]

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]

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

[Fuerchau]

RMTCMD's und Calls werden ja nicht im QZDASOINIT ausgeführt sondern nur eben SQL-Befehle.

[dschroeder]

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.

[Fuerchau]

Was aber bei wiederholten Aufrufen über die selbe verbindung ggf. Performancenachteile bringt.