QZDASOINIT unterscheiden

[Christian.Hesse]

Hallo alle miteinander!

Ich habe folgendes Problem:auf meine iSeries greifen verschiedene Programme per JDBC/ODBC zu.
Das Problem ist dabei aber, daß diese sich grob in zwei Kathegorien einteilen lassen:
- Programme und Clients, die regelmäßig Daten abfragen und schnell Antworten bekommen müssen, da sie mehr oder minder Zeitkritisch sind (JDBC)
- Programme, die eher zu statistischen Abfragen genutzt werden und keine Priorität haben und somit auch zurückstecken können und sollen. (ODBC und manchmal JDBC)

Leider eröffnet OS400 für jede Verbindung die parallel besteht ein QZDASOINIT im selben Subsystem und mit dem selben Benutzer (QUSER).

Wie kann ich diese Verbindungen in der Priorität staffeln? Ist es möglich, dies über die Client-IP-Adresse oder den Adress-Bereich oder über den Nutzer, der sich anmeldet zu erledigen?

Vielen herzlichen Dank für eure Hilfe!

Gruß

Christian

[Fuerchau]

Vom System her kannst du da leider nichts standardmäßig verlangen.
Du hast nur die Möglichkeit eine SQL-Procedure zu erstellen, die mittels CHGJOB die Priorität herab/heraufsetzt.
Allerdings musst du das dann bei jeder Art ODBC/JDBC-Verbindung machen, da durch die Wiederverwendung der PJ's die letzte Prio erhalten bleibt.

Die andere Alternative (allerdings seeeeehr aufwändig) ist ein User-Exit (WRKREGINF) für SQL um an Hand bestimmter Kriterien einzugreifen. Allerdings kannst du an dieser Stelle den Verursacher nur durch den Usernamen und die Art des selbst zu analysierenden SQL's ermtteln.

[Christian.Hesse]

Hallo Fuerchau!

vielen herzlichen Dank für die schneller Antwort. Es sieht so aus als müßte ich eher die Benutzer erziehen, als eine "automatische" Lösung zu finden. Schade eigentlich, aber ich befürchte der Aufwand durch die von dir benannten Varianten wird zu groß sein.

Vielen Dank nocheinmal!

Gruß

Christian

[Robi]

Hi,
ich lese gerade das "Memorandum für Benutzer für V5R4"
Seite 19 steht singemäß
Änderung der Anzeige im wrkactjob, zukünftig kann man den ECHTEN user sehen.
Vielleicht kannst du damit später was anfangen
Wart halt auf V5R4, wir sind schon echt gespannt

Gruß
Schönes Wochenende
Robi

[TARASIK]

Hallo,
schaue Dir doch einmal dieses Programm an "WrkOdbcJob"
http://home.columbus.rr.com/jbmmdietz/iseries.html

Vielleicht kannst Du damit etwas anfangen ?

[klaro03]

Hallo Christian,

falls die ODBC/JDBC Requests von verschiedenen IP-Adressen kommen,
kann man via iseries Navigator einstellen, dass die Requests in verschiedene
Subsysteme geleitet werden. Per SBS kann man dann unterschiedliche prestart jobs definieren und so auch die Prioritäten entsprechend anpassen.
Im Navigator findest du diese Einstellung unter: systemname/Network/Servers/iSeriesAccess (habe leider nur die englische Version)
Hier dann auf Eigenschaften von Database klicken und unter subsystems die Zuordnung der einzelnen IP-Adressen oder Bereiche vornehmen.

Gruss,
Klaus

[Christian.Hesse]

Hallo Robi, Tarsik und klaro03,

vielen Dank für eure Tipps. Die Einstellungen für den Datenbankserver habe ich gefunden, muß sie allerdings noch testen. (Eingestellt war das recht schnell)

Das Tool zum betrachten der JDBC/ODBC-Verbindungen ist auch Gold Wert.

Allerdings hat mich letzteres vor ein neues Problem gestellt: Wenn ich ein Java-Programm habe, öffne eine JDBC-Verbindung und schicke 10 Statements auf die selbe Datei los, ist das File 10 mal geöffnet. Das schließen der Dateien wird anscheinend erst mit dem schließen der JDBC-Verbindung geschlossen. Das ganze läßt sich auch mit 100 oder 500 SQL-Statements reproduzieren.

Benutzt wird in diesem Fall die IBM-Toolbox JTOpen in der neuesten Version.

Hat schon einmal jemand dieses Phänomen beobachtet und könnte das evtl. für zusätzliche "Trägheit" der AS400 sorgen? Bei meinen permanent vorhandenen Verbindungen habe ich im Schnitt 400-500 geöffnete Dateien bewundern dürfen, die allerdings alle das selbe identische File betrafen. Irgendwie ist das alles gerade etwas seltsam.

Vielen herzlichen Dank nochmal euch allen!

Gruß

Christian

[RobertPic]

Zum Unterscheiden:

Die Jobs QZDASOINIT halten eine Sperre auf den Anmeldebenutzer.

ein WRKOBJLCK JAVAUSR OBJTYPE(*USRPRF)

zeigt z.B. alle Jobs, welche den Benutzer JAVAUSR verwenden, auch QZDASOINIT.
Leider hat WRKOBJLCK keine FileOutput.

Auch für die Sperren vom Job kommt man an das benutzte Userprofil (dort gibt es ein Outfile).

Zum 2. Problem:
Da ist die Java-Anwendung unsauber programmiert. Ich tippe auf PrepearedStatements die bei jeder Benutzung neu gemacht werden. Entweder schließt man sie nach der Benutzung oder besser man macht sie nur einmal auf.

Der Code könnte in etwas so aussehen:

public boolean fetchByFirKunr(int firma, int kundennr) {
        try {
            if (fetch == null) {
                fetch = as400Conn.getConn().prepareStatement(
                 "Select " + fieldList + " from mixdta.mkun where " +
                 "mkufir = ? and mkukunr = ?");
            }
            fetch.setInt(1, firma);
            fetch.setInt(2, kundennr);

            retRs = fetch.executeQuery();
            geladen = retRs.next();
            if (geladen) {
                this.mapping(retRs);
            }
             ..... 

Laut Lehrbüchern sollte man sowieso ResultSet und Statement schließen und die Connection einem Connectionpool zurückgeben. Aber ich halte mir für einfache Serverjobs und kleine GUI-Awendungen lieber eine Connection offen.

Robert P.

[Christian.Hesse]

Hallo RobertPic,

du hast recht: Es waren PreparedStatements, die nicht geschlossen sind. Vielen herzlichen Dank.

Die Rückgabe der Verbindungen an einen Connection Pool wird derzeit nur beim Application Server genutzt, da die "Clients", die mir momentan mit das größte Kopfzerbrechen bereiten 24/7 connected sind und SQL-Statements ausführen. Diese bestehen aus einer Verbindung von einer Java-Anwendung, die alleine auf einem Rechner untergebracht ist, weswegen ich den Nutzen eines Connection Pools in diesem Fall nicht sehe.

Da fällt mir aber noch etwas anderes ein: In den Applikationen wird zum Schreiben in die Datenbank ein RPG-Programm mit Parametern aufgerufen, welches das Schreiben übernimmt. Angeblich soll das bei der Implementierung deutlich schneller gewesen sein als die Nutzung von Insert/Update per JDBC. Hat da jemand Erfahrungen dazu?

Ich werde mal versuchen, meinen Problemen weiter auf den Grund zu gehen - vielleicht findet sich noch irgendetwas, was ich bisher übersehen habe.

In diesem Sinne nocheinmal herzlichen Dank allen und bis bald!

Gruß

Christian

[RobertPic]

.... Es waren PreparedStatements, die nicht geschlossen sind.

Rein vom Speed her, würde ich sie weiterhin offen lassen. Also für die gesamte Klasse deklarieren, aber das Statement nur erzeugen wenn es null ist (Beispielcode) oder dafür einen Schalter machen.

Nachteil: Dateien bleiben geöffnet (aktiver Job bei Sicherungen)
Vorteil: schnellste Lösung

....weswegen ich den Nutzen eines Connection Pools in diesem Fall nicht sehe.

Sehe ich genauso. Einen ConnectionPool brauche ich erst, wenn ICH die Übersicht verliere (WebServer, komplexe GUI und/oder Multithread-Applikationen)...

... In den Applikationen wird zum Schreiben in die Datenbank ein RPG-Programm mit Parametern aufgerufen, welches das Schreiben übernimmt. Angeblich soll das bei der Implementierung deutlich schneller gewesen sein als die Nutzung von Insert/Update per JDBC. Hat da jemand Erfahrungen dazu?

Also unter normalen Umständen, kann ich mir das eigentlich nicht vorstellen. Vielleicht wenn ein Aufruf viele DB-Operationen erzeugt.

Auch bei Updates habe ich, von der Performance her, mit offen gelassenen PreparedStatements gute Erfahrungen gemacht.

Eventuell hilft dieser Thread
bei der Performancesuche etwas.

Bei DB-Updates macht nichtmal unsere kleine Entwicklungsmaschine (170er) mucken.

Robert P.

[BenderD]

Hallo,

das mit dem Connection Pool...
Hauptvorteile sind:
- einfacheres Transaktionshandling (pro Transaktion eigene Connection vom Pool)
- Zentralisierung des Connection Handlings (ab und an schließen und neue öffen, wg. vergammeln etc.)
- gute Pools können prepared Statements cross Connection poolen
Primär geht es um Design und erst sekundär um Performance!!!

Zur Performance von updates: bei read Write Logik ist es meist vorteilhaft positioned updates über ResultSet zu machen statt searched updates

Ansonsten geht im allgemeinen messen (DBMON) über raten.

mfg

Dieter Bender

Hallo RobertPic,

du hast recht: Es waren PreparedStatements, die nicht geschlossen sind. Vielen herzlichen Dank.

Die Rückgabe der Verbindungen an einen Connection Pool wird derzeit nur beim Application Server genutzt, da die "Clients", die mir momentan mit das größte Kopfzerbrechen bereiten 24/7 connected sind und SQL-Statements ausführen. Diese bestehen aus einer Verbindung von einer Java-Anwendung, die alleine auf einem Rechner untergebracht ist, weswegen ich den Nutzen eines Connection Pools in diesem Fall nicht sehe.

Da fällt mir aber noch etwas anderes ein: In den Applikationen wird zum Schreiben in die Datenbank ein RPG-Programm mit Parametern aufgerufen, welches das Schreiben übernimmt. Angeblich soll das bei der Implementierung deutlich schneller gewesen sein als die Nutzung von Insert/Update per JDBC. Hat da jemand Erfahrungen dazu?

Ich werde mal versuchen, meinen Problemen weiter auf den Grund zu gehen - vielleicht findet sich noch irgendetwas, was ich bisher übersehen habe.

In diesem Sinne nocheinmal herzlichen Dank allen und bis bald!

Gruß

Christian