I assume that you use embedded SQL and not something like CLI/ODBC? You precompile the C source code, correct?
What happens in such a case is the following: The DB2 precompiler extracts all SQL statements and replaces them with regular C function calls into libdb2. The SQL statements are bundled into a bind file. In order to use those SQL statements, you must bind the bind file to a database, which creates a package. Naturally, DB2 must ensure that the package in the database matches the (compiled) C code. If it doesn't, you would run into problems because, for example, you connect to the wrong database, DB2 wouldn't return all columns in a query that the program expects, you would use completely wrong queries and tables, etc. In order to ensure the consistency between the precompiled C code and the package, DB2 uses timestamps that are generated at precompilation time and stored in the bind file (package) as well as the precompiled code. (You can actually use your own consistency tokens using the LEVEL option for the DB2 precompiler.)
Now, when you work with the database against which the precompile was run, things just work because DB2 already created the package as part of the precompilation. With another database, you don't have the package (or in the wrong version) in the database and you will the mentioned error. What you have to do there is to bind the bind file (option BINDFILE for the DB2 precompiler to generate this file) to each database against which your application should run. Note that I'm talking about "databases" here and not "local box"/"remote box" because local/remote has nothing to do with this.
IBM DB2 Analytics Accelerator
IBM Germany Research & Development