COBOL DB2程序 [英] COBOL DB2 program
问题描述
如果我有一个COBOL DB2程序正在调用另外两个COBOL DB2子程序，那么DBRM，Packages，它将创建几个计划？如果我正在改变任何一个子程序，那么我需要重新编译并绑定所有程序吗？我真的很困惑于DBRM，计划和软件包。
Manasi
哦我的...这是一个很大的话题，所以这个
的答案是非常简化，因此不完整。
答案在某种程度上取决于您是否使用DB / 2预编译器或协同编译器。对于这个
答案，我会假设你正在使用预编译器。如果你正在使用协同编译器，那么
的原理是相同的，但是机制有些不同。
这里的目标就是产生： / p>
- a从您的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通常写入
a永久数据集（通常为PDS），然后输入到
DB / 2 Binder，其中程序中每个SQL语句的特定访问
路径被编译为表示DB / 2
实际可以使用。绑定工具对于DB / 2与COBOL的编译器大致相同的功能。
将DBRM视为源代码，Binder作为编译器。
当DBRM绑定
时生成的访问路径信息需要存储在某处，以便在程序调用时可以找到并使用
DB / 2。
在哪里放置binder输出？您的选择是将其绑定到一个包或直接进入一个计划。
最短的路径是将一组DBRM直接绑定到一个计划中。
然而，与许多捷径一样，这可能不是
最有效的做法（稍后会介绍原因）。
最大的系统不会将DBRM直接绑定到计划中，它们将绑定到一个包中。绑定的
包存储在DB / 2子系统中（与Plan相同）。那么一个包呢？
一个包是绑定的单个 DBRM。另一方面，计划通常包含多个DBRM的
访问路径。
现在我们有一组软件包，每个软件包包含其相应DBRM的SQL访问路径，
是从给定的
程序派生的。我们需要从中构建一个计划。为此，通常由数据库管理员创建一组绑定卡
。绑定卡只是DB / 2 Binder的一个源代码
（它们不是打孔卡）。
绑定卡定义了给定计划中哪些包形成
。然后将它们提交给将其组装成计划的Binder。注意：
你也可以听到提及的集合，这些只是命名分组的
已由您的DBA定义。总而言之，我们有以下过程：
程序 - >（预编译器） - >修改程序 - >（COBOL编译器） - >对象 - >（链接） - >加载模块
- > DBRM - >（DB / 2绑定） - >软件包
绑定卡 - >（DB / 2绑定） - > DB / 2计划
包 - >
这里的两个基本输出是加载模块（您的可执行COBOL程序）和DB / 2计划。程序
和计划汇集在您的JCL中，您必须在EXEC语句
中的某个地方将计划名称与程序一起运行。
有了这个简短的，高度简化的背景，我们可以尝试回答你的问题：
如何创建DBRM？
每个程序包含一个DBRM SQL EXEC 语句
创建多少个包？
一个包是从一个DBRM构建的。源程序和软件包之间有1：1的对应关系
创建了几个计划？
任何给定的包可能包含在多个集合和/或多个绑定卡集中。这个
意味着给定的包可能会包含在多个计划中。
如果我更改程序有什么影响？ p>
如果将DBRM直接绑定到计划中，那么您必须重新绑定使用
DBRM的每个计划。这可能是一个非常耗时且容易出错的命题。
但是，如果将DBRM绑定到一个包中，则只需重新绑定该包。
由于程序和程序包之间有1：1的对应关系，因此只需单个绑定
即可完成。计划需要反弹的唯一时间是当从定义它的绑定卡集中添加或删除包或集合
时。
使用Packages应该从上面清楚，这就是为什么大多数
商店不直接将DBRM绑定到计划中，而是使用Packages。
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屋！
