COBOL DB2程序

Question

如果我有一个COBOL DB2程序正在调用其他2个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直接绑定到计划中.然而,正如许多捷径一样,这可能不是最有效的事情(我稍后会谈到原因).

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

现在我们有一组Packages,每个Package包含从其给定程序派生的各自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计划.程序和计划在您的JCL中汇集在一起​​,您必须在EXEC语句中的某个位置提供计划名称以及要运行的程序.

有了这个简短而高度简化的背景,让我们试着回答你的问题:

如何创建DBRM？

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

创建了多少个包？

包由一个DBRM构成.源程序和包之间存在1:1的对应关系

创建了多少计划？

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

如果我改变了一个受影响的程序？

如果将DBRM直接绑定到计划中,则必须重新绑定使用该DBRM的每个计划.这可能是一个非常耗时且容易出错的主张.

但是,如果将DBRM绑定到Package中,则只需重新绑定该Package.由于Program和Package之间存在1:1的对应关系,因此只需要进行一次绑定.计划需要反弹的唯一时间是在定义它的绑定卡集中添加或删除包或集合时.

从上面可以清楚地看到使用Packages的优点,这就是为什么大多数商店不会将DBRM直接绑定到Plans中,而是使用Packages.