COBOL DB2 程序 [英] COBOL DB2 program
问题描述
如果我有 1 个 COBOL DB2 程序正在调用 2 个其他 COBOL DB2 子程序，那么它将创建多少个 DBRM、包、计划?如果我要更改任何一个子程序，那么我是否需要重新编译和绑定所有程序?我真的对 DBRM、Plans 和 Packages 感到困惑.
问候，玛纳斯
哦，天哪...这是一个巨大的话题，所以这个答案将非常简化，因此不完整.
答案在某种程度上取决于您使用的是 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 绑定到计划中，而是使用包.
If I have 1 COBOL DB2 program which is calling 2 other COBOL DB2 sub programs, then how many DBRMs,Packages,Plans it will create? If I am changing any one of the sub program then do I need to recompile and bind all the programs?I am really confused with DBRMs,Plans and Packages.
Regards, Manasi
Oh my... This is a huge topic so this answer is going to be very simplified and therefore incomplete.
The answer depends somewhat on whether you are using the DB/2 pre-compiler or co-compiler. For this answer I will assume you are using the pre-compiler. If you are using the co-compiler the principle is pretty much the same but the mechanics are a bit different.
The goal here is to generate:
- a Load module from your COBOL source
- DB/2 Plan to provide your program with access paths into the DB/2 database
Everything in between just supports the mechanics of creating an appropriate DB/2 Plan for your program to run against.
The Mechanics
Each program and/or sub-program containing DB/2 statements needs
to be pre-processed by the DB/2 pre-compiler. The pre-compiler
creates a DBRM (Data Base Request Module). The pre-compile also alters your source program by commenting
out all the EXEC SQL...END-EXEC statements and replaces them with specific calls to the DB/2 subsystem.
You then use the regular COBOL compiler to compile the code emitted by the pre-processor to produce an object module which you then link into an executable.
The DBRM produced by the pre-compile contains a listing of the SQL statements contained in your program plus some other information that DB/2 uses to associate these specific SQL statements to your program. The DBRM is typically written to a permanent dataset (usually a PDS) and then input to the DB/2 Binder where the specific access paths for each SQL statement in your program are compiled into a form that DB/2 can actually use. The binder does for DB/2 roughly the same function as the compiler does for COBOL. Think of the DBRM as your source code and the Binder as the compiler.
The access path information produced when the DBRM is bound needs to be stored somewhere so that it can be located and used when your program calls DB/2.
Where to put the binder output? Your options are to bind it into a Package or directly into a Plan.
The shortest route is to bind a group of DBRMs directly into a Plan. However, as with many short cuts, this may not be the most efficient thing to do (I will touch upon the reason later on).
Most larger systems will not bind DBRMs directly into Plans, they will bind into a Package. The bound Package is stored within the DB/2 sub-system (same way a Plan is). What then is a Package? A Package is a bound single DBRM. A Plan, on the other hand, typically contains the access paths for multiple DBRMs.
Now we have a set of Packages, each Package contains the SQL access paths to its respective DBRM which was derived from a given program. We need to construct a Plan from these. To do this, a set of Bind Cards is created, usually by your Data Base Administrator. Bind Cards are just a sort of "source code" to the DB/2 Binder (they are not punched cards). The Bind Cards define which Packages form a given Plan. These are then submitted to the Binder which assembles them into a Plan. Note: you may also hear mention of Collections, these are just named groupings of Packages that have been defined by your DBA.
To summarize, we have the following process:
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) ->
The two fundamental outputs here are a Load Module (your executable COBOL program) and a DB/2 Plan. The Program and Plan come together in your JCL where you have to give the Plan name somewhere within the EXEC statement along with the program to run.
With this brief, and highly simplified, background, lets try to answer your questions:
How may DBRMs are created?
One DBRM per program containing SQL EXEC statements
How many Packages are created?
A package is constructed from one DBRM. There is a 1:1 correspondence between Source Program and Package
How many Plans are created?
Any given Package may be included in multiple Collections and or multiple Bind Card sets. This means that a given Package may be included in multiple Plans.
If I change a program what is affected?
If you bind your DBRM directly into a Plan, then you must rebind every Plan that uses that DBRM. This can be a very time consuming and error prone proposition.
However, if you bind your DBRM into a Package, then you only need to rebind that Package. Since there is a 1:1 correspondence between Program and Package, only a single bind needs to be done. The only time the Plan needs to be rebound is when a Package or Collection is added or removed from the Bind Card set that defines it.
The advantage of using Packages should be clear from the above and this is why most shops do not bind DBRMs directly into Plans, but use Packages instead.
这篇关于COBOL DB2 程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
