Configuring Oe Replication Plus For Dummies With Openedge Explorer

Clueless

New Member
Dumb question: I am trying to configure OE Replication Plus on a Windows 2012 server, but I am baffled at how to configure this using the OpenEdge Explorer.

I can get things working by using the proenv commandline, but cannot figure out how to do this with OpenEdge Explorer:

proserve database -DBService replagent -S 4501 -Mn 7 -n 45
proserve database -m3 -Ma 5 -Mpb 5 -ServerType SQL -S 4000

Then:

sqlexp database -S 4000 -user odbc -password odbcpassword

WORKS

In the OpenEdge Explorer for the configuration.database.defaultconfiguration , I added:

-DBService replagent -S 4501

in the "Other arguments" section

and then I configured the SQL broker in the section:

servergroup.database.defaultconfiguration.defaultservergroup

I added 4000 for the Service name or port and changed the Client Type to SQL.


When I start the database, port 4501 is listening, but port 4000 never starts listening.
I changed the Client Type to Both and 4GL for debugging and the port never starts listening regardless of Client Type.

I can't find anything in the KBases and I have a case with Progress Tech Support, but after 5 days with no solution, I am becoming impatient...

Thanks in advance for any help!
 

Clueless

New Member
Found answer: replication port can be used by 4GL and SQL clients. So no need for separate brokers...

This, of course, is the opposite of how the source database is configured = with separate 4GL and SQL brokers for performance and administration (in case the SQL broker/server hangs, then it can be shutdown and restarted)...

***Solved.
 

Cringer

ProgressTalk.com Moderator
Staff member
Some of our clients have gone one step further and have been assimilated by the Borg. They've installed OEM. In theory it's great - it's meant to alert on all sorts of important stuff like AppServers down, Replication down, etc, etc. Except it blows the Java Heapspace without warning, so the Adminserver crashes. The DBs carry on running quite happily without the Adminserver, but the alerting relies on it and so the alerts just stop coming through. You only know about this when, hopefully, you try and stop/start a database and it doesn't work. You schedule a reboot. Happy days. Trouble is, often you only know about it when it's failed to alert on something for weeks and now the DB has crashed because the AIs are full and now you have to reseed Replication on a 200GB database.
In other words OEE and OEM are filth and should be avoided at all costs.
ProTop on the other hand... :D
 

joey.jeremiah

ProgressTalk Moderator
Staff member
Now that I'm part of the borg, I guess I'll be speaking for the collective... :)

I've had my fair share of issues with the AdminServer but there's usually a good reason, like, a busy port, permissions etc., all of them were resolved and once it's setup there's nothing more to do.

I've personally moved away from scripts and the command line and I've never looked back.

Besides, what about everything else you might need for a complete resource management solution, like, proactive monitoring and actions, managing remote sites and servers, dashboards, scheduled reports, centralised place to manage and schedule your jobs and utilities etc.

If there are issues, sure they have to be fixed but going back to using a script directory and the command line for only the most basic operations isn't an alternative.

Looking at the planned features for OEE/OEM in the roadmap presentation slides from the NEXT conference: new data dictionary, database and PASOE stress testing, custom ABL and Kendo UI rules and dashboards etc. ... it continues the theme of a top to bottom resource management solution from hardware to Progress OpenEdge resources to your application. I don't think the AdminServer and OEE/OEM can be ignored.

BTW these are just my opinions not Progress or anyone else's.

May the force be with you :p Nanu nanu :)
 
Last edited:

TomBascom

Curmudgeon
Who put that soapbox there? ;)

There is a command line renaissance underway in the dev ops world. I imagine Progress will notice that in 10 years or so ;)

Mouse driven management tools are execrable in every way. I cannot imagine why anyone serious about having things done in a repeatable and consistent manner would ever consider such tools -- it's just crazy. Even Microsoft has started to see the light.

Just the other day I spent a bit of quality time with a customer who insists on using those mouse driven tools. For some reason connections to one of their databases were mysteriously failing. No matter how many times they clicked on the "start resource" button etc. After a quick look at the .lg file and some command line investigation it turned out that at some point in the distant past someone had accidentally clicked the box that enabled SSL connections for that db. Which apparently worked ok with the default certificate. Until it expired.

OEE/OEM are not a requirement to use the admin server -- not should they be. Editing properties files by hand (or with mergeprop if you want to go crazy) is perfectly feasible and a lot more productive than fighting your way through the OEE "experience".

The admin server desperately needs reliability fixes. We're stuck with the cursed thing -- it *has* to work better. Removing Java from the picture would be an excellent first step. If I held the purse strings that's where I would start.

Updating the dictionary? Yes, that's a good idea too. It's about 20 years overdue but certainly a good idea. I look forward to it.
 

joey.jeremiah

ProgressTalk Moderator
Staff member
I know most experts prefer using the command line and vi. The same with Microsoft Powershell but mere mortals like myself have a problem remembering all the Progress servers and operating system commands and switches. I usually need the documentation for that. The same for editing huge OpenEdge or Tomcat configuration files. I even install webmin for the Linux stuff. Shame on me :)

Maybe the idea to put the dictionary in OEE will trick more people into using it :)
 

TomBascom

Curmudgeon
I'm an Emacs guy. Microemacs actually. VI is a travesty. Bill Joy should surrender his Programmers Guild card and forever hang his head in shame for foisting vi on the world and calling it an "editor".

There is no shame in needing the documentation. Except for a few fairly obvious things I need to reference the docs a *lot*. I make sure that the documentation is never far away -- perhaps even just a mouse click away (mice are good for something after all!)

But I only rarely type raw commands at the command line and thus have little need to memorize every command option -- most administrative activity is scripted and tested well in advance. You can do that with commands and scripts -- you cannot do that with mouse clicks. When people are clicking stuff THEY MAKE MISTAKES. Lots of mistakes.

The OEE configuration screens are impervious to reason and sense -- do I leave that field blank? Put a zero in it? I thought the maximum value for that parameter is X but OEE keeps restricting it to Y... and on and on and on... a pox upon OEE. (It's also ugly as sin.)

I heard the bit about updating the dictionary at the partner conference but I did NOT hear that it would be part of OEE -- if that is the plan then it is utter nonsense and I rescind my positive comments about upgrading the dictionary. Let us hope that more sensible minds prevail.
 

cj_brandt

Active Member
We have people that like to see GUI interfaces so we use OEM as a way to get trending and secondary monitoring. We had to allocate 4gb of memory to our admin servers to keep them from shutting down with some java memory issue.

@Cringer - OEM has some diagnostic pages that will help you see the memory the admin server is consuming. It won't alert you, that its about to die, but you can see the memory usage slowly increase and know when its about to reach the limit. The pages are in./diagnostic. I have found system.jsp and memory.jsp to be most helpful. Just append /diagnostic/system.jsp after the port number in the URL.

I would be very interested in seeing a presentation or just hearing from someone that uses OEM to monitor 500 or more resources (using multiple OEM instances). We try and I'm thinking there has to be a better way that how we are doing it.
 

joey.jeremiah

ProgressTalk Moderator
Staff member
I have found a case study of a customer using OEM to manage approx 900 resources across 40 remote adminservers.

I'm checking if the case study can be made public and will let you know soon.
 

joey.jeremiah

ProgressTalk Moderator
Staff member
Maybe I'm not the most objective but I wanted to mention that there have been some performance and resource usage improvements to OE Management in 11.7.

I have been playing around with OE Management 11.7 today and it does feel more responsive and faster.
 

WinNix

New Member
Every few versions I'll give OEE a re-try. I've yet to find it satisfying, but I'll give it 1 chance in 11.7 (maybe). Command line has always gotten the job done.
 
Top