我们有一个应用程序在z / OS下连接到DB2，过了一段时间，似乎在主机端遇到了一些资源限制。由于我们使用的是BIRT，因此我们对JDBC代码的唯一控制似乎是URL本身的节。我们没有对连接或语句的直接Java控制（当然除了SQL本身），尽管可以通过在报表设计中使用Javascript来实现。所以我们可以通过以下方式打开调试：
jdbc:db2://machine.com:1234/INSTANCE:traceFile=c:/db2.txt;traceLevel=-1;
最终，使用JDBC的应用程序将停止运行，不再有数据写入日志文件。在大型机上执行TSO NETSTAT会在ESTABLISHED州显示约50个会话。
现在我们知道这是大型机方面的问题，因为当它发生时， no 与该实例的JDBC连接将起作用（来自任何客户端）。此时，我们必须重新启动数据库才能继续。
我搜索了很多东西，其中一些似乎表明你可能需要在关闭会话之前提交查询。可能是会话可能被保持打开，因为BIRT关闭代码中存在错误（至少在DB2期望的方面）。
以前有没有经历过这样的事情？你是如何解决它的（如果有的话）？有没有办法通过在报表设计中仅使用JDBC URL节或Javascript代码来解决它？
FWIW，我们使用的是DB2 9.1和BIRT 2.2.1。
答案 0 :(得分：1)
这实际上是在另一个论坛上解决的，我在这里为后代复制解决方案。
事实证明，在DB2参数汇编/链接作业的IDTHTOIN部分中有一个名为DSN6FAC的参数（通常是 db2prefix .SDSNSAMP(DSNTIJUZ)，但您的设置可能在我们的案例中被设置为零。此参数是IDLE TIME OUT DDF个线程的CMTSTAT=INACTIVE，零表示“无超时”。
将此设置为180解决了我们的问题。如果在这三分钟内没有任何活动，那么持有锁的线程就会被关闭。将其设置为小于120是没有用的，因为无论如何每两分钟只检查一次线程（至少在DB2 v9中）。
您还应该设置DSNTIJUZ以保护行为良好的线程（已释放所有资源锁但仍保持线程打开的线程）。
请记住，这对于我们的特定问题是可以的，因为线程是用于报告的。他们的行为是打开一个会话，得到报告的数据，然后不再需要会话。如果你有长时间运行的会话，你需要小心（尽管任何持有超过三分钟锁定的会话都是可疑的。）
您应该编辑SET SYSPARM成员，运行作业，然后循环DB2实例或执行{{1}}。
感谢IBM澳大利亚（西珀斯实验室）提供的帮助，帮助我解决这个问题。