-818 SQLCODE error

kranthikumarb · Posted: Fri May 15, 2009 11:17 am

Hi,

I have a DB2 cobol program.

The general program preparation process is

1) Precompilation
2) Bind
3) Compile
4) link edit
5) Run

After link edit and before run, I am doing a bind to a plan. using the option in
12. DB2I PRIMARY OPTION MENU -> 5. BIND/REBIND/FREE -> 1. BIND
PLAN

Here I am specifying the plan name and DBRM library and DBRM member which i want to bind.

Now I have two scenarios.

Scenario1:

I have changed something in an SQL statement and compiled the program. Now it generates a new DBRM and places a new time stamp in the the DBRM and same timestamp in the load module. So when i bind the program before i run it, using 12->5->1 the plan will b replaced with latest timestamp in the DBRM. No issues with that and i dont get a -818

Scenario 2:

I have changed something in my cobol code (not in SQLs). I have compiled it. a new DBRM gets generated with latest time stamp and the same time stamp is placed in load module also. But this time i am not interested to bind the DBRM to a plan. But still the program is running fine. Why is it not throwing a -818 as it compares the time stamp present in the load and plan?

Please correct me if I am wrong some where.
I checked all the posts related to -818. But no clue for my question.

Thanks

dbzTHEdinosauer · Posted: Fri May 15, 2009 2:41 pm

You should start looking at the manuals for sql errorcodes.
As you read the description (below), you will see where you went wrong.

-818
Reason: THE PRECOMPILER GENERATED TIMESTAMP x IN THE LOAD MODULE IS DIFFERENT FROM THE BIND TIMESTAMP y BUILT FROM THE DBRM z

Description: The SQL precompiler places timestamp 'y' in the DBRM, and time stamp 'x' in the parameter list in the application program for each SQL statement. At BIND time, DB2 stores the DBRM timestamp for run time use. At run time, timestamp 'x', for the SQL statement being processed,is compared with timestamp 'y' derived from the DBRM 'z' at BIND time. If the two timestamps do not match, the DBRM and the application program were not the result of the same precompile. This problem can occur if you:

Precompile, compile, and link, without doing a BIND of the application,
Precompile and BIND, without doing the compile and link for the application program, or
BIND the application using a DBRM that resulted from a different precompile of the application program than that which produced the object module that is linked into the application module.

The timestamps 'x' and 'y' are DB2 internal timestamps. They do not have an external interpretation.

User Response: BIND the application again, using the DBRM for the application program that matches the object module.

kranthikumarb · Posted: Fri May 15, 2009 4:33 pm

Raghu navaikulam · Posted: Sun May 17, 2009 12:07 am

Hi kranthikumarb

kranthikumarb · Posted: Mon May 18, 2009 2:53 pm

Hi Raghu,

I've a macro using which we compile a program. It automatically does the precompile,compile and link edit.
I am not doing all these steps manually.

I could see the precompile step in the sd;st screen.That means the DBRM was generated.

vinit_infy · New User Joined: 07 Apr 2005 Posts: 56

Hi kranthikumarb,

Check your cobol changes. Might be after cobol changes you are not executing the SQL statements. Until you are not executing the SQL ststements , you wont get -818.

dick scherrer · Posted: Tue May 19, 2009 7:48 pm

Hello,

That is rather confusing. . .

Some clarification is needed or this should be deleted. . .

vinit_infy · New User Joined: 07 Apr 2005 Posts: 56

Dick,

What i mean to say is, since before kranthikumarb's cobol changes program was running fine after package bind.

But when he did some cobol changes he didn't run the bind and even then he is not getting -818. Whenever we compile a cobol-db2 program, everytime timestamps changes and so we need BIND. But if the control is not going to any EXEC SQL statement then, it wont check the timestamps and wont fail with -818.

So, may be kranthikumarb's new cobol changes are bypassing the EXEC SQL statemements / not executing the sql statements.