SQLCODE -818: Timestamp mismatch between program and DBRM

What it means

The Db2 precompiler writes a consistency token, normally based on the time of the precompile, into two places. One copy goes into the changed source and ends up in the load module. The other goes into the DBRM, which is bound later. At run time Db2 compares them. If they differ, the load module and the bound SQL weren't built from the same precompile, and running it could execute the wrong SQL. Db2 stops it with -818. The message shows both tokens in hex and the DBRM name.

On current Db2 for z/OS, programs run through packages, and Db2 uses the token to find the package in the first place. So a mismatch there normally appears as -805 reason 03 instead. -818 is more typical of Db2 for LUW, and of older plans that had DBRMs bound straight into them, which Db2 10 and later no longer allow. The causes and the cure are the same as for -805.

Common causes

• The program was precompiled and compiled again, but the new DBRM wasn't bound.
• The DBRM was bound, but the matching compile and link-edit didn't run, or went to a different load library.
• The job runs a copy of the load module from another library in the STEPLIB or JOBLIB concatenation.
• A promotion copied the DBRM from one precompile and the load module from another.

How to find the problem

1. Note both tokens and the DBRM name in the message. The first token comes from the load module and the second from the bound DBRM.
2. Compare PCTIMESTAMP (precompile time) and BINDTIME for the package in SYSIBM.SYSPACKAGE with the load module's link-edit date.
3. Check the STEPLIB and JOBLIB order to see which copy of the module ran.
4. Check your change management records for the last precompile, compile and bind of the program.

How to fix it

• Precompile, compile, link-edit and bind together from the same source, then run again.
• If the load module is the right one, bind the DBRM from its precompile with BIND PACKAGE ... ACTION(REPLACE). A REBIND won't help, because it reuses the SQL already stored for the old package.
• If the package is the right one, link-edit or restore the matching load module.
• Fix the load library concatenation so test and production copies can't mix.
• Promote DBRMs and load modules as one unit through your change tool.

What it looks like

DSNT408I SQLCODE = -818, ERROR:  THE PRECOMPILER-GENERATED TIMESTAMP 18B2C4F00A1E3D27 IN THE
         LOAD MODULE IS DIFFERENT FROM THE BIND TIMESTAMP 18B2A9C5122F0B44 BUILT FROM THE
         DBRM INVCALC
DSNT418I SQLSTATE   = 51003 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.