我在AS400（iSeries）上设置了数据源，当Cognos通过客户端访问ODBC驱动程序访问它时，它会锁定AS400上的文件。即使报告关闭，文件也会保持锁定一段时间。这会导致更新数据源，重新组织文件，清除记录等问题。必须有一种方法可以强制ODBC驱动程序在检索数据时删除锁定...或者至少监视时间它保持不变。任何方向都将不胜感激。
感谢。
Cognos 10.1.0 .... iSeries V7R1M0
降压， 感谢您抽出时间发表评论....但是，我向您保证我的iSeries实际上正在运行V7R1M0，我从未说过我有一个记录锁。我说文件仍然锁定。我非常确定我的问题确实构成了Cognos通过客户端访问ODBC驱动程序访问AS400文件的特定方案，并锁定了该文件。然后保持锁定一段时间。我的问题是，是否有办法阻止Cognos保持对文件的锁定。在锁定发生后，我可以为iSeries上的随机文件访问提供错误消息，但是当我在寻找一种方法来解除锁定之前，我没有看到它的相关性......但我我肯定会收到CPF3203错误，告诉我它无法分配对象。
答案 0 :(得分：4)
IBM i 7.1不能在AS / 400或iSeries硬件上运行。这不是一个语义：在网上搜索ODBC和AS400将返回古老和无用的结果。
问题不包含特定错误消息，也不包含发生错误的特定方案。我猜你在CLRPFM上看到了一个对象锁（不是记录锁）。如果是这样，根本原因是数据库管理器没有完全关闭游标;由于性能原因，软关闭它们（有时称为伪关闭）。
如果您的非SQL进程需要对表进行独占锁定（例如SAVOBJ，CLRPFM，DLTF，RGZPFM等，那么您可以包含ALCOBJ命令，其参数设置为强制关闭任何伪闭合游标。 ALCOBJ OBJ((SOMSCHEMA/SOMETABLE *FILE *EXCL)) WAIT(1) CONFLICT(*RQSRLS)
如果我猜错了，请编辑问题以显示正在抛出错误的IBM i端采取的操作，以及错误的确切错误消息ID。
编辑：更好地解释锁定
任何ODBC访问，任何RPG记录级别访问，打开输入表的任何进程都会导致对表的锁定。如果I / O请求是只读的，则锁定级别为* SHRRD（共享以供读取）。如果I / O请求涉及更新，则锁定级别为* SHRUPD（共享以进行更新）。这是正常和理想的行为，不能被禁用，因为它发生在操作系统的深处，并且在IBM i的DNA中。
这些对象锁允许共享访问;如果您的Cognos进程在表上有* SHRUPD锁定，那么我的RPG程序仍然可以同时在同一个表中打开，读取，写入和更新记录。这就是所有现代数据库的运作方式。
通常，当出现这样的问题时，有一个服务器进程需要对表进行独占（* EXCL）锁定。典型的服务器端操作是CLRPFM，RGZPFM，SAVOBJ。如果Cognos使用* SHRUPD锁打开表（WRKOBJLCK会告诉您），像CLRPFM这样的服务器端进程无法获得* EXCL锁并将发出CPF3203 - 无法为文件分配对象。
有时会丢失的部分是伪关闭。典型的ODBC过程可能如下所示：
在DB2方面，人们会期望当关闭光标时＃39;步骤发生时，* SHRUPD锁定被释放。这不一定发生，因为DB2执行伪关闭，将光标留在内存中，以便下次Cognos执行完全相同的访问（除了使用不同的客户）。对于大多数操作，这不是问题 - 在Cognos可以随时请求访问的白天，谁需要在桌面上使用* EXCL锁定？但是我们的遗产并非如此简单，我们大多数人仍然拥有服务器端流程，可以快速执行CLRPFM以清除工作表中的批处理。这就是CPF3203发生的地方。
由于数据库管理器持有锁（而不是Cognos进程，它已断开连接！），我们需要告诉DB2我们要在执行CLRPFM之前执行硬关闭。 ALCOBJ CONFLICT（* RQSRLS）就是我们这样做的。这需要在执行CLRPFM的CL程序中添加。另一种方法是使用SQL清除表。在7.1中，我们可以在CL程序中发出SQL命令，因此我们可以执行RUNSQL＆＃39;从tempfile中删除＆＃39;而不是CLRPFM TEMPFILE。 - 作为SQL，它不需要在表上进行* EXCL锁定。
编辑：RGZPFM
RGZPFM的一些背景可能是有序的。很老的应用程序没有删除表中的记录：它们设置了一个删除的记录＆＃39;应用程序需要检查的字节。随着时间的推移，表格累积了越来越多的标记为已删除或不活动的记录。磁盘价格昂贵，这些记录是多余的，所以重组诞生了。通常，这是一个两步过程：将文件复制到临时副本，然后将其复制回来，省略删除＆＃39;。这工作正常，因为当交互式用户离开系统时，重组通常在晚上作为一天结束处理的一部分运行。另一个好处是将记录物理地按主键顺序排列;通过密钥读取程序的性能提高了。
更多现代应用程序能够在行上发出实际的物理DELETE操作，但该行仍占用空间。磁盘仍然很昂贵，所以RGZPFM诞生了。 RGZPFM仍然需要独家访问该表，原因与两步CPYF的原因相同。许多这些RGZPFM进程都是简单地继承而没有考虑在具有更多磁盘的更新（更快）硬件上进行实际重组的必要性。有些应用程序执行重组，因为我们总是这样做。＆＃39;
2014年，硬件非常快，磁盘非常便宜。可以创建表以重用已删除的记录 - 这是使用CREATE TABLE创建的表的默认值，并且极少数例外情况下没有性能问题 - 性能是RGZPFM的主要原因。 RGZPFM还有一个地方，它可用于包含许多已删除记录的大型表 - 稀疏表。如果你有一个导致全表扫描的SQL SELECT，那将会是性能损失。一般来说，这些表中没有很多;如果你有一个数百万行表，它可能是一个历史文件，并没有看到很多DELETE活动。但是，对于稀疏表具有数百万行且没有goot索引的少数情况，需要考虑一下。