COBOL DB2 程序

Question

如果我有 1 个 COBOL DB2 程序正在调用 2 个其他 COBOL DB2 子程序，那么它将创建多少个 DBRM、包、计划？如果我要更改任何一个子程序，那么我是否需要重新编译和绑定所有程序？我真的对 DBRM、Plans 和 Packages 感到困惑。

问候， 玛纳斯

Answer 1

哦，我的...这是一个很大的话题，所以这个 答案将非常简化，因此不完整。

答案在某种程度上取决于您使用的是 DB/2 预编译器还是协同编译器。为了这 回答我会假设您使用的是预编译器。如果您使用的是协同编译器 原理大同小异，只是机制有些不同。

这里的目标是生成：

• 从您的 COBOL 源加载模块
• DB/2 计划为您的程序提供进入 DB/2 数据库的访问路径

介于两者之间的所有内容都支持创建适当的 DB/2 计划的机制 供您的程序运行。

机制

每个包含 DB/2 语句的程序和/或子程序都需要 由 DB/2 预编译器进行预处理。预编译器 创建一个 DBRM（数据库请求模块）。预编译还通过注释更改您的源程序 删除所有EXEC SQL...END-EXEC 语句并将它们替换为对DB/2 子系统的特定调用。 然后，您使用常规 COBOL 编译器编译预处理器发出的代码以生成目标模块，然后将其链接到可执行文件中。

预编译生成的 DBRM 包含一个包含的 SQL 语句的列表 在您的程序中加上 DB/2 使用的其他一些信息 将这些特定的 SQL 语句与您的程序相关联。 DBRM 通常被写入 永久数据集（通常是 PDS），然后输入到 DB/2 Binder 具体在哪里访问 程序中每个 SQL 语句的路径都被编译成 DB/2 的形式 实际可以使用。绑定器对 DB/2 的作用与编译器对 COBOL 的作用大致相同。 将 DBRM 视为您的源代码，将 Binder 视为编译器。

DBRM绑定时产生的访问路径信息 需要存储在某个地方以便可以定位和使用 当你的程序调用 DB/2 时。

在哪里放置活页夹输出？您的选择是将其绑定到包中或直接绑定到计划中。

最短的路线是将一组 DBRM 直接绑定到一个计划中。 然而，与许多捷径一样，这可能不是 最有效的做法（我稍后会谈到原因）。

大多数大型系统不会将 DBRM 直接绑定到计划中，它们会绑定到包中。界 包存储在 DB/2 子系统中（与计划相同）。那么什么是包？ 一个包是一个绑定的单个 DBRM。另一方面，计划通常包含 多个 DBRM 的访问路径。

现在我们有一组包，每个包都包含其各自 DBRM 的 SQL 访问路径 是从给定的 程序。我们需要从这些中构建一个计划。为此，一组绑定卡 通常由您的数据库管理员创建。绑定卡只是一种“源代码” 到 DB/2 活页夹（它们不是穿孔卡片）。 绑定卡定义了哪些包形成 给定的计划。然后将这些提交给 Binder，后者将它们组合成一个计划。笔记： 您可能还听说过 Collections，这些只是命名的 Packages 分组，它们具有 由您的 DBA 定义。

总而言之，我们有以下流程：

程序->（预编译器）->修改程序->（COBOL编译器）->对象->（链接）->加载模块 -> DBRM -> (DB/2 绑定) -> 包 绑定卡片 -> (DB/2 绑定) -> DB/2 计划 包裹 ->

这里的两个基本输出是加载模块（您的可执行 COBOL 程序）和 DB/2 计划。该程序 和计划一起出现在您的 JCL 中，您必须在 EXEC 语句中的某处给出计划名称 连同要运行的程序。

有了这个简短且高度简化的背景，让我们尝试回答您的问题：

如何创建 DBRM？

每个包含SQL EXEC 语句的程序一个 DBRM

创建了多少包？

一个包由一个 DBRM 构成。 Source Program和Package之间是1:1的对应关系

创建了多少个计划？

任何给定的包都可以包含在多个集合和/或多个绑定卡组中。这 表示一个给定的包可以包含在多个计划中。

如果我更改程序会受到什么影响？

如果您将 DBRM 直接绑定到计划中，则必须重新绑定使用的每个计划 那个 DBRM。这可能是一个非常耗时且容易出错的提议。

但是，如果您将 DBRM 绑定到一个包中，那么您只需要重新绑定该包。 由于 Program 和 Package 是 1:1 的对应关系，所以只有一个 bind 需要完成。唯一需要重新启动计划的时候是一个包或集合 从定义它的绑定卡集中添加或删除。

从上面应该可以清楚地看出使用包的优势，这就是为什么大多数 商店不直接将 DBRM 绑定到计划中，而是使用包。