Re: Can ping, but can't connect.

Drew wrote: > > you may check out sqlhosts file in etc directory to see if the > protocol > > is correct, or some hidden file ( I cant remember correctly) related > to > > trusted client connection. It should be resident in $INFORMIXDIR, > and > > I encountered this kind of error accidently even no para changed. > > > > good luck ;) > > robert > > Cosmo, > > If there are problems with the nameserver, you may try adding an entry > > in the hosts file on a client machine. Also the services file on the > client can cause problems. > > Drew Did that. Both Primary and Secondary have entries in their respective /etc/hosts files. I know that the connectivity from the secondary to the Primary is OK, because I can use dbaccess to connect to the Primary databases no-prob. I believe that the connectivity from the Primary to the Secondary is OK too (it was fine before), but can't really test this because the Secondary comes up in Recovery mode after the `ontape -p`. But dbaccess from the Primary states that it cannot connect to the Secondary because the Secondary is in Quiescent mode - so I know that they are talking. What's odd is that the two can talk this way, but won't connect in replication mode. I'm starting to suspect a possible `ontape` bug. We're currently having problems w/ ontape reading tapes made on the primary. Perviously, restores from `ontape -p` would seemingly restore successfully. I'd run all the `oncheck` options just to make sure, and everything came up roses. But when I actually tried to bring the thing up there would be error entries about bad pages in the online.log file. For some reason, pages on a chunk on one drive were overwritting pages on a chunk on a completely different drive. Odd that `oncheck` didn't find any of this. So, I'm proceeding on the theory that this is an `ontape` problem. The last restore was done with a remote tape. I can't say that I have a high level of confidence with this, given that we are trying to restore several Gig of data over a clogged network - despite the fact that `ontape` doesn't flag any error. Neither `ontape` nor `oncheck` flagged the last prolem. -- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ADDRESS ALTERED TO FOIL SPAMMERS: Remove "*NO-SPAM*" to reply. Cosmo Lee Multi-User Computer Systems Brooklyn, NY "JUST SAY 'NO' TO SPAM" * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *