如果我有 1 个 COBOL DB2 程序正在调用 2 个其他 COBOL DB2 子程序,那么它将创建多少个 DBRM、包、计划?如果我要更改任何一个子程序,那么我是否需要重新编译和绑定所有程序?我真的对 DBRM、计划和包感到困惑。
问候, 马纳西
哦,我的……这是一个很大的话题,所以这个答案将非常简化,因此不完整。
答案在某种程度上取决于您使用的是 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 直接绑定到一个 Plan 中。然而,与许多捷径一样,这可能不是最有效的做法(我稍后会谈到原因)。
大多数较大的系统不会将 DBRM 直接绑定到计划中,它们将绑定到包中。绑定的包存储在 DB/2 子系统中(与计划相同)。那么什么是包?包是绑定的单个DBRM。另一方面,计划通常包含多个 DBRM 的访问路径。
现在我们有一组包,每个包都包含从给定程序派生的各自 DBRM 的 SQL 访问路径。我们需要从这些中构建一个计划。为此,通常由数据库管理员创建一组绑定卡。Bind Cards 只是 DB/2 Binder 的一种“源代码”(它们不是穿孔卡片)。绑定卡定义了哪些包构成给定计划。然后将这些提交给 Binder,后者将它们组合成一个计划。注意:您可能还听说过 Collections,这些只是您的 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 的对应关系,因此只需进行一次绑定。唯一需要重新绑定计划的时间是在定义它的绑定卡集中添加或删除包或集合时。
使用 Packages 的优势从上面应该很清楚,这就是为什么大多数商店不直接将 DBRM 绑定到 Plans 中,而是使用 Packages。