SQLCODE -818 — load module and package out of step

The program that is running and the package it uses were not made by the same precompile. In Db2 12 and 13 the same mismatch normally shows as -805 reason 03; the fix is to bind the DBRM that belongs to the load module.

What happened

A batch step or transaction fails on its first SQL statement with SQLCODE -818 (SQLSTATE 51003), usually right after a program change was put in.

Program output via DSNTIAR (illustrative)Illustrative example

DSNT408I SQLCODE = -818, ERROR:  THE PRECOMPILER-GENERATED TIMESTAMP
         1B51A3E40C77D2F6 IN THE LOAD MODULE IS DIFFERENT FROM THE BIND
         TIMESTAMP 1B2C88F1D4A09E35 BUILT FROM THE DBRM FEECALC
DSNT418I SQLSTATE   = 51003 SQLSTATE RETURN CODE

What it means

When a Db2 program is precompiled, the precompiler writes the same timestamp (the consistency token) into two places: the DBRM and the modified program that is compiled and link-edited into the load module. BIND copies the DBRM's token into the package. At run time Db2 compares the token in the load module with the one in the package. -818 means they differ: the module and the package come from different precompiles.

Typical causes

The program was precompiled, compiled and link-edited again, but the new DBRM was never bound.
The bind step used another DBRM: an old copy kept for backout, a test library, or the wrong member.
An older or newer load module was picked up (STEPLIB order, a promotion that copied only the module).

-818 or -805?

In Db2 12 and 13 every DBRM is bound into a package, and Db2 finds the package by the load module's consistency token, so this mismatch usually shows as -805 reason 03. IBM's -818 page lists the same causes for plans and packages; whichever code you see, the cause and the fix are the same.

Where to look

The two timestamps and the DBRM name in the message.
SYSIBM.SYSPACKAGE: SELECT COLLID, NAME, HEX(CONTOKEN), BINDTIME, PDSNAME FROM SYSIBM.SYSPACKAGE WHERE NAME = 'program'. PDSNAME is the library the package was bound from.
The change record and the output of its precompile, link-edit and bind steps: which libraries did each use?

How to fix it

Decide with the application owner which version should run (usually the new one).
Bind the DBRM from the same precompile as that load module: BIND PACKAGE(collection) MEMBER(program) LIBRARY('dbrm.library') ACTION(REPLACE).
Or, for a backout, put back the old load module and bind (or keep) the old DBRM that matches it.
Rerun and check the program gets past its first SQL statement.

Interview question

A program fails with -818 the morning after a change. What do you check, and what do you do?