如果两者都是 db2 -cobol 程序，解释 db2-cobol 的执行过程的步骤
如果两个子程序都是 db2-cobol 程序，如何从主程序运行两个子程序？
我的主程序名为“Mainpgm1”，它正在调用名为“subpgm1”和“subpgm2”的子程序，它们是被调用的程序，我只喜欢静态调用。
实际上，我现在使用名为 package 的语句，而不是计划和一个成员，两者都在“db2bind”（绑定程序）中，以及一个具有 dsn 名称的 dbrmlib。
主要问题是，当我绑定两个 db2-cobol 程序时，“db2bind”中受影响的更改是什么。
同样，在“DB2RUN”（运行程序）中也是如此。
How to run two sub programs from a main program if both are db2-cobol programs?
My main program named 'Mainpgm1', which is calling my subprograms named 'subpgm1' and 'subpgm2' which are a called programs and I preferred static call only.
Actually, I am now using a statement called package instead of a plan and one member, both in 'db2bind'(bind program) along with one dbrmlib which is having a dsn name.
The main problem is that What are the changes affected in 'db2bind' while I am binding both the db2-cobol programs.
Similarly, in the 'DB2RUN'(run program) too.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
每个包含 SQL 的程序（或子程序）都需要进行预处理以创建 DBRM。然后将 DBRM 绑定到
在运行时由 LOAD 模块访问以获得正确的 DB/2 访问的 PLAN
它包含的 SQL 语句的路径。
您已经从将所有 SQL 放在一个程序中变成了多个子程序。基本流程
保持不变 - 您需要一个计划来运行该程序。
DBA 经常建议，如果您有多个包含 SQL 的子程序，那么您应该
为它们创建 PACKAGES，然后将 PACKAGES 绑定到 PLAN 中。什么曾经是一个
步骤过程现在有两个：
PACKAGES 有什么大不了的？
假设您有 50 个包含 SQL 的子程序。如果你创建
每个人都有一个 DBRM，然后将所有 50 个绑定到一个 PLAN 中，作为单个操作，它将进行
花费大量资源来构建计划，因为每个程序中的每个 SQL 语句都需要
进行分析并为其创建访问路径。当所有 50 个子程序都是新的时，这还算不错
或已被更改。但是，如果您有一个相对稳定的系统并且想要更改1个子程序，您可以
最终重新绑定所有 50 个 DBRMS 以创建计划 - 尽管 50 个中的 49 个尚未更改并且
最终将使用完全相同的访问路径。这不是一个很好的方法。它类似于编译
每次对其中任何一个进行更改时，都会显示全部 50 个子程序。
但是，如果为每个子程序创建一个 PACKAGE，则该 PACKAGE 才是真正需要构建的工作。
它包含与其关联的 DBRM 的所有访问路径。现在如果你只改变 1 个子程序
只需通过将单个 DBRM 重新绑定到 PACKAGE 集合中来重建其 PACKAGE，然后重新绑定 PLAN。
但是，将一组 PACKAGES（集合）绑定到一个 PLAN 中
与绑定系统中的所有 DBRM 相比，资源消耗要少得多。
一旦您有了包含程序中使用的所有访问路径的计划，就可以使用它。没关系
如果正在执行的 SQL 来自 subprogram1 或 subprogram2。只要您关联了 PLAN
对于正在运行的 LOAD 来说，一切都应该可以解决。
每个安装都有自己的命名约定和设置 PACKAGES、COLLECTIONS 的标准
计划。在进行进一步操作之前，您应该与数据库管理员一起查看这些内容。
以下是有关 DB/2 环境中程序准备的一些背景信息：
开发您的应用程序
Each program (or subprogram) that contains SQL needs to be pre-processed to create a DBRM. The DBRM is then bound into
a PLAN that is accessed by a LOAD module at run time to obtain the correct DB/2 access
paths for the SQL statements it contains.
You have gone from having all of your SQL in one program to several sub-programs. The basic process
remains the same - you need a PLAN to run the program.
DBA's often suggest that if you have several sub-programs containing SQL that you
create PACKAGES for them and then bind the PACKAGES into a PLAN. What was once a one
step process is now two:
What is the big deal with PACKAGES?
Suppose you have 50 sub-programs containing SQL. If you create
a DBRM for each of them and then bind all 50 into a PLAN, as a single operation, it is going
to take a lot of resources to build the PLAN because every SQL statement in every program needs
to be analyzed and access paths created for them. This isn't so bad when all 50 sub-programs are new
or have been changed. However, if you have a relatively stable system and want to change 1 sub-program you
end up reBINDing all 50 DBRMS to create the PLAN - even though 49 of the 50 have not changed and
will end up using exactly the same access paths. This isn't a very good apporach. It is analagous to compiling
all 50 sub-programs every time you make a change to any one of them.
However, if you create a PACKAGE for each sub-program, the PACKAGE is what takes the real work to build.
It contains all the access paths for its associated DBRM. Now if you change just 1 sub-program you
only have to rebuild its PACKAGE by rebinding a single DBRM into the PACKAGE collection and then reBIND the PLAN.
However, binding a set of PACKAGES (collection) into a PLAN
is a whole lot less resource intensive than binding all the DBRM's in the system.
Once you have a PLAN containing all of the access paths used in your program, just use it. It doesn't matter
if the SQL being executed is from subprogram1 or subprogram2. As long as you have associated the PLAN
to the LOAD that is being run it should all work out.
Every installation has its own naming conventions and standards for setting up PACKAGES, COLLECTIONS and
PLANS. You should review these with your Data Base Administrator before going much further.
Here is some background information concerning program preperation in a DB/2 environment:
Developing your Application