The bind process
The bind process establishes a relationship between an application program and its relational data. This step is necessary before you can execute your program. Currently, DB2 allows you two basic ways of binding a program: to a package, or directly to an application plan.
Even when they are bound into packages, all programs must be designated in an application plan. BIND PLAN establishes the relationship between DB2 and all DBRMs or packages in that plan. Plans can specify explicitly named DBRMs, packages, collections of packages, or a combination of these elements. The plan contains information about the designated DBRMs or packages and about the data the application program intends to use. It is stored in the DB2 catalog.
I am giving you one practical example to differentiate between plan and package and DBRM which i read recently in a book–
PLAN package and DBRM:-
Consider a grocery store analogy. Before going to a grocery store you prepare a shopping list. As you go through the list and you find an item in the list, you place the item in your shopping cart. After you pay for the items at the check-out counter, the counter person places item in your bag. You can think the purchasing item as DBRMs. The bag is the plan. You have multiple DBRMs(grocery items) in your plan(shopping bag).
In the package environment, rather than actually removing items from the shelf, you would mark on your shopping list the location of each item in the store. Later you gave the checked list to the counter person at the counter. The counter person then would place the list in the bag not the actual items. The Plan(bag) contains a list pointing to the physical location of the packages (grocery items) that are still on the self.
In addition to building packages and plans, the bind process:
Validates the SQL statements using the DB2 catalog. During the bind process, DB2 checks your SQL statements for valid table, view, and column names. Because the bind process occurs as a separate step before program execution, errors are detected and can be corrected before the program is executed.
Verifies that the process binding the program is authorized to perform the data accessing operations requested by your program’s SQL statements. When you issue BIND, you can specify an authorization ID as the owner of the plan or package. The owner can be any one of the authorization IDs of the process performing the bind. The bind process determines whether the owner of the plan or package is authorized to access the data the program requests.Selects the access paths needed to access the DB2 data your program wants to process.In selecting an access path, DB2 considers indexes, table sizes, and other factors. DB2 considers all indexes available to access the data and decides which ones (if any) to use when selecting a path to the data.
Advantages of packages
Ease of maintenance: When you use packages, you do not need to bind the entire plan again when you change one SQL statement. You need to bind only the package associated
with the changed SQL statement.
Incremental development of your program: Binding packages into package collections allows you to add packages to an existing application plan without having to bind the entire plan again. A collection is a group of associated packages. If you include a collection name in the package list when you bind a plan, any package in the collection becomes available to the plan. The collection can even be empty when you first bind the plan. Later, you can add packages to the collection, and drop or replace existing packages, without binding the plan again.
The Mainframe hub 