By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,558 Members | 1,068 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,558 IT Pros & Developers. It's quick & easy.

Multiple Instances and their corresponding entries in the services file

P: n/a
I have approximately 5 instances on my test server that are identical
to my prod server. On the prod server, when I look at the services
file, there is a single entry per instance and everything seems to be
working fine. However, on the test server, after creating each
instance, there are 4 entries per instance. Is there a need for all 4
of these entries? When I add a new service for each instance like on
the prod server and then change the SVCENAME parm for each instance to
match the new service name, I have problems. I keep receiving an error
about the SQL6031N Error in the db2nodes.cfg file at line number "0".
Reason code "11". Any ideas as to why it works on my prod server but
not on my test server? Thanks in advance for any help. Also, here is
an example of the services entries for 1 of the instances on the test
server.

DB2_db2inst1 60000/tcp
DB2_db2inst1_1 60001/tcp
DB2_db2inst1_2 60002/tcp
DB2_db2inst1_END 60003/tcp

Apr 27 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Your error message is not surprising. Review the complete description of
the SVCENAME data base manager parameter. The port address specified is
"the first of two consecutive ports ...".

Use even numbered port addresses only; 60000, 60002, 60004, 60006.

Phil Sherman
Matt wrote:
I have approximately 5 instances on my test server that are identical
to my prod server. On the prod server, when I look at the services
file, there is a single entry per instance and everything seems to be
working fine. However, on the test server, after creating each
instance, there are 4 entries per instance. Is there a need for all 4
of these entries? When I add a new service for each instance like on
the prod server and then change the SVCENAME parm for each instance to
match the new service name, I have problems. I keep receiving an error
about the SQL6031N Error in the db2nodes.cfg file at line number "0".
Reason code "11". Any ideas as to why it works on my prod server but
not on my test server? Thanks in advance for any help. Also, here is
an example of the services entries for 1 of the instances on the test
server.

DB2_db2inst1 60000/tcp
DB2_db2inst1_1 60001/tcp
DB2_db2inst1_2 60002/tcp
DB2_db2inst1_END 60003/tcp

Apr 27 '06 #2

P: n/a
Thanks for the reply. I'm curious why it works on my prod server but
not on my test server. Does it make a difference if I have Workgroup
Edition on my prod server and EE on my test server? Also, I just
realized that both servers are not at the same fixpack. Could this be
the problem? Thanks.

Apr 27 '06 #3

P: n/a
In article <11**********************@j33g2000cwa.googlegroups .com>,
ma*******@gmail.com says...
I have approximately 5 instances on my test server that are identical
to my prod server. On the prod server, when I look at the services
file, there is a single entry per instance and everything seems to be
working fine. However, on the test server, after creating each
instance, there are 4 entries per instance. Is there a need for all 4
of these entries? When I add a new service for each instance like on
the prod server and then change the SVCENAME parm for each instance to
match the new service name, I have problems. I keep receiving an error
about the SQL6031N Error in the db2nodes.cfg file at line number "0".
Reason code "11". Any ideas as to why it works on my prod server but
not on my test server? Thanks in advance for any help. Also, here is
an example of the services entries for 1 of the instances on the test
server.

DB2_db2inst1 60000/tcp
DB2_db2inst1_1 60001/tcp
DB2_db2inst1_2 60002/tcp
DB2_db2inst1_END 60003/tcp


Those service entries should not be used as SVCENAME. They are used
internally by DB2. You should have other entries in the sevices file. In
my case it also contains the entry 'db2c_DB2 50000/tcp'.
Just add entries to the services file in the 500.. range and use those
names or portnumbers in the instance definitions.
Apr 27 '06 #4

P: n/a
OOPS - incomplete response

The error message states that the defined value in the DBM config does
not have a matching entry in the services file. The second port, one
number higher, is used for interrupt requests from down-level clients.

I'm guessing that your test system uses descriptive names for the port
addresses. Check the services file to verify that the matching names are
indeed in the file.

If the create instance procedure is generating services entries for four
ports for each instance, then I'd suspect that this is early preparation
for some possible future feature of UDB. Note that this is my personal
speculation.

If all the DBM SVCENAMEs match with the first entry in each set in the
services file, try using the actual port addresses in the DBM
configuration to see if this eliminates the error message. You could
also check to see if any fixpak(s) have fixes that resolve a SVCENAME
problem like yours.

Phil Sherman

Phil Sherman wrote:
Your error message is not surprising. Review the complete description of
the SVCENAME data base manager parameter. The port address specified is
"the first of two consecutive ports ...".

Use even numbered port addresses only; 60000, 60002, 60004, 60006.

Phil Sherman
Matt wrote:
I have approximately 5 instances on my test server that are identical
to my prod server. On the prod server, when I look at the services
file, there is a single entry per instance and everything seems to be
working fine. However, on the test server, after creating each
instance, there are 4 entries per instance. Is there a need for all 4
of these entries? When I add a new service for each instance like on
the prod server and then change the SVCENAME parm for each instance to
match the new service name, I have problems. I keep receiving an error
about the SQL6031N Error in the db2nodes.cfg file at line number "0".
Reason code "11". Any ideas as to why it works on my prod server but
not on my test server? Thanks in advance for any help. Also, here is
an example of the services entries for 1 of the instances on the test
server.

DB2_db2inst1 60000/tcp
DB2_db2inst1_1 60001/tcp
DB2_db2inst1_2 60002/tcp
DB2_db2inst1_END 60003/tcp

Apr 27 '06 #5

P: n/a
Matt wrote:
I have approximately 5 instances on my test server that are identical
to my prod server. On the prod server, when I look at the services
file, there is a single entry per instance and everything seems to be
working fine. However, on the test server, after creating each
instance, there are 4 entries per instance. Is there a need for all 4
of these entries? When I add a new service for each instance like on
the prod server and then change the SVCENAME parm for each instance to
match the new service name, I have problems. I keep receiving an error
about the SQL6031N Error in the db2nodes.cfg file at line number "0".
Reason code "11". Any ideas as to why it works on my prod server but
not on my test server? Thanks in advance for any help. Also, here is
an example of the services entries for 1 of the instances on the test
server.

DB2_db2inst1 60000/tcp
DB2_db2inst1_1 60001/tcp
DB2_db2inst1_2 60002/tcp
DB2_db2inst1_END 60003/tcp


Is your test server set up identical to your production server? The reason
why I ask is that these extra service entries should only show up on DB2
UDB ESE, and not on any other product. So if you have ESE on your test
server, but WSE on your production server, for example, that would explain
this difference.

With non-ESE servers, you get one service entry: the connection port. This
entry is usually something like "db2c_<instancename>" unless you opted for
a different name during instance creation (usually in the GUI or response
file). This name goes in your SVCENAME parameter. Again, this should
largely be automatic. (Using db2icrt directly, however, may not create
this, so then it's manual.)

With ESE servers, you get the above connection port PLUS you get
FCM/INTRA-PARALLEL ports. These are *always* of the format
"DB2_<instancename>". The ones with _1, _2, and _END in your example
aren't needed by DB2 explicitly - they are derived internally by just
adding the node number to the port number. They are placed in your
services file mostly to prevent other applications from trying to use them.

These ports are only needed if you're using multiple nodes (whether logical
or physical) in a DPF environment *or* you have intra-parallel turned on,
as I recall. However, even if you're not using either of these yet, DB2
creates them during instance creation (unless they alread exist) to reserve
the ports for when you do need to scale to use these features.

Since these ports have a predefined name, not only can you not change the
names (you can change the numbers, however, as long as they remain
consecutive and not used by any other application on the machine, as well
among the entire cluster if using DPF), you need not configure DB2 in any
way to tell DB2 what the names are. So do not set the SVCENAME to these
values. Leave SVCENAME referencing the connection port from your services
file.

Hope that helps,
Apr 27 '06 #6

P: n/a
Thank you all for your help. The problem seems to be that we have WSE
on the prod server and EE on the test server.

Apr 27 '06 #7

P: n/a
Ian
Darin McBride wrote:

With ESE servers, you get the above connection port PLUS you get
FCM/INTRA-PARALLEL ports. These are *always* of the format
"DB2_<instancename>". The ones with _1, _2, and _END in your example
aren't needed by DB2 explicitly - they are derived internally by just
adding the node number to the port number. They are placed in your
services file mostly to prevent other applications from trying to use them.

Two minor corrections:

These ports are necessary for ESE only, not when you have INTRA_PARALLEL
enabled (otherwise you couldn't use INTRA_PARALLEL with anything other
than ESE!

Also, the DB2_<instancename> and DB2_<instancename>_END ports are both
required, but the _1, _2, etc are not.
Apr 30 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.