大型机中是否有 DB2 系统表 - 批处理运行时日志？在 DB2 for i Series 中，有一个表函数QSYS2.GET_JOB_INFO()在运行时返回作业信息，包括状态（活动/完成），最重要V_SQL_STATEMENT_TEXT的是 - 最后一次 SQL 运行的语句。
场景：我想在 Cobol 批处理作业中检索运行时最后执行的 SQL 语句。这样做的主要目的是确定在作业运行时是否发出了 COMMIT 或 ROLLBACK。目的是创建一个小程序，我们称之为“控制器”，在发出 Commit 或 Commit interval 甚至 Rollback 时监控 DB2。更具体地说，这个“控制器”将充当迷你操作系统，并具有触发主程序的能力。
例如，如果主程序发出 ROLLBACK，“控制器程序”可以发出特定的业务逻辑并控制更新。可以在 T1 和 T2 类型的 DB2 连接中进行更新。通过这种方式，更新是在批处理客户端或在 EXCI 中运行的 Java 端完成的（EXCI 使用 RRS 恢复）。
快速浏览一下IBM Documentation for DB2似乎表明“否”。
但是，虽然与您的情况不完全匹配，但这是我们过去所做的...
创建一个表，APP_RESTART_DATA使用列调用它以唯一标识您的流程的执行。我们使用PROC_NAME并且STEP_NAME因为我们仅限于批处理作业。还有一KEY列和任何其他元数据，您可能会发现在重新启动情况下会有所帮助。有些人存储了记录号而不是实际的键值。
在您的控制器程序中，首先SELECT使用您的唯一标识符执行 a 以确定您是否处于重新启动模式。如果你得到一个SQLCODE0 的值，那么你就处于重新启动模式，并且将检索到最后一个COMMIT成功执行 a 的 KEY。在这些情况下，您必须在输入数据中找到该键，然后立即开始对数据进行正常处理。如果你得到了SQLCODE100，那么你就没有处于重启模式；在这些情况下，您可以在输入数据的开始处开始正常处理。
当您处理输入数据并达到一个COMMIT点时，UPDATE您的APP_RESTART_DATA表也会使用新的 KEY。然后COMMIT。我们的COMMIT观点还由一个参数决定，该参数指示要在COMMITs. 如果有必要在主要班次期间运行通常在班外运行的批处理过程，我们可以减少此参数。
当您完成输入数据的处理时，表DELETE中您的进程所在的行。APP_RESTART_DATA
捕捉ROLLBACK可能很棘手。您可以将您的行标记APP_RESTART_DATA为在代码中执行了ROLLBACK何时完成，但如果在异常结束情况下隐式完成，您可能会发现自己通过语言环境CEEHDLR可调用服务注册了条件处理程序，以便您获得控制并指示ROLLBACK发生了。