C
ChUIMonster
Guest
Here is what I have discovered: 0) My dislike for properties files and windows is even more well founded than I imagined and has not been improved in any way by this experience. Applying the Linux patch gets more attractive every time I see a windows login screen 
1) There were several minor configuration issues. These were very aggravating but, in the end immaterial. The biggest problem with these is that anything involving properties files is basically trial and error. There is no useful logging by default. You can turn on more logging but that requires restarting the admin server (not so easy on a server that is being used by others) and when you do that you get flooded with a whole lot of drivel -- finding anything useful is nearly impossible. 2) "dbman" et al are opaque. They often do things silently -- no matter your logging level they write nothing anywhere. And then simply return no information. You get to "try it" to see if it works. The trial and error cycle is very time consuming. 3) There are a whole lot of very knowledgeable and helpful people out there -- thank you all! But especially Libor who pointed out the biggest problems and convinced me to try a couple of things that I was sure didn't matter. ... drum roll... 4) I'm not very smart. For years I have been implementing replication working on the assumption that: proserve dbname -DBService replserv -S port# is the canonical command to start a db with replication enabled. I had this misguided idea that the -S was "tied" to the -DBService. I don't know why I thought that. In retrospect I should have known better. (Although, in my defense, there are a lot of examples in the documentation that look this.) None the less -- this approach of setting aside a port and specifying it on the proserve command line has worked very well and continues to work well in scripted environments (UNIX). I expected it to work and it took a lot of persuading (thanks Libor) to convince me that it was causing problems. I had also *thought* that you needed a port dedicated to the replication service. This seems to be untrue. Apparently you can just put any old 4gl broker in dbname.repl,properites (I didn't try sql brokers). Anyhow... the root problem seems to have been that adding -DBService replserv -S port# to "otherargs" somehow prevents any of the "server groups" in conmgr.properties from starting. Even if the port# is not in conflict with anything. For reasons that escape me there do not appear to be any messages in any log files which would reveal that this is happening. You just get to wonder why you cannot connect when all that you (think that you) did is to start replication services. Furthermore, as it turns out, "dbman" magically figures out that it needs to start a replication server (a fact which is not visible in any log file that I've been able to find). Which makes the addition of DBService to otherargs pointless and possibly harmful. So, in the end, it was basically "operator error". Thanks to everyone who pitched in and helped out!
Continue reading...
1) There were several minor configuration issues. These were very aggravating but, in the end immaterial. The biggest problem with these is that anything involving properties files is basically trial and error. There is no useful logging by default. You can turn on more logging but that requires restarting the admin server (not so easy on a server that is being used by others) and when you do that you get flooded with a whole lot of drivel -- finding anything useful is nearly impossible. 2) "dbman" et al are opaque. They often do things silently -- no matter your logging level they write nothing anywhere. And then simply return no information. You get to "try it" to see if it works. The trial and error cycle is very time consuming. 3) There are a whole lot of very knowledgeable and helpful people out there -- thank you all! But especially Libor who pointed out the biggest problems and convinced me to try a couple of things that I was sure didn't matter. ... drum roll... 4) I'm not very smart. For years I have been implementing replication working on the assumption that: proserve dbname -DBService replserv -S port# is the canonical command to start a db with replication enabled. I had this misguided idea that the -S was "tied" to the -DBService. I don't know why I thought that. In retrospect I should have known better. (Although, in my defense, there are a lot of examples in the documentation that look this.) None the less -- this approach of setting aside a port and specifying it on the proserve command line has worked very well and continues to work well in scripted environments (UNIX). I expected it to work and it took a lot of persuading (thanks Libor) to convince me that it was causing problems. I had also *thought* that you needed a port dedicated to the replication service. This seems to be untrue. Apparently you can just put any old 4gl broker in dbname.repl,properites (I didn't try sql brokers). Anyhow... the root problem seems to have been that adding -DBService replserv -S port# to "otherargs" somehow prevents any of the "server groups" in conmgr.properties from starting. Even if the port# is not in conflict with anything. For reasons that escape me there do not appear to be any messages in any log files which would reveal that this is happening. You just get to wonder why you cannot connect when all that you (think that you) did is to start replication services. Furthermore, as it turns out, "dbman" magically figures out that it needs to start a replication server (a fact which is not visible in any log file that I've been able to find). Which makes the addition of DBService to otherargs pointless and possibly harmful. So, in the end, it was basically "operator error". Thanks to everyone who pitched in and helped out!Continue reading...