QAQQINI über OLE zuweisen

[iseries]

Hallo zusammen!
Ich möchte einer OLE-Connetion eine spezielle QAQQINI zuweisen. Laut IBM geht dies über den Connection-String des OLE.
Ich verwende diesen:
@provider=N'IBMDA400', @provstr=N'Initial Catalog=DBNAME;Data Source=as400.FIRMA.de;Catalog Library List = lib1, lib2;Query Options File Library = MYLIB;'
sLeider funktioniert dies nicht. Nur wenn die QAQQINI in der QUSRSYS steht, wird sie auch für QZDASOINIT-Jobs verwendet. Dann allderings von allen. Kennt sich hier jemand aus?

[Fuerchau]

Siehe auch hier:
IBM System i Support: Software Technical Document : 23062121

Hast du auch das passende Release (V5R3) des IBMDA400 ?

[iseries]

Hallo! Das passende Release (VR4) und alle neuen PTFs sind vorhanden. Das angesprochene Dokument hatte ich auch vom IBM Support erhalten. Mit einem CL-Befehl über SQL geht es zwar, aber wenn der PJ-Job QZDASOINIT beendet und neu gestartet wird, ist die Einstellung wieder weg. Das Jobende und den Neustart kann man nicht vorhersagen und vor jeder Abfrage den CL-Befehl aufzurufen wiederstrebt mir. Aussehen würden die Statements (vom SQL-Server aus) so:
execute('CALL QSYS.QCMDEXC(''CHGQRYA QRYOPTLIB(bibliotheksname)'', 0000000028.00000 )') at verbindungsservername;
select*fromopenquery(verbindungsservername,'select * from bibliotheksname.qaqqini')

[BenderD]

was natürlich auch geht (falls VR4 nicht V4Rx meint), ist die QZDASOINIT Jobs nach bestimmten Kriterien (User, IP_Adresse) in unterschiedliche Subsysteme zu routen und das dann auf Subsystem Ebene zu regeln.

D*B

Hallo! Das passende Release (VR4) und alle neuen PTFs sind vorhanden. Das angesprochene Dokument hatte ich auch vom IBM Support erhalten. Mit einem CL-Befehl über SQL geht es zwar, aber wenn der PJ-Job QZDASOINIT beendet und neu gestartet wird, ist die Einstellung wieder weg. Das Jobende und den Neustart kann man nicht vorhersagen und vor jeder Abfrage den CL-Befehl aufzurufen wiederstrebt mir. Aussehen würden die Statements (vom SQL-Server aus) so:
execute('CALL QSYS.QCMDEXC(''CHGQRYA QRYOPTLIB(bibliotheksname)'', 0000000028.00000 )') at verbindungsservername;
select*fromopenquery(verbindungsservername,'select * from bibliotheksname.qaqqini')

[Fuerchau]

Es reicht, den QCMDEXC 1x direkt nach dem Connect durchzuführen, da deine Verbindung mit dem QZDA-Job verbunden bleibt, bis disconnected wird.

Allerdings bleibt diese Einstellung für den Job erhalten, so dass diese auch für die nächste Verbindung eines anderen Users gilt.
Hat dieser aber keine Berechtigung für deine Lib, gibt es ggf. Probleme.

Deshalb sollte vor Disconnect die Einstellung auf Default zurückgestellt werden !

Ich habe übrigens ein ähnliches Problem mit den Sprachlib's QSYS29xx.
Je nach User wird automatisch die Sprachlib QSYS29xx eingestellt.
Meldet sich aber wieder ein User mit der Stammsprache des Systems an, bleibt die letzte QSYS29xx leider erhalten, da für die Stammsprache diese Lib ja nicht vorhanden ist.
Lösung: Leere QSYS29xx der Stammsprache anlegen.

[BenderD]

... was natürlich schwierig ist, wenn der Connect über Timeout stirbt, oder anderweitig Client seitig abbricht.

Das mit der Sprachlib ist ein klassischer Fall für die Trennung in verschiedene Subsysteme, da gibt es in der SBSD extra einen Lib Eintrag für. An die Einstellung für die Serverjobs kommt man leider nur mit Oops Nerv dran, aber der Effekt belohnt die Mühe (its very easy, right click here and left click there and if the mouse is anywhere...)

D*B

Deshalb sollte vor Disconnect die Einstellung auf Default zurückgestellt werden !

Ich habe übrigens ein ähnliches Problem mit den Sprachlib's QSYS29xx.
Je nach User wird automatisch die Sprachlib QSYS29xx eingestellt.
Meldet sich aber wieder ein User mit der Stammsprache des Systems an, bleibt die letzte QSYS29xx leider erhalten, da für die Stammsprache diese Lib ja nicht vorhanden ist.
Lösung: Leere QSYS29xx der Stammsprache anlegen.

[Fuerchau]

Bei QZDA-Job's gestaltet sich die Trennung nach User etwas schwierig (ich habe zumindest keine Lösung gefunden).

QZDA-Jobs laufen als PJE's, sind also immer da (STRHOSTSVR natürlich vorausgesetzt).
Als User ist hier immer der QUSER vorgesehen.
Beim Verbindungsaufbau sucht sich das System einen freien QZDA-Job (ggf. wird auch ein neuer initiiert).
Erst danach wird der Job auf den DB-User gesetzt sowie die SYSLIBL angepasst.

QZDA-Job's nach User in verschiedene Subsysteme zu trennen ist derzeit (leider) nicht möglich.

Ich denke, auch bei Connection-Pooling wird es ähnliche Probleme geben, wenn bestimmte Jobattribute durch Nicht-SQL-Aufrufe verändert werden.

[BenderD]

Ergänzung: müsste sogar seit V5R1 gehen, siehe auch hier
IBM Redbooks | Managing OS/400 with Operations Navigator V5R1 Volume 6: Networking


das ist mittlerweile möglich, geh mal mit Operations Navigator entweder auf Server oder Subsystem und schau dir da mal die Kontext Menues an, ich habe momentan keinen Link zur Doku parat.

Bei QZDA-Job's gestaltet sich die Trennung nach User etwas schwierig (ich habe zumindest keine Lösung gefunden).

QZDA-Jobs laufen als PJE's, sind also immer da (STRHOSTSVR natürlich vorausgesetzt).
Als User ist hier immer der QUSER vorgesehen.
Beim Verbindungsaufbau sucht sich das System einen freien QZDA-Job (ggf. wird auch ein neuer initiiert).
Erst danach wird der Job auf den DB-User gesetzt sowie die SYSLIBL angepasst.

QZDA-Job's nach User in verschiedene Subsysteme zu trennen ist derzeit (leider) nicht möglich.

Ich denke, auch bei Connection-Pooling wird es ähnliche Probleme geben, wenn bestimmte Jobattribute durch Nicht-SQL-Aufrufe verändert werden.