DB2 Plans, Collections, Packages, Etc

DB2 DBRMs, Collections, Packages, and Plans

This document is a technical summary of these 4 DB2 objects and how they relate. It is not a complete summary of command options and authorization requirements.

Object Type Contents How Created Authority needed (if not SYSADM) DBRM SQL for a source Input: Source Program None program Command: DB2 Precompile Program (dependent on source language)

Output: DBRM PACKAGE Bound SQL for a A PACKAGE is initially created with the BIND PACKAGE. The actual name of the To BIND a PACKAGE source program package is a 4 part name: Complicated, but simplistically, the OWNER location name.collection id.DBRM member name.version must have all: where version is determined by precompiler options but is typically a timestamp.  SQL authority for all statements in package Input: DBRM  BINDADD (for new package) or BIND (for existing package) Command:  CREATE IN or PACKADM for specified collection BIND PACKAGE (location name.collection id) OWNER (authid of package owner) Also, if the Binder is not equal to OWNER, QUALIFER (for unqualified SQL) then Binder must be in an ACF2 Source MEMBER (DBRM member name) Group containing OWNER LIBRARY (DBRM PDS name) + additional parameters To execute a PACKAGE for a program EXECUTE on the PLAN containing the Output: PACKAGE for the program. Package residing in the specified collection If executing through DRDA when no PLAN Note: exists on the local DB2 system, then Location name does not need to be specified if BIND command executed on same DB2 EXECUTE on the PACKAGE or on

D:\Docs\2017-11-29\01b9fc4ea7092c73b7986f02c188641f.doc - 1 - subsystem as where BIND is taking place collection id.* containing the PACKAGE

COLLECTION A group of bound A collection is NOT explicitly created (There is no CREATE COLLECTION SQL To bind a package in a collection: PACKAGES statement). It is implicitly created the first time a BIND PACKAGE into a CREATE IN for the specific collection collection with that name is executed (+ whatever authorities are needed for the package itself) A package is added or replaced in a COLLECTION via the BIND PACKAGE command

PLAN A group of bound A PLAN is initially created via the BIND PLAN statement To BIND a PLAN DBRMS and/or DBRMs specified in the BIND PLAN command must already exist Complicated, but simplistically, the OWNER PACKAGES PACKAGES specified in the BIND PLAN command do not need to exist must have all:

Input: DBRMs and/or a list of PACKAGES. This list of packages can be wildcarded as  SQL authority for all statements in described below DBRMs specified (this authority is NOT necessary for packages included in the Command: PKLIST since they are already bound) Similar to BIND PACKAGE with the important addition of PKLIST  BINDADD (for new plan) or BIND (for existing plan) BIND PLAN (plan name)  For explicitly specified packages: OWNER (authid of plan owner) EXECUTE authority (or PACKADM) QUALIFER (for unqualified SQL) on each explicitly specified package or on MEMBER (DBRM member name, …) collection id.* containing an explicitly LIBRARY (DBRM PDS name) specified package PKLIST (location name.collection id.package id, …)  For collection id.*: + additional parameters EXECUTE authority (or PACKADM) on collection id.*

Also, if the Binder is not equal to OWNER, Output: then Binder must be in an ACF2 Source The BIND PLAN command (for a new PLAN) does two things: Group containing OWNER 1. Any DBRMs specified are bound in the same way that BIND PACKAGE binds DBRMs To execute a PLAN for a program 2. Creates a PLAN object contains all DBRMs specified and the list of packages EXECUTE on the PLAN containing the specified. bound DBRM or PACKAGE for the program.

D:\Docs\2017-11-29\01b9fc4ea7092c73b7986f02c188641f.doc - 2 - Notes on PKLIST (location name.collection id.package id) parameter:

1. Any or all of location name, collection id, and package id may be wildcarded with *. This allows future BIND PACKAGE (location name.collection id) commands to bind additional packages into the PLAN without needing additional BIND PLANs 2. Typically at NEES, BIND PLAN specifies PKLIST (collection id.*). This results in location name defaulting to the local location (DB2A or DSNP) and includes ALL packages that are or will ever be bound into a specific collection.

Example: The DBA first issues BIND PLAN (PSFTDPLB) PKLIST (PSFTDCOL.*) to create a DEV Plan PSFTDPLB to include ALL packages which are or will ever be bound into the DEV Collection PSFTDCOL via BIND PACKAGE (PSFTDCOL) MEMBER (DBRM member name) LIBRARY (DBRM PDS name) commands

The developer then issues BIND PACKAGE (PSFTDCOL) MEMBER (PIP250) LIBRARY(TESTPSFT.HRDEV.DRMLIB). This creates a package named DB2A.PSFTDCOL.PIP250.version where version = a timestamp.

D:\Docs\2017-11-29\01b9fc4ea7092c73b7986f02c188641f.doc - 3 -