SQLCODE -805: Package not found in plan

What it means

When a Db2 program is precompiled, the precompiler gives the program and its DBRM the same consistency token. The token ties that load module to that DBRM. The DBRM is then bound into a package in a collection. At run time Db2 looks for a package with the program's name and that token, in the collections listed in the plan's package list (PKLIST), or in the collection named by CURRENT PACKAGESET if the program sets it. If none matches, the first SQL statement fails with -805.

The message shows the full name Db2 searched for as location.collection.program.token, then the plan name and a reason code. Two reason codes cover most cases.

• Reason 02. The program name doesn't match any entry in the plan's package list. You see this when the list names packages one by one and this program isn't on it, or when CURRENT PACKAGESET names a collection the list doesn't cover.
• Reason 03. The name matched one or more entries, such as PAYCOLL.*, but none of those collections holds a package with this name and token. Either the package was never bound there, or the load module and the package came from different precompiles. With wildcard package lists this is the reason you'll see most.

Common causes

• The program was precompiled, compiled and link-edited, but the new DBRM was never bound. The new load module carries a token no package has.
• A new subprogram with SQL is being called, and no package was ever bound for it.
• The package was bound, but into a collection that isn't in the plan's PKLIST. With a list like PAYCOLL.* this shows up as reason 03.
• STEPLIB, JOBLIB or the CICS DFHRPL picks up a different copy of the load module than the one that matches the package, such as an old test version.
• A BIND replaced the package with a newer DBRM, but the job still runs the older load module.
• The bind failed, for example with -204 or -551, and nobody noticed. The old package is still there with the old token.
• The program sets CURRENT PACKAGESET to a collection that doesn't hold the package.

How to find the problem

1. Read the full name in the message. Note the collection, the program, the token (16 hex digits) and the reason code.
2. List the packages for the program with SELECT COLLID, HEX(CONTOKEN), VERSION, BINDTIME FROM SYSIBM.SYSPACKAGE WHERE NAME = 'PAYCALC'. If no row has the token from the message, the module that ran was never bound.
3. Check the plan's package list with SELECT COLLID, NAME FROM SYSIBM.SYSPACKLIST WHERE PLANNAME = 'PAYPLAN'. An entry like PAYCOLL with NAME * covers every package in that collection.
4. Find which load module actually ran. Check the STEPLIB and JOBLIB order, or the CICS program library concatenation, and compare the module's link-edit date with the package's BINDTIME.

How to fix it

• Bind the package from the DBRM made by the same precompile as the load module, into a collection the plan searches, for example BIND PACKAGE(PAYCOLL) MEMBER(PAYCALC) ACTION(REPLACE).
• If the collection is missing from the plan, add it with REBIND PLAN(PAYPLAN) PKLIST(PAYCOLL.*, ...). List every collection the plan needs, because the new list replaces the old one.
• Fix the load library concatenation so the job runs the module that matches the package.
• Precompile with VERSION(AUTO) so several versions of a package can live in one collection. Old and new load modules then both find a package during a rollout.
• Promote load modules and DBRMs together through your change tool, so one never moves without the other.

What it looks like

DSNT408I SQLCODE = -805, ERROR:  DBRM OR PACKAGE NAME DB2P.PAYCOLL.PAYCALC.18B2C4F00A1E3D27
         NOT FOUND IN PLAN PAYPLAN. REASON 03
DSNT418I SQLSTATE   = 51002 SQLSTATE RETURN CODE

Last reviewed 2026-10-12 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your z/OS, CICS or Db2 release.