We are on UDB ESE 8.1 FP6a on AIX 5.2L.
When I compile a C program and bind it first time, it works fine.

However if I recompile the program and then bind it again, I get timestamp -818 error on executing it. It seems DB2 does not pick up the updated library. Even if binary in sqllib/function is updated, DB2 does kepp using the old one previously loaded.


I found out that if I stop db2 and restart db2, then db2 picks up the recompiled version and everything is fine..

Is there anyway to refresh the cache without recycling DB2 ?

thanks

This problem occours because you have 2 applications using packages with the same name.

You should consider versioning the packages generated by the PRECOMPILE (PREP) statement.

I´d recommend you use the parameter PACKAGE, like this:

db2 PREP <application> BINDFILE PACKAGE USING <versioned_pkg_name>

You can also choose to rename the BINDFILE name generated by the precompile command. Although I´m not sure if this will solve this problem.

One question to more experienced users:

If I issue this precompile statement:

PREP <application> BINDFILE xpto.bnd

The bindfile name will be "xpto.bnd", instead of the "<application>.bnd", right?

If so.. does it change, also, the package name (in an implicit manner)?

fohana,
thanks for the response but that is not the problem in my case..

I found that solution is if this is a stored procedure , then you need to ensure KEEPFENCED is set to NO.. This is a dbm cfg parameter. KEEPFENCED is a parameter that will 'cache' stored procedure code, so that if you call a stored procedure, it will not create a brand new db2fmp process everytime... The db2fmp process is the process spawned by the db2agent that actually executes the user code.

KEEPFENCED YES is default, and is highly recommended in production, for performance reasons. However in development, it is recommended to set KEEPFENCED to NO, so that DB2 does not cache the procedures, and so when you make a change, and execute the new code DB2 will pick that new code up.

Stopping/Starting the instance is the only way to 'refresh' the cache when KEEPFENCED is set to YES.

I thought this parameter was related only to the fenced process. From what I got, if setting this parameter to YES, after completing the execution of a fenced routine, the fenced process will not be destroyed. Otherwise, the fenced process is destroyed.

I didn´t know if setting the dbm cfg to keep fenced process would cause the caching of the sp code.

Thank you too!

You can issue the SQL statement FLUSH PACKAGE CACHE DYNAMIC.