Problems configuring OE Replication - Forum - OpenEdge RDBMS - Progress Community

Problems configuring OE Replication


Problems configuring OE Replication

This question is not answered

Progress 10.2B08 on Windows servers

Trying to get OE Replication running on a client site. Normally have few issues but struggling today for some reason. 

Source and Target have identical files. 




When I Restart Server and check status it is 1100 on source, 3104 on target. The port 38140 is the port the database is started on on the Target DB. That's correct is it not? 

Any ideas? 

All Replies
  • 38140 is indeed the -S port of/for the target db.

    What does the pctrl.lg file say on the source side after the dsrutil pctrl -C restart server ?

    1100 is connecting ....

    It's not the properties, I used yours above for test and

    2016/10/31@18:12:49.372+0100] P-14772      T-15748 I RPLS    6: (11251) The Replication Server successfully connected to all of it's configured Agents.

    [2016/10/31@18:12:49.372+0100] P-14772      T-15748 I RPLS    6: (10436) The source database pctrl and the target database D:\repltest2\secondary\pctrl on host localhost are synchronized.

  • Looking for what you're asking for and found the following which I didn't find earlier:

    [2016/10/31@16:26:54.816+0000] P-14908      T-15416 I RPLS   18: (-----) Connection timeout for host cmlsql03 port 38140 transport TCP.

    [2016/10/31@16:27:44.818+0000] P-14908      T-15416 I RPLS   18: (-----) Connection timeout for host cmlsql03 port 38140 transport TCP.

    [2016/10/31@16:27:52.819+0000] P-14908      T-15416 I RPLS   18: (10396) The Fathom Replication Server cannot connect to the database broker on cmlsql03 at the port -27396.

    [2016/10/31@16:27:52.819+0000] P-14908      T-15416 I RPLS   18: (10397) The connection attempt to the Fathom Replication Agent l_idx41_pctrl failed.

    [2016/10/31@16:27:52.819+0000] P-14908      T-15416 I RPLS   18: (11241) The Replication Server will continue to attempt Agent connections until Mon Nov 07 16:21:12 2016.

    [2016/10/31@16:28:14.838+0000] P-6496       T-7964  I SRV    10: (742)   Login usernum 90, userid PSLAdmin4 client type ABL , on CMLSQL01 using TCP/IP IPV4 address

    We have 9 databases in the application and 10.2B suffers from that horrible 'feature' where database connect/disconnect messages are written for all databases in the session to each db log file, so there's a lot of noise. Easy to miss stuff! :(

  • This would suggest that either target database is not started on 38140, or the agent is not running (I believe you said it was), or there is a firewall between source and target.

  • Thanks Libor. Fairly sure it's firewall related. Got to wait for the datacentre to think about investigating now.

  • Rather than create a new thread, it seems the datacentre hosting the client's servers is having a bit of a nightmare.

    They tried to open the ports up on the firewall for this and ended up breaking connectivity for the application.

    So, they want to have a definitive list of what ports need to be open in order for the application to work. Is it just the ports that the databases are running on, or are there others?

  • How can opening up the ports break the connectivity ? :-D

    I don't know what does your app need port wise - aside of the client server that is.

    For the replication itself between the source and target it would be:


    range from listener-minport=4387 to listener-maxport=4500 (you can tighten this up to like 2 ports range per DB set, if you are replicating more than 1 set of databases)

    For the client-server connectivity it would be -S and range from (database) minport to (database) maxport.

    if you have appserver/webspeed etc - there is more.

  • Thanks Libor. I suspect that they changed from a blacklist to a whitelist or something. They were meant to be opening up the connectivity between Source and Target, but broke the connectivity between the Citrix boxes and the source in the process. No idea what they did. Bit useless though.

    The annoying thing is we get it in the neck. The datacentre never makes mistakes apparently.