Colpire qualche limite con z / OS con autista t4 DB2 Connect JDBC

Question

Abbiamo un'applicazione di collegamento a DB2 su z / OS e, dopo un po ', sembra che ci sia un certo limite di risorse che è colpito sul lato mainframe. Dal momento che stiamo usando BIRT, sembra che l'unico controllo che abbiamo sul codice JDBC è con strofe del URL stesso. non abbiamo controllo diretto Java tramite la connessione o dichiarazioni (tranne che per la SQL sé ovviamente) anche se può essere possibile utilizzando Javascript all'interno della progettazione dei report. Così possiamo attivare il debug con qualcosa di simile:

jdbc:db2://machine.com:1234/INSTANCE:traceFile=c:/db2.txt;traceLevel=-1;

Alla fine l'applicazione utilizzando JDBC sarà semplicemente smettere e non più dati saranno scritti nel file di registro. Facendo un TSO NETSTAT sul mainframe mostra circa 50 sessioni in stato ESTABLISHED.

Ora sappiamo che questo è un problema sul lato mainframe in quanto, quando succede, non connessione JDBC a tale istanza funzionerà (da qualsiasi client). A quel punto, dobbiamo riavviare il database per continuare.

Googled un sacco di roba, alcuni dei quali sembra indicare che potrebbe essere necessario per commettere query prima di chiudere una sessione. Può essere che le sessioni possono essere detenuti aperta perché c'è qualcosa di sbagliato nel codice vicino BIRT (almeno in termini di ciò che si aspetta DB2).

Qualcuno ha provato nulla di simile prima d'ora? Come hai fatto a risolvere il problema (se non del tutto)? C'è un modo per risolverlo utilizzando solo le strofe URL JDBC o codice Javascript all'interno della progettazione dei report?

FWIW, stiamo usando DB2 9.1 e BIRT 2.2.1.

Answer 1

Questo è stato effettivamente risolto in un altro forum, sto copiando la soluzione qui per i posteri.

Si scopre c'è un parametro chiamato IDTHTOIN nella sezione DSN6FAC del lavoro parametri DB2 di montaggio / link (generalmente db2prefix .SDSNSAMP(DSNTIJUZ) anche se la configurazione può essere diversa) che è stato fissato a zero nel nostro caso. Questo parametro è il IDLE TIME OUT per filettature DDF e zero indica "nessun timeout".

L'impostazione di questo a 180 risolto il nostro problema. I fili che tenevano blocchi sono stati chiudere se non avessero avuto alcuna attività in quei tre minuti. L'impostazione a meno di 120 non è utile in quanto i fili vengono controllati solo ogni due minuti in ogni caso (in DB2 v9 almeno).

È inoltre necessario impostare CMTSTAT=INACTIVE per proteggere le discussioni ben educati (quelli che hanno liberato tutti i loro blocchi di risorse, ma sono ancora in mano il filo aperto).

Tenete a mente questo era okay per il nostro problema particolare in quanto i fili erano per i report. Il loro comportamento era tale che l'ha aperto una sessione, ha ottenuto i dati per il reporting, quindi non ha bisogno la sessione più. Se avete le sessioni di lunga durata, è necessario prestare attenzione (anche se qualsiasi sessione che mantiene i blocchi per più di tre minuti è sospetto in ogni caso).

Si dovrebbe modificare il membro DSNTIJUZ, eseguire il lavoro, allora o riciclare l'istanza DB2 o eseguire SET SYSPARM.

Grazie alle bods utile a IBM Australia (West Perth Lab) per nutting questo per me.