DB2INSTANCE Warning

Nick_6789 · Post by **Nick_6789** » Thu May 31, 2007 1:38 am

Hi guys,

I am encountering the below warning each time I load data into the db2 server:

FNC_STG_DATA1: The environment variable DB2INSTANCE is currently set to `db2inst1'
and is being changed to `db2inst2' as specified in the server option;
if this instance is a different version of DB2, the program may not succeed.

Can anyone explain how to rid this warning from the log?

As well as why this is occuring? I've read a similar thread and correct me if I'm wrong... this has something to do with my client instance name not matching that of the db2 server instance name? Still vague in understanding this.

Additional info would be, my ETL server is seperate from the DB2 server. Thus remote connection is needed.

Please advice. Thanks in advanced all!

ray.wurlod · Post by **ray.wurlod** » Thu May 31, 2007 7:15 pm

Either via the Server option in your DB2 stage, or via the APT_DBNAME environment variable, you've specified db2inst2.

my_stm · Post by **my_stm** » Thu May 31, 2007 8:32 pm

Hi Ray,

In my db2 stage I set the server as db2inst2 whereas my client instance name is db2inst1. I guess that's the cause.

But I was wondering how this works. Please correct if me if my understanding is wrong.

The client instance name is set as db2inst1 in my project (ETL Server) /home/db2inst1/sqllib/db2profile file.

My guess that it's because in the db2 remote server the instance name is set as db2inst2...? Does that hit the mark?

Does the solution encompass syncing the instance names between the 2 servers?

I've tried to contact my DBA... to no avail yet... prolly he would get back to me some time later.

Please advice if my understanding's correct?

PS. The APT_DBNAME in Administrator is set to blank... so I dun think it's to do with the warning I'm having... I think.

ray.wurlod · Post by **ray.wurlod** » Thu May 31, 2007 10:26 pm

Just look at the help in the client. What's supposed to happen is what you expected. That it's not is a worry.
A quick fix might be to include $DB2INSTANCE as a job parameter, with a default value of $UNSET so that, in the job, it is not set unless explicitly overridden. In this case the property in the stage must be the only available value.