Ermittlung des DB2-Subsystems mit SQL in QMF for Workstation

In den meisten Unternehmen existieren auf einem HOST-System mehrere DB2-Umgebungen. Bevor eine Query auf einem DB2-Subsystem ausgeführt wird, muss man in QMF for Workstation das gewünschte DB2-Subsystem auswählen (z.B. über das Menü –> Query –> Set Data Source). In DB2-Prozeduren kann man sich über CONNECT TO auf ein bestimmtes DB2-Subsystem verbinden. Alle Queries die im Anschluss ausgeführt werden, laufen automatisch auf diesem DB2-Subsystem.

Ist man sich nicht sicher, auf welcher Umgebung eine Query ausgeführt wird, so kann man sich über die Abfrage auf ein spezielles Register in den Systeminformationen das DB2-Subsystem ausgeben lassen.

Im folgenden Beispiel wird aus den Systables die Information zu Tabellen in einem DB2-Subsystem ausgegeben. Zusätzlich wird das spezielle Register SYSIBM.SYSDUMMYE in CURRENT SERVER mit ausgegeben in dem das DB2-Subsystem aufgeführt ist:

SELECT 
    CURRENT SERVER AS DB2_SUBSYS
    ,TBCREATOR    AS SCHEMA
    ,TBNAME
    ,NAME         AS COL_NAME
    ,COLNO
    ,TYPENAME
    ,LENGTH
    ,FOREIGNKEY
FROM SYSIBM.SYSCOLUMNS, SYSIBM.SYSDUMMYE
  WHERE TBNAME like 'VWPO%'
  AND TBCREATOR = 'DBPOZS01'
ORDER BY 2,4

QMF for Workstation V10 – 256 offene Fenster, dann ist Schluss

Während meiner Arbeit mit DB2-Prozeduren bin ich auf eine nicht dokumentierte Beschränkung bezüglich der Anzahl von geöffneten Fenstern gestoßen. Hierbei reagiert QMF for Workstation in der Version 10 sehr „gelassen“. In meiner Prozedur werden über das import-Statement SQL-Queries importiert und nacheinander abgearbeitet. Obwohl die Systemvariable DSQQW_PROC_WNDWS auf 0 gestellt ist, werden bei mehr als 256 importierten Queries einige Fenster nicht geschlossen und die Verarbeitung wird ohne Fehlermeldung beendet. Offensichtlich ist die maximale Anzahl an geöffneten Fenstern auf 256 begrenzt. Ein statement zum vorzeitigen Schließen von Fenstern existiert leider nicht. Setzt man die Systemvariable DSQQW_PROC_WNDWS=0, so werden alle Fenster nach erfolgreicher Beendigung der Prozedur geschlossen – nicht jedoch, wenn mehr als 256 Fenster geöffnet wurden.

Als akzeptablen Workaround kann man die zu importierenden Queries in Sub-Prozeduren auslagern, welche dann in einer Haupt-Prozedur aufgerufen werden. Somit können Cluster von Subprozeduren gebildet werden und 256 x 256 Fenster geöffnet und die darin enthaltenen Queries ausgeführt werden. Das dürfte für die meisten Anwendungsfälle ausreichen ;-).