如果我有一个调用另外两个COBOL DB2子程序的COBOL DB2程序，那么它将创建多少个DBRM、Package和Plan？如果我更改任何一个子程序，那么是否需要重新编译和绑定所有程序？我对DBRMs、Plans和Packages感到非常困惑。
祝好， Manasi
祝好， Manasi
2个回答
8
哦，这是一个非常庞大的话题，因此本答案将会被简化并且不完整。答案有点取决于你是否使用DB/2预编译器或协同编译器。对于这个答案，我将假设你正在使用预编译器。如果你正在使用协同编译器，原则基本相同，但机制略有不同。
目标是生成：
- 从您的COBOL源代码生成Load模块 - DB/2计划以为您的程序提供访问DB/2数据库的访问路径
中间的所有内容都支持创建适当的DB/2计划，使您的程序运行。
机制：
每个包含DB/2语句的程序和/或子程序都需要通过DB/2预编译器进行预处理。预编译器创建一个DBRM（数据请求模块）。预编译还通过注释掉所有的
由预编译生成的DBRM包含程序中包含的SQL语句列表以及DB/2用于将这些特定SQL语句与您的程序关联的其他信息。DBRM通常写入永久数据集（通常是PDS），然后输入到DB/2 Binder中，Binder将编译您程序中每个SQL语句的特定访问路径，以便DB/2实际使用。对于COBOL编译器所做的工作，Binder对于DB/2来说也是相同的功能。将DBRM视为您的源代码，将Binder视为编译器。
绑定DBRM时生成的访问路径信息需要存储在某个位置，以便在程序调用DB/2时可以找到并使用它。
将Binder输出放在哪里？您可以将其绑定到一个Package中，也可以直接绑定到一个Plan中。
最短的路线是将一组DBRM直接绑定到一个计划中。但是，与许多捷径一样，这可能不是最有效的方法（稍后我将谈到原因）。
大多数较大的系统不会直接将DBRM绑定到计划中，而是将其绑定到包中。绑定的包存储在DB/2子系统中（计划也是如此）。那么，什么是Package？包是一个绑定的单个DBRM。另一方面，计划通常包含多个DBRM的访问路径。
现在我们有一组包，每个包都包含了从给定程序派生的其相应DBRM的SQL访问路径。我们需要从这些中构建一个计划。为此，通常由您的数据库管理员创建一组绑定卡。绑定卡只是DB/2 Binder的一种“源代码”（它们不是打孔卡）。绑定卡定义了哪些包形成给定计划。然后将它们提交给Binder，它将它们组装成一个计划。注意：您可能还会听到提到Collections，这只是由您的DBA定义的已命名的包组合。
总结一下，我们有以下过程：
程序->（预编译器）->修改后的程序->（COBOL编译器）->对象->（链接）->加载模块 ->DBRM->（DB/2 Bind）->Package 绑定卡->（DB/2 Bind）->DB/2计划 ->包
这里的两个基本输出是加载模块（可执行的COBOL程序）和DB/2计划。程序和计划在JCL中结合在一起，在其中必须在EXEC语句中的某处给出计划名称以及要运行的程序。
通过这个简短而高度简化的背景，让我们尝试回答您的问题：
DBRM如何创建？
每个包含SQL EXEC语句的程序一个DBRM。
有多少个包被创建？
一个包由一个DBRM构成。源程序和包之间存在1:1的对应关系。
有多少个计划被创建？
任何给定的包都可以包含在多个集合或多个绑定卡集中。这意味着一个给定的包可能包含在多个计划中。
如果我更改了程序会受到什么影响？
如果您将DBRM直接绑定到计划中，则必须重新绑定使用该DBRM的每个计划。这可能是一项非常耗时且容易出错的建议。
然而，如果您将DBRM绑定到包中，则只需要重新绑定该包。由于程序和包之间存在1:1的对应关系，因此只需要进行单个绑定。仅当添加或删除定义其的绑定卡集中的包或集合时，才需要重新绑定计划。
从上面和这里可以清楚地看出使用包的优点，这就是为什么大多数商店不会将DBRM直接绑定到计划中，而是使用包。
目标是生成：
- 从您的COBOL源代码生成Load模块 - 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中，Binder将编译您程序中每个SQL语句的特定访问路径，以便DB/2实际使用。对于COBOL编译器所做的工作，Binder对于DB/2来说也是相同的功能。将DBRM视为您的源代码，将Binder视为编译器。
绑定DBRM时生成的访问路径信息需要存储在某个位置，以便在程序调用DB/2时可以找到并使用它。
将Binder输出放在哪里？您可以将其绑定到一个Package中，也可以直接绑定到一个Plan中。
最短的路线是将一组DBRM直接绑定到一个计划中。但是，与许多捷径一样，这可能不是最有效的方法（稍后我将谈到原因）。
大多数较大的系统不会直接将DBRM绑定到计划中，而是将其绑定到包中。绑定的包存储在DB/2子系统中（计划也是如此）。那么，什么是Package？包是一个绑定的单个DBRM。另一方面，计划通常包含多个DBRM的访问路径。
现在我们有一组包，每个包都包含了从给定程序派生的其相应DBRM的SQL访问路径。我们需要从这些中构建一个计划。为此，通常由您的数据库管理员创建一组绑定卡。绑定卡只是DB/2 Binder的一种“源代码”（它们不是打孔卡）。绑定卡定义了哪些包形成给定计划。然后将它们提交给Binder，它将它们组装成一个计划。注意：您可能还会听到提到Collections，这只是由您的DBA定义的已命名的包组合。
总结一下，我们有以下过程：
程序->（预编译器）->修改后的程序->（COBOL编译器）->对象->（链接）->加载模块 ->DBRM->（DB/2 Bind）->Package 绑定卡->（DB/2 Bind）->DB/2计划 ->包
这里的两个基本输出是加载模块（可执行的COBOL程序）和DB/2计划。程序和计划在JCL中结合在一起，在其中必须在EXEC语句中的某处给出计划名称以及要运行的程序。
通过这个简短而高度简化的背景，让我们尝试回答您的问题：
DBRM如何创建？
每个包含SQL EXEC语句的程序一个DBRM。
有多少个包被创建？
一个包由一个DBRM构成。源程序和包之间存在1:1的对应关系。
有多少个计划被创建？
任何给定的包都可以包含在多个集合或多个绑定卡集中。这意味着一个给定的包可能包含在多个计划中。
如果我更改了程序会受到什么影响？
如果您将DBRM直接绑定到计划中，则必须重新绑定使用该DBRM的每个计划。这可能是一项非常耗时且容易出错的建议。
然而，如果您将DBRM绑定到包中，则只需要重新绑定该包。由于程序和包之间存在1:1的对应关系，因此只需要进行单个绑定。仅当添加或删除定义其的绑定卡集中的包或集合时，才需要重新绑定计划。
从上面和这里可以清楚地看出使用包的优点，这就是为什么大多数商店不会将DBRM直接绑定到计划中，而是使用包。
- NealB
1
非常感谢Neal :) 这减少了我的困惑... :) - Manasi
0
3个DBRM，1个计划，
在包环境中，可以为3个包绑定，1个计划
如果我错了，请纠正我。
如果我错了，请纠正我。
- Shweta Tripathi
1
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接