COBOL DB2程序

Question

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

问候， 玛纳斯

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直接绑定到一个Plan中。然而，就像许多捷径一样，这可能不是最有效的事情（稍后我会谈及其原因）。

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

现在我们有一套软件包，每个软件包包含其各自DBRM的SQL访问路径，其中 源自给定的 程序。我们需要从这些方面构建一个计划。为此，通常由您的数据库管理员创建一套绑定卡 。绑定卡只是DB/2 Binder（它们不是打孔卡）的一种“源代码” 。 绑定卡定义了给定计划的哪些包形成 。然后将它们提交给将其组装成计划的Binder。注意： 您也可能听到提及的集合，这些只是名称分组的软件包，其中 已由您的DBA定义。

总之，我们有以下过程：

 
    Program -> (Pre-Compiler) -> Modified Program -> (COBOL compiler) -> Object -> (Link) -> Load Module 
           -> DBRM -> (DB/2 Bind) -> Package 

    Bind Cards -> (DB/2 Bind) -> DB/2 Plan 
    Package(s) -> 

两个根本性这里输出是一个加载模块（可执行COBOL程序）和DB/2计划。程序 和Plan一起在您的JCL中，您必须将EXEC语句 中的计划名称与程序一起运行。

利用这短暂的，并且高度简化，背景，让我们尝试回答你的问题：

如何可以创建DBRMs？每含SQL EXEC陈述

程序

一个DBRM多少包创建？

包由一个DBRM构建而成。源程序和包装之间存在1：1的对应关系

创建了多少个计划？

任何给定的包可能包含在多个集合和/或多个绑定卡集中。这 意味着一个给定的包可能包含在多个计划中。

如果我改变一个程序受到什么影响？

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

但是，如果您将DBRM绑定到一个包中，那么您只需重新绑定该包。 由于程序和软件包之间存在1：1的对应关系，因此只需要执行一次绑定 即可。计划需要反弹的唯一时间是在定义它的绑定卡集中添加或删除包或集合 。

使用软件包的优势应该从上面清楚，这就是为什么大多数 商店不会将DBRM直接绑定到计划中，而是使用软件包代替。