ER problem / bug? in 11.50.UC3

Hi, We are looking at 11.50.UC3 for an upgrade to ER and came across a funny bit. First - both servers are RHEL4 running 11.50.UC3. One is called sirrp61 and the other Stan2 - note the capital letter in the start of the name. ER is established between the pair fine and replicates created. When I go to sync a replicate it fails with the below - and it has used a lower case version of the group number g_stan2 in the attempt to connect message. Now I know it isn't a good idea to let capital letters and Linux mix, but worth noting. Can you let me know if I am missing something here? otherwise I will look to raise a PMR as a bug. Thank Jarrod Teale Fonterra NZ [informix@Stan2 ~]$ cdr list server SERVER ID STATE STATUS QUEUE CONNECTION CHANGED ----------------------------------------------------------------------- g_Stan2 100 Active Local 0 g_sirrp61 101 Active Connected 0 Feb 20 13:27:53 [informix@Stan2 ~]$ cdr sync repl -m g_sirrp61 -r sirrp61_stan2_tag_defn g_Stan2 Creating Shadow Repl sync_5590_6553602_1235090243 Starting synchronization scan for replicate sirrp61_stan2_tag_defn Error returned from getReplColumns: prepare recheck_3 from select def_id as def_id from stan2@g_Stan2:"sdev".tag_defn where def_id = ? SQLCODE -908 ISAM 0 Error Details: 908: Attempt to connect to database server (g_stan2, conerr=-25555, oserr=0) failed. Current Connection:conn5, Database:stan2@g_Stan2 connect to Stan2 failed unable to connect to server specified (5) command failed -- unable to connect to server specified (5) Error Details: Could not connect to the specified server or database. Perform the following actions and then run the above repair command again: 1. Correct any misspelled server group names in the command. 2. Correct any misspelled or incorrectly formatted sqlhosts entries corresponding to the server groups specified in the command. 3. Ensure that all servers specified in the command are online. 4. If the error indicates a problem with the syscdr database, then ensure that ER is running on all the servers specified in the command. 5. Ensure that the user who is running the command has CONNECT permission to the specified database. DISCLAIMER: This email contains confidential information and may be legally privileged. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. You may not use, disclose or copy this email or its attachments in any way. Any opinions expressed in this email are those of the author and are not necessarily those of the Fonterra Co-operative Group. http://www.fonterra.com/

Jarrod Teale wrote: > Hi, > We are looking at 11.50.UC3 for an upgrade to ER and came across a funny > bit. > First - both servers are RHEL4 running 11.50.UC3. > > One is called sirrp61 and the other Stan2 - note the capital letter in > the start of the name. > > ER is established between the pair fine and replicates created. > > When I go to sync a replicate it fails with the below - and it has used > a lower case version of the group number g_stan2 in the attempt to > connect message. > Now I know it isn't a good idea to let capital letters and Linux mix, > but worth noting. What is in the sqlhosts file? The output of list server is from the syscdr database. Do the names match? > > Can you let me know if I am missing something here? otherwise I will > look to raise a PMR as a bug. > > Thank > Jarrod Teale > Fonterra NZ > > [informix@Stan2 ~]$ cdr list server > SERVER ID STATE STATUS QUEUE CONNECTION CHANGED > ----------------------------------------------------------------------- > g_Stan2 100 Active Local 0 > g_sirrp61 101 Active Connected 0 Feb 20 13:27:53 > [informix@Stan2 ~]$ cdr sync repl -m g_sirrp61 -r sirrp61_stan2_tag_defn > g_Stan2 Creating Shadow Repl sync_5590_6553602_1235090243 Starting > synchronization scan for replicate > sirrp61_stan2_tag_defn > Error returned from getReplColumns: prepare recheck_3 from select def_id > as def_id from stan2@g_Stan2:"sdev".tag_defn where def_id = ? > SQLCODE -908 ISAM 0 > > Error Details: > 908: Attempt to connect to database server (g_stan2, > conerr=-25555, oserr=0) failed.> > Current Connection:conn5, Database:stan2@g_Stan2 connect to > Stan2 failed unable to connect to server specified (5) command failed > -- unable to connect to server specified (5) Error Details: > Could not connect to the specified server or database. > Perform the following actions and then run the above repair command > again: > 1. Correct any misspelled server group names in the command. > 2. Correct any misspelled or incorrectly formatted sqlhosts > entries > corresponding to the server groups specified in the command. > 3. Ensure that all servers specified in the command are online. > 4. If the error indicates a problem with the syscdr database, > then ensure > that ER is running on all the servers specified in the > command. > 5. Ensure that the user who is running the command has CONNECT > permission > to the specified database. > > > DISCLAIMER: > This email contains confidential information and may be legally privileged. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. > You may not use, disclose or copy this email or its attachments in any way. > Any opinions expressed in this email are those of the author and are not necessarily those of the Fonterra Co-operative Group. > http://www.fonterra.com/ >

Jarrod Teale wrote: > Hi, > We are looking at 11.50.UC3 for an upgrade to ER and came across a funny > bit. > First - both servers are RHEL4 running 11.50.UC3. > > One is called sirrp61 and the other Stan2 - note the capital letter in > the start of the name. > > ER is established between the pair fine and replicates created. > > When I go to sync a replicate it fails with the below - and it has used > a lower case version of the group number g_stan2 in the attempt to > connect message. > Now I know it isn't a good idea to let capital letters and Linux mix, > but worth noting. > > Can you let me know if I am missing something here? otherwise I will > look to raise a PMR as a bug. > > Thank > Jarrod Teale > Fonterra NZ > > [informix@Stan2 ~]$ cdr list server > SERVER ID STATE STATUS QUEUE CONNECTION CHANGED > ----------------------------------------------------------------------- > g_Stan2 100 Active Local 0 > g_sirrp61 101 Active Connected 0 Feb 20 13:27:53 > [informix@Stan2 ~]$ cdr sync repl -m g_sirrp61 -r sirrp61_stan2_tag_defn > g_Stan2 Creating Shadow Repl sync_5590_6553602_1235090243 Starting > synchronization scan for replicate > sirrp61_stan2_tag_defn > Error returned from getReplColumns: prepare recheck_3 from select def_id > as def_id from stan2@g_Stan2:"sdev".tag_defn where def_id = ? > SQLCODE -908 ISAM 0 > > Error Details: > 908: Attempt to connect to database server (g_stan2, > conerr=-25555, oserr=0) failed.> > Current Connection:conn5, Database:stan2@g_Stan2 connect to > Stan2 failed unable to connect to server specified (5) command failed > -- unable to connect to server specified (5) Error Details: > Could not connect to the specified server or database. > Perform the following actions and then run the above repair command > again: > 1. Correct any misspelled server group names in the command. > 2. Correct any misspelled or incorrectly formatted sqlhosts > entries > corresponding to the server groups specified in the command. > 3. Ensure that all servers specified in the command are online. > 4. If the error indicates a problem with the syscdr database, > then ensure > that ER is running on all the servers specified in the > command. > 5. Ensure that the user who is running the command has CONNECT > permission > to the specified database. > > > DISCLAIMER: > This email contains confidential information and may be legally privileged. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. > You may not use, disclose or copy this email or its attachments in any way. > Any opinions expressed in this email are those of the author and are not necessarily those of the Fonterra Co-operative Group. > http://www.fonterra.com/ > The fine manual specifically states that we must use lower case letters for the server names... I know... Many of us have used a mixed case and it works most of the times... But you may see tech support raise some doubts about this... Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

The SQLHosts file has the uppercase entry in it for both the instance name and the group name (g_Stan2 and server is Stan2). There is no lower case name anywhere. As I said, I know it isn't good practice - just wondering if I should raise it with support? Jarrod Teale Fonterra NZ -----Original Message----- From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] On Behalf Of Madison Pruet Sent: Monday, 23 February 2009 9:02 a.m. To: informix-list@iiug.org Subject: Re: ER problem / bug? in 11.50.UC3 Jarrod Teale wrote: > Hi, > We are looking at 11.50.UC3 for an upgrade to ER and came across a > funny bit. > First - both servers are RHEL4 running 11.50.UC3. > > One is called sirrp61 and the other Stan2 - note the capital letter in > the start of the name. > > ER is established between the pair fine and replicates created. > > When I go to sync a replicate it fails with the below - and it has > used a lower case version of the group number g_stan2 in the attempt > to connect message. > Now I know it isn't a good idea to let capital letters and Linux mix, > but worth noting. What is in the sqlhosts file? The output of list server is from the syscdr database. Do the names match? > > Can you let me know if I am missing something here? otherwise I will > look to raise a PMR as a bug. > > Thank > Jarrod Teale > Fonterra NZ > > [informix@Stan2 ~]$ cdr list server > SERVER ID STATE STATUS QUEUE CONNECTION CHANGED > ----------------------------------------------------------------------- > g_Stan2 100 Active Local 0 > g_sirrp61 101 Active Connected 0 Feb 20 13:27:53 > [informix@Stan2 ~]$ cdr sync repl -m g_sirrp61 -r > sirrp61_stan2_tag_defn > g_Stan2 Creating Shadow Repl sync_5590_6553602_1235090243 Starting > synchronization scan for replicate > sirrp61_stan2_tag_defn > Error returned from getReplColumns: prepare recheck_3 from select def_id > as def_id from stan2@g_Stan2:"sdev".tag_defn where def_id = ? > SQLCODE -908 ISAM 0 > > Error Details: > 908: Attempt to connect to database server (g_stan2, > conerr=-25555, oserr=0) failed.> > Current Connection:conn5, Database:stan2@g_Stan2 connect to > Stan2 failed unable to connect to server specified (5) command failed > -- unable to connect to server specified (5) Error Details: > Could not connect to the specified server or database. > Perform the following actions and then run the above repair command > again: > 1. Correct any misspelled server group names in the command. > 2. Correct any misspelled or incorrectly formatted sqlhosts > entries > corresponding to the server groups specified in the command. > 3. Ensure that all servers specified in the command are online. > 4. If the error indicates a problem with the syscdr database, > then ensure > that ER is running on all the servers specified in the > command. > 5. Ensure that the user who is running the command has CONNECT > permission > to the specified database. > > > DISCLAIMER: > This email contains confidential information and may be legally privileged. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. > You may not use, disclose or copy this email or its attachments in any way. > Any opinions expressed in this email are those of the author and are not necessarily those of the Fonterra Co-operative Group. > http://www.fonterra.com/ > _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list DISCLAIMER: This email contains confidential information and may be legally privileged. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. You may not use, disclose or copy this email or its attachments in any way. Any opinions expressed in this email are those of the author and are not necessarily those of the Fonterra Co-operative Group. http://www.fonterra.com/

Jarrod Teale wrote: > The SQLHosts file has the uppercase entry in it for both the instance > name and the group name (g_Stan2 and server is Stan2). > There is no lower case name anywhere. > As I said, I know it isn't good practice - just wondering if I should > raise it with support? Yes, but the bug is not what you think. The documentation states that the DBSERVER field in the sqlhosts is not supposed to contain upper case letters. (page 3-17) So the real issue is that the cdr utility didn't catch that you used an uppercase letter when defining the server. If this is a test system, then you'll need to rebuild with the correction to the group name. If this is a production system, then you will need to open a case with tech support and have them contact me. I guess you can contact me directly, but we still need a tech support case to open the bug. > > Jarrod Teale > Fonterra NZ > -----Original Message----- > From: informix-list-bounces@iiug.org > [mailto:informix-list-bounces@iiug.org] On Behalf Of Madison Pruet > Sent: Monday, 23 February 2009 9:02 a.m. > To: informix-list@iiug.org > Subject: Re: ER problem / bug? in 11.50.UC3 > > Jarrod Teale wrote: >> Hi, >> We are looking at 11.50.UC3 for an upgrade to ER and came across a >> funny bit. >> First - both servers are RHEL4 running 11.50.UC3. >> >> One is called sirrp61 and the other Stan2 - note the capital letter in > >> the start of the name. >> >> ER is established between the pair fine and replicates created. >> >> When I go to sync a replicate it fails with the below - and it has >> used a lower case version of the group number g_stan2 in the attempt >> to connect message. >> Now I know it isn't a good idea to let capital letters and Linux mix, >> but worth noting. > > What is in the sqlhosts file? The output of list server is from the > syscdr database. Do the names match? > >> >> Can you let me know if I am missing something here? otherwise I will >> look to raise a PMR as a bug. >> >> Thank >> Jarrod Teale >> Fonterra NZ >> >> [informix@Stan2 ~]$ cdr list server >> SERVER ID STATE STATUS QUEUE CONNECTION > CHANGED > ----------------------------------------------------------------------- >> g_Stan2 100 Active Local 0 >> g_sirrp61 101 Active Connected 0 Feb 20 13:27:53 >> [informix@Stan2 ~]$ cdr sync repl -m g_sirrp61 -r >> sirrp61_stan2_tag_defn >> g_Stan2 Creating Shadow Repl sync_5590_6553602_1235090243 Starting >> synchronization scan for replicate >> sirrp61_stan2_tag_defn >> Error returned from getReplColumns: prepare recheck_3 from select > def_id >> as def_id from stan2@g_Stan2:"sdev".tag_defn where def_id = ? >> SQLCODE -908 ISAM 0 >> >> Error Details: >> 908: Attempt to connect to database server (g_stan2, >> conerr=-25555, oserr=0) failed.>> >> Current Connection:conn5, Database:stan2@g_Stan2 connect to >> Stan2 failed unable to connect to server specified (5) command failed >> -- unable to connect to server specified (5) Error Details: >> Could not connect to the specified server or database. >> Perform the following actions and then run the above repair command >> again: >> 1. Correct any misspelled server group names in the command. >> 2. Correct any misspelled or incorrectly formatted sqlhosts >> entries >> corresponding to the server groups specified in the > command. >> 3. Ensure that all servers specified in the command are > online. >> 4. If the error indicates a problem with the syscdr database, >> then ensure >> that ER is running on all the servers specified in the >> command. >> 5. Ensure that the user who is running the command has CONNECT > >> permission >> to the specified database. >> >> >> DISCLAIMER: >> This email contains confidential information and may be legally > privileged. If you are not the intended recipient or have received this > email in error, please notify the sender immediately and destroy this > email. >> You may not use, disclose or copy this email or its attachments in any > way. >> Any opinions expressed in this email are those of the author and are > not necessarily those of the Fonterra Co-operative Group. >> http://www.fonterra.com/ >> > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > > > DISCLAIMER: > This email contains confidential information and may be legally privileged. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. > You may not use, disclose or copy this email or its attachments in any way. > Any opinions expressed in this email are those of the author and are not necessarily those of the Fonterra Co-operative Group. > http://www.fonterra.com/ >

Madison, It's a test system - we will rebuild. Thanks Jarrod -----Original Message----- From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] On Behalf Of Madison Pruet Sent: Monday, 23 February 2009 1:52 p.m. To: informix-list@iiug.org Subject: Re: ER problem / bug? in 11.50.UC3 Jarrod Teale wrote: > The SQLHosts file has the uppercase entry in it for both the instance > name and the group name (g_Stan2 and server is Stan2). > There is no lower case name anywhere. > As I said, I know it isn't good practice - just wondering if I should > raise it with support? Yes, but the bug is not what you think. The documentation states that the DBSERVER field in the sqlhosts is not supposed to contain upper case letters. (page 3-17) So the real issue is that the cdr utility didn't catch that you used an uppercase letter when defining the server. If this is a test system, then you'll need to rebuild with the correction to the group name. If this is a production system, then you will need to open a case with tech support and have them contact me. I guess you can contact me directly, but we still need a tech support case to open the bug. > > Jarrod Teale > Fonterra NZ > -----Original Message----- > From: informix-list-bounces@iiug.org > [mailto:informix-list-bounces@iiug.org] On Behalf Of Madison Pruet > Sent: Monday, 23 February 2009 9:02 a.m. > To: informix-list@iiug.org > Subject: Re: ER problem / bug? in 11.50.UC3 > > Jarrod Teale wrote: >> Hi, >> We are looking at 11.50.UC3 for an upgrade to ER and came across a >> funny bit. >> First - both servers are RHEL4 running 11.50.UC3. >> >> One is called sirrp61 and the other Stan2 - note the capital letter in > >> the start of the name. >> >> ER is established between the pair fine and replicates created. >> >> When I go to sync a replicate it fails with the below - and it has >> used a lower case version of the group number g_stan2 in the attempt >> to connect message. >> Now I know it isn't a good idea to let capital letters and Linux mix, >> but worth noting. > > What is in the sqlhosts file? The output of list server is from the > syscdr database. Do the names match? > >> >> Can you let me know if I am missing something here? otherwise I will >> look to raise a PMR as a bug. >> >> Thank >> Jarrod Teale >> Fonterra NZ >> >> [informix@Stan2 ~]$ cdr list server >> SERVER ID STATE STATUS QUEUE CONNECTION > CHANGED > ----------------------------------------------------------------------- >> g_Stan2 100 Active Local 0 >> g_sirrp61 101 Active Connected 0 Feb 20 13:27:53 >> [informix@Stan2 ~]$ cdr sync repl -m g_sirrp61 -r >> sirrp61_stan2_tag_defn >> g_Stan2 Creating Shadow Repl sync_5590_6553602_1235090243 Starting >> synchronization scan for replicate >> sirrp61_stan2_tag_defn >> Error returned from getReplColumns: prepare recheck_3 from select > def_id >> as def_id from stan2@g_Stan2:"sdev".tag_defn where def_id = ? >> SQLCODE -908 ISAM 0 >> >> Error Details: >> 908: Attempt to connect to database server (g_stan2, >> conerr=-25555, oserr=0) failed.>> >> Current Connection:conn5, Database:stan2@g_Stan2 connect to >> Stan2 failed unable to connect to server specified (5) command failed >> -- unable to connect to server specified (5) Error Details: >> Could not connect to the specified server or database. >> Perform the following actions and then run the above repair command >> again: >> 1. Correct any misspelled server group names in the command. >> 2. Correct any misspelled or incorrectly formatted sqlhosts >> entries >> corresponding to the server groups specified in the > command. >> 3. Ensure that all servers specified in the command are > online. >> 4. If the error indicates a problem with the syscdr database, >> then ensure >> that ER is running on all the servers specified in the >> command. >> 5. Ensure that the user who is running the command has CONNECT > >> permission >> to the specified database. >> >> >> DISCLAIMER: >> This email contains confidential information and may be legally > privileged. If you are not the intended recipient or have received this > email in error, please notify the sender immediately and destroy this > email. >> You may not use, disclose or copy this email or its attachments in any > way. >> Any opinions expressed in this email are those of the author and are > not necessarily those of the Fonterra Co-operative Group. >> http://www.fonterra.com/ >> > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > > > DISCLAIMER: > This email contains confidential information and may be legally privileged. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. > You may not use, disclose or copy this email or its attachments in any way. > Any opinions expressed in this email are those of the author and are not necessarily those of the Fonterra Co-operative Group. > http://www.fonterra.com/ > _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list DISCLAIMER: This email contains confidential information and may be legally privileged. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. You may not use, disclose or copy this email or its attachments in any way. Any opinions expressed in this email are those of the author and are not necessarily those of the Fonterra Co-operative Group. http://www.fonterra.com/

Jarrod Teale wrote: > Madison, > It's a test system - we will rebuild. Thanks > Jarrod OK - I've opened a bug for this problem - 172306. There's no need to open a case for this. I've tested a patch and we'll be including in the build after tomorrow's code review. > > -----Original Message----- > From: informix-list-bounces@iiug.org > [mailto:informix-list-bounces@iiug.org] On Behalf Of Madison Pruet > Sent: Monday, 23 February 2009 1:52 p.m. > To: informix-list@iiug.org > Subject: Re: ER problem / bug? in 11.50.UC3 > > Jarrod Teale wrote: >> The SQLHosts file has the uppercase entry in it for both the instance >> name and the group name (g_Stan2 and server is Stan2). >> There is no lower case name anywhere. >> As I said, I know it isn't good practice - just wondering if I should >> raise it with support? > > Yes, but the bug is not what you think. The documentation states that > the DBSERVER field in the sqlhosts is not supposed to contain upper case > letters. (page 3-17) So the real issue is that the cdr utility didn't > catch that you used an uppercase letter when defining the server. > > If this is a test system, then you'll need to rebuild with the > correction to the group name. If this is a production system, then you > > will need to open a case with tech support and have them contact me. > I guess you can contact me directly, but we still need a tech support > case to open the bug. > > > > >> Jarrod Teale >> Fonterra NZ >> -----Original Message----- >> From: informix-list-bounces@iiug.org >> [mailto:informix-list-bounces@iiug.org] On Behalf Of Madison Pruet >> Sent: Monday, 23 February 2009 9:02 a.m. >> To: informix-list@iiug.org >> Subject: Re: ER problem / bug? in 11.50.UC3 >> >> Jarrod Teale wrote: >>> Hi, >>> We are looking at 11.50.UC3 for an upgrade to ER and came across a >>> funny bit. >>> First - both servers are RHEL4 running 11.50.UC3. >>> >>> One is called sirrp61 and the other Stan2 - note the capital letter > in >>> the start of the name. >>> >>> ER is established between the pair fine and replicates created. >>> >>> When I go to sync a replicate it fails with the below - and it has >>> used a lower case version of the group number g_stan2 in the attempt >>> to connect message. >>> Now I know it isn't a good idea to let capital letters and Linux mix, > >>> but worth noting. >> What is in the sqlhosts file? The output of list server is from the >> syscdr database. Do the names match? >> >>> >>> Can you let me know if I am missing something here? otherwise I will >>> look to raise a PMR as a bug. >>> >>> Thank >>> Jarrod Teale >>> Fonterra NZ >>> >>> [informix@Stan2 ~]$ cdr list server >>> SERVER ID STATE STATUS QUEUE CONNECTION >> CHANGED >> > ----------------------------------------------------------------------- >>> g_Stan2 100 Active Local 0 >>> g_sirrp61 101 Active Connected 0 Feb 20 13:27:53 >>> [informix@Stan2 ~]$ cdr sync repl -m g_sirrp61 -r >>> sirrp61_stan2_tag_defn >>> g_Stan2 Creating Shadow Repl sync_5590_6553602_1235090243 Starting >>> synchronization scan for replicate >>> sirrp61_stan2_tag_defn >>> Error returned from getReplColumns: prepare recheck_3 from select >> def_id >>> as def_id from stan2@g_Stan2:"sdev".tag_defn where def_id = ? >>> SQLCODE -908 ISAM 0 >>> >>> Error Details: >>> 908: Attempt to connect to database server (g_stan2, >>> conerr=-25555, oserr=0) failed.>>> >>> Current Connection:conn5, Database:stan2@g_Stan2 connect to >>> Stan2 failed unable to connect to server specified (5) command > failed >>> -- unable to connect to server specified (5) Error Details: >>> Could not connect to the specified server or database. >>> Perform the following actions and then run the above repair command >>> again: >>> 1. Correct any misspelled server group names in the command. >>> 2. Correct any misspelled or incorrectly formatted sqlhosts >>> entries >>> corresponding to the server groups specified in the >> command. >>> 3. Ensure that all servers specified in the command are >> online. >>> 4. If the error indicates a problem with the syscdr database, > >>> then ensure >>> that ER is running on all the servers specified in the >>> command. >>> 5. Ensure that the user who is running the command has > CONNECT >>> permission >>> to the specified database. >>> >>> >>> DISCLAIMER: >>> This email contains confidential information and may be legally >> privileged. If you are not the intended recipient or have received > this >> email in error, please notify the sender immediately and destroy this >> email. >>> You may not use, disclose or copy this email or its attachments in > any >> way. >>> Any opinions expressed in this email are those of the author and are >> not necessarily those of the Fonterra Co-operative Group. >>> http://www.fonterra.com/ >>> >> _______________________________________________ >> Informix-list mailing list >> Informix-list@iiug.org >> http://www.iiug.org/mailman/listinfo/informix-list >> >> >> DISCLAIMER: >> This email contains confidential information and may be legally > privileged. If you are not the intended recipient or have received this > email in error, please notify the sender immediately and destroy this > email. >> You may not use, disclose or copy this email or its attachments in any > way. >> Any opinions expressed in this email are those of the author and are > not necessarily those of the Fonterra Co-operative Group. >> http://www.fonterra.com/ >> > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > > > DISCLAIMER: > This email contains confidential information and may be legally privileged. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. > You may not use, disclose or copy this email or its attachments in any way. > Any opinions expressed in this email are those of the author and are not necessarily those of the Fonterra Co-operative Group. > http://www.fonterra.com/ >

Madison Pruet wrote: > Jarrod Teale wrote: >> Madison, >> It's a test system - we will rebuild. Thanks >> Jarrod > > OK - I've opened a bug for this problem - 172306. There's no need to > open a case for this. I've tested a patch and we'll be including in the > build after tomorrow's code review. I got an email about this statement. There was a bit of concern that the code would go into the product with no QA. I thought that would be a chance to describe what the integration process is for ER (and MACH11/CDC). 1) The engineer develops a patch and performs unit testing to verify that the patch is working. 2) We have a daily code review which is attended by the members of the HA team. In the code review each of the engineers is allowed to raise any issues that they want. Depending on what the patch is, we may require that additional testing is performed. 3) After the code review, the patch is merged into a staging branch used by ER/MACH11). The staging branch is built nightly and goes through some 10 hours of automated testing daily. There is a daily reverse merge from the main release branch to the staging branch so that all patches from other teams are merged into the staging branch. 4) After the code has been in the staging branch for several days, it is merged into the main release branch where it goes through a different set of testing. Since the patch is also contained in the staging branch, that means that the patch is still going through our testing. 5) Only after the patch has received extensive testing in the main release branch is it released to the customer in the form of a pid drop. > >> >> -----Original Message----- >> From: informix-list-bounces@iiug.org >> [mailto:informix-list-bounces@iiug.org] On Behalf Of Madison Pruet >> Sent: Monday, 23 February 2009 1:52 p.m. >> To: informix-list@iiug.org >> Subject: Re: ER problem / bug? in 11.50.UC3 >> >> Jarrod Teale wrote: >>> The SQLHosts file has the uppercase entry in it for both the instance >>> name and the group name (g_Stan2 and server is Stan2). >>> There is no lower case name anywhere. >>> As I said, I know it isn't good practice - just wondering if I should >>> raise it with support? >> >> Yes, but the bug is not what you think. The documentation states that >> the DBSERVER field in the sqlhosts is not supposed to contain upper case >> letters. (page 3-17) So the real issue is that the cdr utility didn't >> catch that you used an uppercase letter when defining the server. >> >> If this is a test system, then you'll need to rebuild with the >> correction to the group name. If this is a production system, then you >> >> will need to open a case with tech support and have them contact me. >> I guess you can contact me directly, but we still need a tech support >> case to open the bug. >> >> >> >> >>> Jarrod Teale >>> Fonterra NZ >>> -----Original Message----- >>> From: informix-list-bounces@iiug.org >>> [mailto:informix-list-bounces@iiug.org] On Behalf Of Madison Pruet >>> Sent: Monday, 23 February 2009 9:02 a.m. >>> To: informix-list@iiug.org >>> Subject: Re: ER problem / bug? in 11.50.UC3 >>> >>> Jarrod Teale wrote: >>>> Hi, >>>> We are looking at 11.50.UC3 for an upgrade to ER and came across a >>>> funny bit. >>>> First - both servers are RHEL4 running 11.50.UC3. >>>> >>>> One is called sirrp61 and the other Stan2 - note the capital letter >> in >>>> the start of the name. >>>> >>>> ER is established between the pair fine and replicates created. >>>> When I go to sync a replicate it fails with the below - and it has >>>> used a lower case version of the group number g_stan2 in the attempt >>>> to connect message. >>>> Now I know it isn't a good idea to let capital letters and Linux mix, >> >>>> but worth noting. >>> What is in the sqlhosts file? The output of list server is from the >>> syscdr database. Do the names match? >>> >>>> >>>> Can you let me know if I am missing something here? otherwise I will >>>> look to raise a PMR as a bug. >>>> >>>> Thank >>>> Jarrod Teale >>>> Fonterra NZ >>>> >>>> [informix@Stan2 ~]$ cdr list server >>>> SERVER ID STATE STATUS QUEUE CONNECTION >>> CHANGED >>> >> ----------------------------------------------------------------------- >>>> g_Stan2 100 Active Local 0 >>>> g_sirrp61 101 Active Connected 0 Feb 20 13:27:53 >>>> [informix@Stan2 ~]$ cdr sync repl -m g_sirrp61 -r >>>> sirrp61_stan2_tag_defn >>>> g_Stan2 Creating Shadow Repl sync_5590_6553602_1235090243 Starting >>>> synchronization scan for replicate >>>> sirrp61_stan2_tag_defn >>>> Error returned from getReplColumns: prepare recheck_3 from select >>> def_id >>>> as def_id from stan2@g_Stan2:"sdev".tag_defn where def_id = ? >>>> SQLCODE -908 ISAM 0 >>>> >>>> Error Details: >>>> 908: Attempt to connect to database server (g_stan2, >>>> conerr=-25555, oserr=0) failed.>>>> >>>> Current Connection:conn5, Database:stan2@g_Stan2 connect to >>>> Stan2 failed unable to connect to server specified (5) command >> failed >>>> -- unable to connect to server specified (5) Error Details: >>>> Could not connect to the specified server or database. >>>> Perform the following actions and then run the above repair command >>>> again: >>>> 1. Correct any misspelled server group names in the command. >>>> 2. Correct any misspelled or incorrectly formatted sqlhosts >>>> entries >>>> corresponding to the server groups specified in the >>> command. >>>> 3. Ensure that all servers specified in the command are >>> online. >>>> 4. If the error indicates a problem with the syscdr database, >> >>>> then ensure >>>> that ER is running on all the servers specified in the >>>> command. >>>> 5. Ensure that the user who is running the command has >> CONNECT >>>> permission >>>> to the specified database. >>>> >>>> >>>> DISCLAIMER: >>>> This email contains confidential information and may be legally >>> privileged. If you are not the intended recipient or have received >> this >>> email in error, please notify the sender immediately and destroy this >>> email. >>>> You may not use, disclose or copy this email or its attachments in >> any >>> way. >>>> Any opinions expressed in this email are those of the author and are >>> not necessarily those of the Fonterra Co-operative Group. >>>> http://www.fonterra.com/ >>>> >>> _______________________________________________ >>> Informix-list mailing list >>> Informix-list@iiug.org >>> http://www.iiug.org/mailman/listinfo/informix-list >>> >>> >>> DISCLAIMER: >>> This email contains confidential information and may be legally >> privileged. If you are not the intended recipient or have received this >> email in error, please notify the sender immediately and destroy this >> email. >>> You may not use, disclose or copy this email or its attachments in any >> way. >>> Any opinions expressed in this email