Re: ER problem / bug? in 11.50.UC3



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@xxxxxxxx
[mailto:informix-list-bounces@xxxxxxxx] On Behalf Of Madison Pruet
Sent: Monday, 23 February 2009 1:52 p.m.
To: informix-list@xxxxxxxx
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@xxxxxxxx
[mailto:informix-list-bounces@xxxxxxxx] On Behalf Of Madison Pruet
Sent: Monday, 23 February 2009 9:02 a.m.
To: informix-list@xxxxxxxx
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@xxxxxxxx
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@xxxxxxxx
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/

.



Relevant Pages

  • Re: 5.3-RELEASE: WARNING - WRITE_DMA interrupt timout
    ... My problem is not related to a SATA controller. ... Everything works pretty well on this server. ... the qmail MTA, an otherwise pretty powerful email program. ... I'm going to apply a patch to qmail in a few days. ...
    (freebsd-current)
  • Re: KB917537 Failing
    ... four days after the patch released. ... mature server OS, an enterprise-class messaging system, and automated ... if you hit the "Restart" button ... here as I had assumed this would be a common problem.. ...
    (microsoft.public.windows.server.sbs)
  • Re: FOLLOW UP : Forms Authentication Randomly Times Out (Windows 2003)
    ... Well there goes my theory on the patch. ... "Joe Audette" wrote in message ... > It doesn't look like we have that patch on our server. ... > had to scrap the automatic re-direction to login from the ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Firewall für Web Edition 2003
    ... Natürlich ist das nicht die einzige Massnahme, ... Patch Management-Konzept ist definitiv notwendig, ... >> geht es ausschliesslich um den Betrieb als Server. ... > Die Anfrage klang aber nicht nach: Wie installier ich ISA auf Windows ...
    (microsoft.public.de.german.windows.server.networking)
  • Re: lag since 1.9???
    ... I believe this is server db related. ... constantly have delays when looting (hey look, a hostile mob approaching ... The Diablo II re-sync ecstasy! ... > Overall I'm very happy with the patch. ...
    (alt.games.warcraft)