多年来，至少8年来，我们公司每天都在运行一个从未失败的过程。客户端没有任何改变，但我们最近在System i上升级到V7R1。旧进程的第一次运行失败，并且向客户端报告了Cursor not open消息，这也是作业日志中的所有内容。我偶尔会看到Error -501，SQLSTATE 24501。
我得到了IBM和DataDirect（ODBC驱动程序的提供者）。 IBM表示这是一个客户端问题，DataDirect挖掘日志并发现当从光标请求下一个记录块时会发生此错误。他们没有看到系统我提醒客户光标已关闭的迹象。
在故障排除中，我注意到ODBC驱动程序有一个WITH HOLD选项，默认情况下会选中它。如果我取消选中它，这个特殊问题就会消失，但它会引入另一个问题（无限循环），这个问题更严重。
没有一个共同的主题导致这些错误，我看到的唯一一个导致这是在循环通过一个相当大的结果集时进行一些处理。它似乎与时序或特定表或表类型无关。外部循环有时是具有许多数据类型的大型表，有时是小型表，只有CHAR（10）和CHAR（8）数据类型。
我真的不希望在这里得到答案，因为这是一个非常深奥的情况，但总有一些希望。
IBM已经解决了其他问题，让我们将PTF应用到数据库级别为36。我绝不是System i专家，只是一个Java程序员，他必须处理这个与Java无关的问题。
由于
答案 0 :(得分：1)
这适用于那些可能遇到类似问题的其他人。事实证明这是导致问题的QRWTSRVR代码中的错误。驱动程序在单个作业中打开了多个连接，并在至少2个连接中使用相同的游标名称。一旦这些游标中的一个被关闭，QRWTSRVR将错误地尝试使用关闭的游标并返回错误。以下是PTF求职信的描述：
A QRWTSRVR job with 2 cursors named C01 takes a MSGSQL0501
error when trying to fetch from the one that is open. The DB2
code is trying to use the cursor which is pseudo closed.
PTF SI57756解决了这个问题。我不知道这个PTF一般会被释放，但是如果你发现这个帖子是因为类似的问题，希望这会帮助你纠正它。
答案 1 :(得分：0)
这就是我修复iseries上DB问题的方法。
开始记录iseries上的表或更改与iseries的连接以commit = * NONE。
对于日记我建议使用两个日记本，每个日记都有自己的接收器。
一个日记用于表格，其变化相对较少，如美国国家/地区的表格，或者每月更新少于10次的表格。这样您就可以确定何时更改数据以进行审计。保持该期刊的所有接收器永远在线。
一张日记用于表格，当天有很多变化。当您无法再负担他们占用的空间时，请删除这些期刊的接收者。
如果期刊或提交*无法解决问题。您需要查看sysixadv表，长时间运行的查询可能会破坏ODBC连接。
SELECT SYS_TNAME，TBMEMBER，INDEX_TYPE，LASTADV，TIMESADV，ESTTIME，
原因，＆＃34; PAGESIZE＆＃34;，QUERYCOST，QUERYEST，TABLE_SIZE，NLSSNAME，
NLSSDBNAME，MTIUSED，MTICREATED，LASTMTIUSE，QRYMICRO，EVIVALS，
FIRSTADV，SYS_DNAME，MTISTATS，LASTMTISTA，DEPCNT FROM sysixadv
ORDER BY ESTTIME desc
也按时间顺序排序
修复这些查询可能会创建建议的索引。
答案 2 :(得分：0)
您使用的是哪种ODBC驱动程序？
如果您正在使用IBM i Access ODBC驱动程序，则APAR SE61342可能会修复此问题。驱动程序始终没有处理来自服务器的返回代码，表明结果集已关闭，并且在SQLCloseCursor函数期间，驱动程序将向服务器发送一个关闭命令，这将返回错误，因为服务器已经已关闭光标。请注意，您不必在SP11遇到这种情况，它只是让它更容易命中，因为我在该fixpack中的更多情况下启用了预取。检查是否存在问题的简单测试是禁用DSN的预取或在连接字符串上传递PREFETCH = 0.
如果你正在使用DB2 Connect驱动程序，那我就无法提供很多帮助，抱歉。