Showing posts with label Db2 packages. Show all posts
Showing posts with label Db2 packages. Show all posts

Saturday, 17 August 2013

DB2 BIND and REBIND: What They Do and When to Run Each


Db2 bind and rebind flow showing COBOL source, DBRM, BIND PACKAGE, BIND PLAN, REBIND, and package set
Binding turns static SQL into a runnable package.

A COBOL program with embedded SQL does not become runnable after compile alone. The SQL is precompiled into a DBRM, bound into a package, connected to a plan or package list, and then used by the job, CICS transaction, or IMS program at runtime.

This refresh explains Db2 binding and rebinding for mainframe developers: what BIND does, why REBIND is used, how collections and package sets affect runtime lookup, and what to check before promoting a changed program.

Where Binding Fits in a COBOL Db2 Build

A typical static SQL build has these steps:

  1. Precompile the COBOL source and extract SQL into a DBRM.
  2. Compile the modified COBOL source.
  3. Link-edit the load module.
  4. Bind the DBRM into a package.
  5. Bind or use a plan that includes the package.

If the package is missing or the plan cannot find it, the program can compile cleanly and still fail at runtime.

What BIND PACKAGE Does

BIND PACKAGE takes a DBRM and creates a package. During bind, Db2 validates SQL, checks object names, checks authorization, and selects an access path for static SQL statements.

BIND PACKAGE(CERTCOL)
     MEMBER(CERTPGM)
     ACTION(REPLACE)
     ISOLATION(CS)
     OWNER(DB2USER1)
     QUALIFIER(DB2USER1)

The package becomes the stored form of the program's static SQL. The access path chosen at bind time can change when statistics, indexes, SQL text, or bind options change.

What BIND PLAN Does

A plan is the runtime object that lets an application execute Db2 SQL. Modern static SQL designs usually bind DBRMs into packages and then bind a plan that references package collections through PKLIST.

BIND PLAN(CERTPLAN)
     PKLIST(CERTCOL.*)
     ACTION(REPLACE)
     ISOLATION(CS)

Using package lists means packages can be added or replaced in a collection without rebinding the plan every time.

Collections and Package Names

A collection is a group of associated packages. A package name is commonly referenced as collection.package. The collection is implicitly created the first time a package is bound into that collection.

Collections are useful for separating environments or application versions. For example, test packages can use CERTCOL while production packages use a different collection name.

CURRENT PACKAGESET

The CURRENT PACKAGESET special register can direct package lookup to a specific collection for dynamic package resolution scenarios. Older applications sometimes use it to force package searches into a chosen collection.

EXEC SQL
    SET CURRENT PACKAGESET = 'CERTCOL'
END-EXEC.

Use this carefully. If the collection name is wrong, the application can fail even when the package exists somewhere else.

What REBIND Does

REBIND rebuilds an existing package or plan without changing the source program. It is commonly used after RUNSTATS, index changes, catalog changes, or Db2 maintenance when access paths need to be refreshed.

REBIND PACKAGE(CERTCOL.CERTPGM)

REBIND can change access paths. That is useful when statistics have improved, but risky when a critical batch job depends on a stable path. Review high-risk packages before rebinding in production.

BIND ADD, BIND REPLACE, and REBIND

ActionUse whenCommon risk
ACTION(ADD)Creating a new package or plan.Fails if the object already exists.
ACTION(REPLACE)Program SQL changed and the package must be replaced.Can replace the wrong collection member if naming is sloppy.
REBINDProgram did not change, but access path or bind options need refresh.Can change a stable access path after statistics or index changes.

Binding While a Package Is in Use

Packages and plans can be locked during execution and bind processing. A package or plan generally cannot be rebound while the same object is actively running. A different package version, however, can be bound depending on how versioning and collections are set up.

This is why batch windows and CICS availability matter. Rebinding a package used by a high-volume transaction is not the same as rebinding a rarely used report package.

Bind Options That Affect Programs

Bind options can affect runtime behavior. Some options control isolation, ownership, qualifier resolution, package lookup, and environment restrictions.

BIND PLAN(CICSONLY)
     PKLIST(CERTCOL.*)
     ACTION(REPLACE)
     ISOLATION(CS)
     OWNER(DB2USER1)
     QUALIFIER(DB2USER1)
     ENABLE(CICS)

These settings should be reviewed as deployment controls, not just DBA syntax.

Freeing or Dropping Packages

Use FREE to remove packages or plans from the catalog when they are no longer needed.

FREE PACKAGE(CERTCOL.*)

A package can also be removed with SQL in environments that support the statement and required authorization:

DROP PACKAGE DB2USER.DB2CERT

Do not remove a package just because a load module is old. Confirm runtime references, collection usage, and fallback needs first.

Promotion Checklist

  • Confirm the DBRM member matches the COBOL source level.
  • Bind into the correct collection.
  • Confirm the plan or package list can find the package.
  • Review changed access paths for high-volume SQL.
  • Check authorization for the bind owner and runtime auth ID.
  • Keep fallback package/version details for production rollout.

How Binding Relates to Packages

This article focuses on bind and rebind actions. For a wider explanation of package structure, collections, plans, DBRMs, and static SQL promotion, see Db2 Packages Guide for COBOL Static SQL.

For access-path checks after bind or rebind, see Db2 SQL Optimization Tips for COBOL Programs and Db2 Indexing.

FAQ

What is the difference between BIND and REBIND in Db2?

BIND creates or replaces a package or plan from DBRM input. REBIND rebuilds an existing package or plan, often to refresh access paths after statistics, index, or catalog changes.

Does REBIND require a COBOL program change?

No. REBIND is commonly used when the program did not change but Db2 should reconsider access paths or bind options.

Why do collections matter in Db2 packages?

A collection groups related packages and helps plans or package lookup find the correct package version at runtime.

Binding is not an afterthought after compile. It is the point where Db2 validates the SQL, checks authority, and chooses the access path your COBOL program will use.

Db2 Objects Guide: Tables, Indexes, Views, Sequences, and Packages

Db2 object map showing database, table space, table, index, view, sequence, package, and storage group
Db2 objects are the named pieces SQL uses.

A COBOL program that runs EXEC SQL SELECT depends on more than one table name. Behind that statement are Db2 objects: a database, table space, table, columns, indexes, views, packages, and sometimes sequences or aliases. If one of those objects is missing, changed, or rebound incorrectly, the application can fail before it fetches a single row.

This refresh explains common Db2 objects from a mainframe application point of view. It keeps the broad object-reference intent, while linking out to the focused articles for table spaces, packages, views, indexing, and sequences.

What Is a Db2 Object?

A Db2 object is a named database item that Db2 can create, store, reference, secure, or use while processing SQL. Some objects hold data, some describe access paths, and some control how applications run static SQL.

A developer usually meets these objects through DDL, embedded SQL, bind jobs, promotion scripts, and catalog queries.

Db2 Object Map

ObjectMain purposeWhere a developer sees it
DatabaseLogical container for table spaces and index spaces.DDL, standards, storage planning.
Table spaceStores table data in Db2-managed structures.CREATE TABLESPACE, storage, partitioning.
TableStores rows and columns.SELECT, INSERT, UPDATE, DELETE.
IndexSupports access paths and uniqueness.EXPLAIN, tuning, unique constraints.
ViewPresents a named SELECT over tables or views.Security, simplified SQL, reporting.
SequenceGenerates numeric values.INSERT processing and surrogate keys.
PackageStores bound static SQL for a program.BIND PACKAGE, REBIND, promotion.
Storage groupDefines storage choices for physical objects.DBA-managed storage definitions.

Database

In Db2 for z/OS, a database is a logical grouping for table spaces and index spaces. It is not the same as a separate server or subsystem. A database can provide defaults and ownership structure for dependent objects.

CREATE DATABASE CUSTDB;

Application developers may not create databases every day, but database names appear in DDL reviews, migration scripts, and object naming standards.

Table Space

A table space is where table data is stored. Table space design affects space, partitioning, locking behavior, utilities, and performance operations. It is one of the key places where logical design meets physical storage.

CREATE TABLESPACE CUSTTS
  IN CUSTDB
  USING STOGROUP SYSDEFLT;

For a deeper treatment of PBG, PBR, page size, and partitioning choices, see Db2 Table Spaces Guide.

Table

A table stores rows and columns for one subject. Tables are the objects that most SQL statements directly reference.

CREATE TABLE CUSTOMER
 (CUST_NO     CHAR(10) NOT NULL,
  CUST_NAME   VARCHAR(60),
  STATUS      CHAR(1),
  PRIMARY KEY (CUST_NO));

The logical structure of tables, rows, columns, and keys is covered in Db2 Relational Database Anatomy.

Column and Data Type

Columns are part of a table definition. Each column has a data type, and that data type matters when a COBOL host variable receives or sends a value.

EXEC SQL
    SELECT CUST_NAME,
           STATUS
      INTO :WS-CUST-NAME,
           :WS-STATUS
      FROM CUSTOMER
     WHERE CUST_NO = :WS-CUST-NO
END-EXEC.

The host variables in the program must be compatible with the Db2 column definitions.

Index

An index is an object based on one or more table columns. Db2 can use indexes to avoid scanning a whole table, enforce uniqueness, support clustering, and improve join access.

CREATE INDEX IX_ACCOUNT_CUST
  ON ACCOUNT (CUST_NO);

An index is not a guarantee of speed by itself. Db2 chooses access paths based on SQL predicates, statistics, indexes, and cost. The related Db2 Indexing article covers this in more detail.

View

A view is a named SQL definition. It can hide columns, join tables, apply filters, or give a program a stable query shape while base tables change behind the view.

CREATE VIEW ACTIVE_CUSTOMER_V AS
SELECT CUST_NO,
       CUST_NAME
  FROM CUSTOMER
 WHERE STATUS = 'A';

Views can be simple, joined, aggregate, read-only, or updatable depending on their definition. See Db2 View Classification for the practical types.

Alias and Synonym

Aliases and synonyms let SQL reference another object through a different name. They are often used to simplify names or hide location details. In older Db2 notes, aliases and synonyms are often discussed together, but their scope and behavior are not identical.

For application teams, the main check is simple: confirm what object the name resolves to before changing SQL, grants, or deployment scripts.

Sequence

A sequence is a Db2 object that generates numeric values. Programs often use sequences when inserting rows that need generated identifiers.

INSERT INTO ORDER_HDR
       (ORDER_ID, CUST_NO, ORDER_DATE)
VALUES (NEXT VALUE FOR ORDER_SEQ,
        :WS-CUST-NO,
        CURRENT DATE);

For sequence options such as CACHE, NO CACHE, CYCLE, and NEXT VALUE FOR, see Db2 Sequences.

Package and Plan

Packages and plans are application-facing Db2 objects. A package contains bound static SQL for a program. A plan can include packages and is used at runtime by applications.

BIND PACKAGE(COLLID) MEMBER(PROG1) ACTION(REPLACE)
BIND PLAN(APPPLAN) PKLIST(COLLID.PROG1)

When a COBOL program changes its SQL, the DBRM and package path matters. The Db2 Packages Guide for COBOL Static SQL covers DBRM, BIND PACKAGE, REBIND, collections, and promotion checks.

Storage Group and Index Space

Storage groups and index spaces are usually DBA-facing objects. A storage group defines storage choices. An index space holds index data. Application developers do not normally change them in COBOL work, but these objects appear during DDL review, utility planning, and performance discussions.

Materialized Query Table

A materialized query table stores the result of a query definition. It can help avoid repeated expensive joins or aggregations when the design and refresh rules fit the workload. Use MQTs only when the maintenance cost is justified by the query savings.

Object Dependencies

Db2 objects depend on each other. A view depends on its base tables. A package depends on the SQL it was bound with. An index depends on a table. A table depends on a table space.

If this changesCheck this next
Table column definitionViews, packages, COBOL copybooks, host variables.
IndexEXPLAIN output, access paths, RUNSTATS.
Table spaceUtilities, storage, partitioning, recovery process.
PackageBind options, collection, plan/package list, runtime job.

Common Mistakes

  • Calling every named item a table when it might be a view, alias, or synonym.
  • Changing a column without checking packages and COBOL host variables.
  • Adding an index without running statistics or checking the access path.
  • Confusing database, table space, and table as if they were the same level.
  • Refreshing a package in the wrong collection during promotion.

FAQ

What are the main Db2 objects a COBOL developer should know?

A COBOL developer should know tables, columns, indexes, views, sequences, packages, plans, table spaces, and the basic dependency between those objects.

Is a Db2 package a database object?

Yes. A package is a Db2 object that stores bound static SQL for an application program. It is central to COBOL static SQL execution.

What is the difference between a table and a table space?

A table is the logical object that stores rows and columns. A table space is the storage object that holds table data.

When you know which object you are changing, you know what to check next: SQL text, DDL, indexes, packages, utilities, or COBOL host variables.

Db2 Packages Guide for COBOL Static SQL


Db2 package flow showing COBOL embedded SQL, DBRM, BIND PACKAGE, package, plan, and REBIND
Db2 packages hold prepared SQL and access paths.

A COBOL program with static SQL does not carry its access path inside the load module. During precompile, Db2 extracts embedded SQL into a DBRM. During bind, Db2 turns that DBRM into a package that records prepared SQL, bind options, authorization context, and the access path chosen for the SQL statements.

This refresh replaces the old C-oriented explanation with a Db2 for z/OS package guide for COBOL teams. It covers DBRMs, collections, packages, plans, BIND PACKAGE, REBIND, and the checks developers should make before promoting a static SQL change.

What Is a Db2 Package?

A Db2 package is a database object that contains the prepared form of static SQL statements from one program or routine. IBM's BIND PACKAGE documentation says the subcommand builds an application package, records the package description in catalog tables, and saves the prepared package in the directory.

For a COBOL application, the package is the Db2-side partner to the compiled and linked load module. If the load module and package do not match the same SQL level, the program can fail or run with the wrong assumptions.

COBOL Static SQL Build Flow

The build path matters because each output has a different job. The COBOL compiler handles host language code. Db2 handles embedded SQL through the DBRM and bind process.

Step Output Why it matters
Precompile Modified COBOL source and DBRM Separates SQL from COBOL source.
Compile and link-edit Load module Creates executable program code.
BIND PACKAGE Package in a collection Prepares static SQL and records access paths.
BIND PLAN or package list Runtime plan reference Connects run unit to packages.

DBRM, Package, Collection, and Plan

These four terms often get mixed together in incident calls. Keep them separate.

Term Meaning Common problem
DBRM Database request module created by precompile. Wrong DBRM library used during bind.
Package Bound SQL from a DBRM or copied package. Package not rebound after SQL or statistics change.
Collection Named group that contains packages. Runtime points to the wrong collection.
Plan Runtime object that can include a package list. Plan does not include the expected package collection.

BIND PACKAGE Example

Site JCL and options vary, but a package bind normally identifies the collection, DBRM member, action, owner or qualifier options, isolation level, and validation behavior.

BIND PACKAGE(ACCTCOLL) -
     MEMBER(ACCTPOST) -
     ACTION(REPLACE) -
     QUALIFIER(ACCT) -
     ISOLATION(CS) -
     VALIDATE(BIND) -
     EXPLAIN(YES)

Do not copy bind options blindly. ISOLATION(UR), RELEASE(DEALLOCATE), VALIDATE(RUN), and REOPT can be correct in one workload and wrong in another. Use the site standard unless there is a documented reason to deviate.

Package and Access Path

For static SQL, the access path is selected at bind or rebind time. That is why a COBOL program can slow down after a package rebind even when source code did not change. New RUNSTATS, index changes, subsystem function level, bind options, and SQL changes can all affect the path.

  • Capture EXPLAIN output when binding important packages.
  • Record the DBRM library, collection, package, and version used in the change.
  • Compare access paths before and after a rebind for high-volume programs.
  • Know the rollback option if the new package performs badly.

The related Db2 SQL Optimization Tips for COBOL Programs article covers access-path investigation in more detail.

REBIND PACKAGE

A rebind rebuilds an existing package using the current environment and selected options. It is common after RUNSTATS, index changes, SQL compatibility changes, or package maintenance. Rebind is powerful because it can improve performance without changing COBOL source, but it can also choose a worse path if statistics or options are wrong.

REBIND PACKAGE(ACCTCOLL.ACCTPOST) -
       APREUSE(WARN) -
       EXPLAIN(YES)

For production packages, make the rebind visible in the change record. Include package name, collection, owner, bind options, reason, expected benefit, and fallback plan.

Common Package Problems

Symptom Likely package issue Check
Program works in test but fails in production. Different collection or missing package. Plan PKLIST, collection, package name, and version.
SQL starts running slowly after maintenance. Access path changed during rebind. EXPLAIN before/after and RUNSTATS timing.
Authorization error appears at bind or run time. Owner or VALIDATE option mismatch. Package owner, binder authority, and object grants.
Old load module calls new SQL package. Promotion mismatch. Load library, DBRM, package timestamp, and change ticket.

Developer Checklist

  • Confirm the DBRM was generated from the same source level as the load module.
  • Confirm the package collection used by the runtime plan.
  • Review bind options with the DBA for high-volume programs.
  • Use EXPLAIN for SQL that can affect batch windows or online response time.
  • Keep package rollback details in the implementation plan.
  • Coordinate package changes with related DB2 Binding and Rebinding procedures.

FAQ

Is a Db2 package the same as a plan?

No. A package contains prepared SQL for a program or routine. A plan is a runtime object that can reference packages through a package list.

When should a package be rebound?

Rebind after relevant SQL, index, statistics, compatibility, or bind-option changes. For critical packages, compare access paths before and after the rebind.

Can a COBOL program run without its package?

No, static SQL needs the corresponding package or plan/package setup at runtime. The load module and Db2 package must be promoted together.

Package work is successful when the COBOL load module, DBRM, package collection, bind options, and access path all line up. Treat the package as part of the application deliverable, not an afterthought.

Db2 Stored Procedure Guide for COBOL Programs


Db2 stored procedure flow showing COBOL SQL CALL, procedure logic, Db2 tables, and result handling
Db2 stored procedures group database work behind CALL.

A COBOL batch step that sends five separate SQL statements across a distributed connection can spend more time waiting than working. A Db2 stored procedure can put those statements behind one CALL, run the database logic near the data, and return output parameters or result sets to the caller.

This article refreshes the original stored procedure page for Db2 for z/OS developers. It covers native SQL procedures, external procedures, parameters, result sets, COBOL calls, package/security checks, and the line between a stored procedure and a user-defined function.

What Is a Db2 Stored Procedure?

A Db2 stored procedure is a routine that is created at the database server and invoked with the SQL CALL statement. IBM documents CREATE PROCEDURE as the statement that defines an SQL procedure, or a version of a procedure, at the current server and specifies the procedure source statements.

A stored procedure is a good fit when the logic performs a database operation rather than a simple expression. It can validate input, run several SQL statements, return status values, and expose a stable interface to COBOL, Java, CICS, batch, or distributed applications.

When a Stored Procedure Is the Right Object

Use a stored procedure when the work is a unit of database behavior. Do not create one just to hide a single simple SELECT unless the procedure gives a clear operational benefit.

Requirement Stored procedure fit? Reason
Validate an account and insert an audit row. Yes Multiple SQL statements belong behind one controlled call.
Return customer detail rows to a service. Yes A procedure can return a dynamic result set when defined for it.
Normalize a one-column status code in a query. No A scalar UDF or direct expression is usually cleaner.
Run privileged database work from several applications. Maybe Security and package ownership can be controlled, but it needs careful grants.

Native SQL Procedure Example

A native SQL procedure is written in SQL PL. The example below returns a formatted employee name and a simple status code. It is intentionally small; production procedures should use site naming, error handling, and deployment standards.

CREATE PROCEDURE HR.GET_EMPLOYEE_NAME
       (IN  P_EMPNO     CHAR(6),
        OUT P_EMP_NAME  VARCHAR(40),
        OUT P_STATUS    CHAR(1))
  LANGUAGE SQL
  READS SQL DATA
  DYNAMIC RESULT SETS 0
P1: BEGIN
  DECLARE V_FIRST VARCHAR(12);
  DECLARE V_LAST  VARCHAR(15);

  SET P_STATUS = 'N';

  SELECT FIRSTNME, LASTNAME
    INTO V_FIRST, V_LAST
    FROM DSN8C10.EMP
   WHERE EMPNO = P_EMPNO;

  SET P_EMP_NAME = STRIP(V_LAST) || ', ' || STRIP(V_FIRST);
  SET P_STATUS = 'Y';
END P1;

The procedure has one input parameter and two output parameters. A caller should always check the output status and SQL return code. Do not assume a procedure completed business work just because the CALL returned to the program.

CALL from a COBOL Program

IBM's CALL statement reference describes how arguments map to stored procedure parameters. In COBOL, OUT and INOUT parameters must be host variables because Db2 needs somewhere to place returned values.

EXEC SQL
    CALL HR.GET_EMPLOYEE_NAME
         (:WS-EMPNO,
          :WS-EMP-NAME,
          :WS-STATUS)
END-EXEC.

IF SQLCODE = 0 AND WS-STATUS = 'Y'
   PERFORM WRITE-EMPLOYEE-LINE
ELSE
   PERFORM HANDLE-PROCEDURE-ERROR
END-IF.

Match host variable types to the procedure definition. If the procedure defines VARCHAR(40), use the correct varying-length host variable pattern or the site-standard DCLGEN copybook. The DB2 Host Variables and Structures article is the companion check when returned values look truncated or padded.

IN, OUT, and INOUT Parameters

Parameter direction is part of the interface. Changing it is not a cosmetic edit; it can break callers and package behavior.

Parameter type Meaning COBOL caller rule
IN Caller passes a value into the procedure. Can be a host variable or compatible expression.
OUT Procedure returns a value to the caller. Must be a host variable.
INOUT Caller passes a value and receives a possibly changed value. Must be a host variable and must be initialized before the call.

When a procedure returns an error, do not trust OUT parameter contents unless the procedure contract says they are set before the failing point. In many designs, the safer pattern is a status parameter plus logged diagnostics.

Returning Result Sets

A stored procedure can return result sets when it is defined with DYNAMIC RESULT SETS. This is useful for distributed callers and service layers that need a list of rows rather than a single output value.

CREATE PROCEDURE HR.LIST_DEPT_EMP
       (IN P_DEPTNO CHAR(3))
  LANGUAGE SQL
  READS SQL DATA
  DYNAMIC RESULT SETS 1
P1: BEGIN
  DECLARE C1 CURSOR WITH RETURN FOR
    SELECT EMPNO, FIRSTNME, LASTNAME
      FROM DSN8C10.EMP
     WHERE WORKDEPT = P_DEPTNO
     ORDER BY LASTNAME, FIRSTNME;

  OPEN C1;
END P1;

For COBOL callers, confirm how your site handles result-set locators or whether the procedure is mainly for DRDA/JDBC callers. A batch program that only needs one status value should not receive a cursor just because a result set looks flexible.

External Stored Procedures

An external stored procedure is implemented in a host language such as COBOL, C, Java, PL/I, or Assembler, then registered to Db2. Use this path when the procedure must reuse existing tested code or when the logic cannot be expressed cleanly in SQL PL.

CREATE PROCEDURE ACCT.POST_PAYMENT
       (IN  P_ACCOUNT_NO CHAR(12),
        IN  P_AMOUNT     DECIMAL(13,2),
        OUT P_STATUS     CHAR(1))
  LANGUAGE COBOL
  EXTERNAL NAME 'PAYPOST'
  PARAMETER STYLE SQL
  MODIFIES SQL DATA
  WLM ENVIRONMENT PAYWLM
  COMMIT ON RETURN NO;

External procedures need operational discipline: WLM environment, load library promotion, Language Environment options, RACF access, package grants, abend handling, and rollback behavior. A missing load module can turn a clean application deploy into a production call failure.

Stored Procedure or UDF?

The previous refreshed page covers Db2 User-Defined Functions. Keep the line clear: a UDF belongs inside an SQL expression; a stored procedure is called as a unit of work.

Question Choose stored procedure Choose UDF
Does the routine run multiple SQL statements? Usually yes Usually no
Is the routine called with SQL CALL? Yes No
Can it appear in a WHERE or select list? No Yes
Does it return output parameters or result sets? Yes No, except table functions return rows inside SQL.

Performance and Security Checks

A stored procedure can reduce network trips, but it can also hide expensive SQL behind a short call. Treat it like production code, not a shortcut.

  • Explain the SQL statements inside the procedure, especially statements that join large tables.
  • Confirm package ownership and EXECUTE privileges for the caller and underlying packages.
  • Choose READS SQL DATA or MODIFIES SQL DATA to match the actual procedure behavior.
  • Review COMMIT ON RETURN with the application transaction design.
  • For external procedures, verify WLM environment, RACF access, and load module availability.
  • Log enough status detail to diagnose failures without exposing sensitive data.

The Db2 SQL Optimization Tips for COBOL Programs post covers access-path work that should happen before a procedure is promoted.

Deployment Checklist

  • Keep procedure DDL, grants, package bind steps, and rollback DDL in the same change record.
  • Preserve parameter order and data types unless every caller is being changed at the same time.
  • Test null input, not-found conditions, duplicate-row conditions, and SQL error paths.
  • Check whether static callers need bind or rebind after adding the CALL.
  • Document result-set expectations for COBOL, JDBC, and service callers separately.
  • Run a production-volume test when the procedure replaces several remote SQL calls.

FAQ

How is a Db2 stored procedure called?

A Db2 stored procedure is called with the SQL CALL statement. COBOL programs use embedded SQL and pass host variables for parameters.

Can a stored procedure return rows?

Yes. A procedure can return dynamic result sets when it is defined for result sets and opens the relevant cursor before returning.

Should business logic be placed in a stored procedure?

Place database-centered business rules in a stored procedure when they need controlled SQL execution near the data. Keep screen flow, file formatting, and application orchestration outside the database routine.

A stored procedure should make database work easier to call and easier to control. If the procedure only hides unclear SQL, fix the SQL and interface before promoting it to production.

New In-feed ads