Anwendung kann Teildatei nicht öffnen

[Fuerchau]

WRKOBJLCK -> F6
Dann siehst du erst die Teildateien und wer diese sperrt.

[Jabs]

Bei F6 sagt es F- Taste zur Zeit nicht erlaubt, aber ich habe F4 und die Teildatei angegeben. Dann kommt diese Ausgabe:

                                          Sperr-                       
Ausw  Teildatei   Job         Benutzer    art     Sperre   Status  Gem.
      OXIDTRM     QZDASOINIT  QUSER       MBR     *SHRRD    HELD       
                                          DATEN   *SHRRD    HELD

Ist das meine VB- Anwendung?

[Fuerchau]

Das Problem sind allerdings noch die QZDASOINIT-Job's (ODBC-Zugriffe).
SQL hält die ODP's auch nach Close offen.
Durch das Schließen der Verbindung wird zwar der QZDASOINIT-Job getrennt, aber nicht beendet !
Die nächste Verbindung such sich einen getrennten Job und verbindet sich mit diesem wieder. Erst wenn keiner Verfügbar ist, wird ein neuer Job initiiert.

Solange also der Job tatsächlich nicht beendet wird, sind die Ressourcen noch belegt!

In den Verbindungseigenschaften muss man dafür dann "Lazyclose" dekativieren (wie der Eintrag genau aussieht musst du mal suchen).

Ich habe diesbezüglich nämlich noch ein anderes Problem:
Sind auf dem System mehrere Sprachen installiert, wird die entsprechende QSYS29xx abhängig vom User vorgeschaltet.
Da aber eine QSYS29HH (HH-Hauptsprache) meist nicht existiert, scheitert der CHGSYSLIBL und die zuletzt eingestellte Sprache bleibt bestehen.
Fehlermeldungen erhält man dann in der Fremdsprache.
Lösung: eine leere QSYS29HH (z.B. QSYS2929 für Deutsch) erstellen.

[Jabs]

Hallo und Danke,
ich habe gerade ein Redbook zum Provider gefunden. Mal sehen, ob ich etwas zu 'lazyclose' finde.
Ich wünsche erst einmal ein schönes Wochenende.

[Jabs]

Noch einer hinterher
Könnte eventuell mit Connection Pooling zu tun haben.

The provider uses the ConnectionString as a key to determining whether a connection can be reused out of the connection pool. For connection pooling to work, the ConnectionString for the connection must be identical to a ConnectionString in the pool. If the ConnectionStrings
are not identical, then the connection will not be taken from the pool; instead, a new pool will be created and the new connection will be taken from the new pool. Connection pooling is discussed in greater detail in 4.7.6, “Connection pooling” on page 143.

Das ist per Default aktiv - man kann es aber abschalten.
Das teste ich heute Abend.
cu

[Fuerchau]

Das habe ich auch schon getestet, ändert aber nichts an der QZDASOINIT-Problematik. Diese bleibt bestehen.
Außerdem habe ich festgestellt, dass der Connection-Pool anwendungsspezifisch ist, also nicht systemweit gilt.
Wenn also ein Anwendung eine Verbindung schließt, wird sie dem lokalen Pool zugeordnet, beim nächsten öffnen aus dem Pool entnommen.
Wird die Anwendung beendet, ist auch der Pool weg.

Für den IBMDA400 konnte ich da allerdings nichts finden:
IBM i Support: Software Technical Document : 23062121

Diese Option scheint es nur für den ODBC-Treiber zu geben (ist in meinen Augen sowieso die bessere Wahl).

[Jabs]

Hallo,
ich habe die Anwendung auf ODBC umgestellt. Das Verhalten hat sich nicht geändert.

In der Konfiguration der ODBC Datenquelle ist "Unterstützung für verzögertes Schließen aktivieren" nicht aktiviert.
cu

[Jabs]

Ich nehme alles zurück und behaupte das Gegenteil.
Ich habe die Teildatei gelöscht und die Datenübertragung mit ODBC getestet. Die Sperren werden jetzt beendet, sobald die VB.Net- Anwendung die Datenübertragung beendet hat.
Danke für die Hilfe!
cu

[Fuerchau]

SQL ist da inzwischen ganz schön nickelig geworden.
Sichgerlich gibt es irgendwo die entsprechende Einstellung, aber man kann SQL (ODBC) auch zwingen:

Im Subsystem QUSRWRK gibt es Prestart-Jobs QZDASONINT.
Per
CHGPJE SBSD(QUSRWRK)
PGM(QZDASOINIT)
-> F4 -> F9
kann die "Maximale Verwendungszahl" auf 1 gesetzt werden.
D.h., eine Wiederverwendung eines Jobs wird ausgeschlossen, der Job wird nach Disconnect tatsächlich beendet.
Ggf. sollte man (wenn man viele ODBC-Verbindungen nutzt) die "Anfängliche Jobanzahl", "Schwelle" und "Zusätzliche Jobanzahl" etwas erhöhen, damit das Aufbauen einer Verbindung dann beschleunigt wird.
Das System startet eine entsprechende Anzahl Jobs beim SBS-Start und wenn die Schwelle "freier Jobs" (also ohne Verbindung) unterschritten wird, werden zusätzliche Jobs gestartet.
Den einzigen Performancenachteil, den man in Kauf nimmt, ist das Bereinigen bei Jobende.

Beim nächsten PTF/Update sollte diese Einstellung überprüft werden.

[KingofKning]

Naja, ich hätte jetzt F10 gesagt ;-)

Korinthenkack....

GG

[Fuerchau]

Der Unterschied zwischen F9 und F10 ist folgender:
F9 => Alle zusätzlichen Parameter
F10 => Nur bedingte zusätzliche Parameter

Hat ein CMD keine bedingten Parameter ist F9 und F10 identisch.

Ebenso *korinthenkack*

[Pikachu]

Der Unterschied zwischen F9 und F10 ist 1, Parameter hin oder her.