DB2 系统运行时表,用于检索上次执行的 SQL 语句



大型机中是否有 DB2 系统表 - 批处理运行时登录?在 DB2 for i 系列中,有一个表函数QSYS2.GET_JOB_INFO(),它在运行时返回作业信息,包括状态(活动/完成(,最重要的是V_SQL_STATEMENT_TEXT- 上次 SQL 运行的语句。

场景: 我想在 Cobol 批处理作业中检索运行时执行的最后一个 SQL 语句。这样做的主要目的是确定在作业运行时是否已发出 COMMIT 或 ROLLBACK。目的是创建小程序,我们称之为"控制器",以便在发出提交或提交间隔甚至回滚时监视 DB2。更具体地说 - 这个"控制器"将充当迷你操作系统,并具有触发主程序的能力。

例如,如果主程序发出回滚,则"控制器程序"可以发出特定的业务逻辑并可以控制更新。可以在 DB2 连接的 T1 和 T2 类型中完成更新。通过这种方式,更新是在批处理客户端或 EXCI(使用 RRS 恢复的 EXCI(中运行的 Java 端完成的。

快速浏览 IBM Documentation for DB2 似乎表明"否"。

但是,虽然与您的情况不完全匹配,但这是我们过去所做的......

创建一个表,使用列APP_RESTART_DATA调用它,以唯一标识流程的执行。 我们使用PROC_NAMESTEP_NAME,因为我们仅限于批处理作业。 还要有一个KEY列和任何其他元数据,您可能会发现在重新启动情况下很有用。 有些人存储记录编号而不是实际的键值。

在控制器程序中,首先使用唯一标识符执行SELECT,以确定是否处于重新启动模式。 如果SQLCODE为 0,则表示您处于重新启动模式,并且将检索成功执行COMMIT的最后一个 KEY。 在这些情况下,您必须在输入数据中找到该键,然后立即开始对随后的数据进行正常处理。 如果您的SQLCODE为 100,则您未处于重新启动模式;在这些情况下,您可以在输入数据的开头开始正常处理。

当您处理输入数据并达到COMMIT点时,还要使用新的 KEYUPDATEAPP_RESTART_DATA表。 然后COMMIT. 我们的COMMIT点还由一个参数决定,该参数指示COMMITs之间要处理多少个逻辑工作单元。 如果需要在通常不换档的黄金班次期间运行批处理,我们可以减小此参数。

完成输入数据的处理后,DELETEAPP_RESTART_DATA表中流程的行。

捕捉ROLLBACK可能很棘手。 在代码中执行时,可以将APP_RESTART_DATA中的行标记为已执行ROLLBACK,但如果在异常终止情况下隐式执行,您可能会发现自己通过语言环境 CEEHDLR 可调用服务注册条件处理程序,以便获得控制权并指示发生了ROLLBACK

相关内容

  • 没有找到相关文章

最新更新