BINDCARD
A BINDCARD is a control card or input file used by the DB2 BIND command on z/OS to specify the parameters and options required to create or replace a DB2 package or plan. It contains information about the application program's SQL statements, typically referenced via a Database Request Module (DBRM), and various BIND options that govern how DB2 optimizes and executes those statements.
Key Characteristics
-
- Input to BIND Command: It serves as the primary input for the
DB2 BINDutility, which processes DBRMs to create executable access paths. - Contains BIND Options: Specifies crucial options such as
ISOLATION LEVEL,ACQUIRE,RELEASE,VALIDATE,OWNER,QUALIFIER,DEGREE,CURRENTDATA, andEXPLAIN. - References DBRM(s): Typically points to one or more DBRMs, which are output files from the DB2 precompiler containing extracted SQL statements from application programs (e.g., COBOL, PL/I).
- JCL Integration: Often embedded within a JCL stream as
SYSINdata or referenced as aDDstatement pointing to a dataset containing the BIND options. - Impacts Performance: The choices made for BIND options directly influence the access paths chosen by the DB2 optimizer, significantly affecting application performance.
- Version Control: Critical for maintaining consistency and reproducibility of application deployments, often managed under source code control systems.
- Input to BIND Command: It serves as the primary input for the
Use Cases
-
- Initial Program Deployment: Binding a new COBOL or PL/I application program for the first time to create its corresponding DB2 package or plan.
- Application Code Changes: Rebinding an existing program after modifications to its SQL statements or application logic, requiring a new DBRM.
- DB2 Catalog Updates: Rebinding programs when DB2 statistics change, new indexes are added, or DB2 subsystem parameters are altered, to allow the optimizer to choose potentially better access paths.
- Performance Tuning: Experimenting with different BIND options (e.g.,
ISOLATION LEVEL,OPTIMIZE FOR) to fine-tune the performance of SQL statements within an application. - Creating Stored Procedures/UDFs: Used to bind the SQL logic embedded within DB2 stored procedures or user-defined functions.
Related Concepts
A BINDCARD is intrinsically linked to the DB2 BIND process and DBRMs. A DBRM (Database Request Module) is generated by the DB2 precompiler from an application program's source code (e.g., COBOL) and contains the SQL statements. The BINDCARD then instructs the BIND command on how to process this DBRM to create a PACKAGE (a collection of DBRMs) and/or a PLAN (an executable object that defines access paths). This entire process is fundamental to how COBOL and other host language applications interact with DB2 for z/OS.
- Version Control: Always keep BINDCARDs under strict version control, ideally alongside the application source code and DBRMs, to ensure reproducibility and auditability.
- Standardize Options: Define and enforce standard BIND options for different types of applications or environments (e.g., production vs. test) to maintain consistency and predictability.
- Use
EXPLAIN: IncludeEXPLAIN(YES)in your BINDCARDs during development and testing to capture access path information, which can then be analyzed usingDB2 EXPLAINtools to identify and optimize inefficient SQL. - Test Rebinds: Before deploying a rebind to production, always test it thoroughly in a pre-production environment to verify performance and functionality, especially after DB2 upgrades or significant data changes.
- Minimize Scope: When possible, bind individual packages rather than entire plans to minimize the impact of changes and reduce the risk of affecting unrelated application components.