Trust me, I had that idea long before Rob mentioned it

Something like that will probably occur. I need to start mucking about with oe12 now that it is actually available.

Just came across a case with a new CentOS VM where "time" wasn't installed. syncio.sh didn't do much of anything, just exiting pretty much immediately. which time didn't find a time command. Upshot: I installed time and then syncio.sh worked as expected. The code that sets TIMECMD may need to be a little more robust.

@kynan great!

Zing!

@rob-fitzpatrick Yes, that is correct.

I would like to see historical Checkpoint information on the portal. It would help to verify changes to biclustersize

Rob is correct, and ProTop already has the equivalent alarm: it's called the heartbeat. If monitoring is NOT running OK for any given monitored resource, the web portal generates an alert saying "HEY! I haven't heard anything from the ProTop agent for siteName.ResourceName for the past x minutes!!". This is much more interesting than getting an hourly or daily "Everything is OK!" email as you may not notice if you miss one or two or five. The default heartbeat check interval is 1200 seconds. After that, a heartbeat alert is generated. Note however that you must configure in ProTop where your heartbeat alerts are sent. They can stay in the web portal, they can be sent to an email list, or they can be sent to an emergency "pager" list (typically to your mobile phone). The various web portals around the world also ping each other via email to make sure that outbound alerting is always working. if one of the portals fails to send emails for more than a few minutes, one of the other portals alerts our devOps team so that we can investigate.

@jdpjamesp (Somewhat off-topic): That KB list is pretty close to a list of my own that I've been updating off and on over the years. I stopped updating mine when, thankfully, I got rid of my last WG license. However to me this looks questionable, re licensing requirements for TDE: OpenEdge Enterprise RDBMS and OpenEdge TDE or alternatively Advanced Enterprise Edition RDBMS available since OpenEdge 11.5 (for Production) OpenEdge Development Server (for Application deployment) I don't see what OE Dev Server has to do with TDE. It is the development version of App Server, is it not? Same goes for the footnotes for MT and TP. Also, aren't -napinc and -napstep decommissioned?

Understood. Enhancement added to our TODO list.

YES. Or maybe right-click - copy the whole thing to clipboard.

It is ugly and annoying but it should be harmless. The issue has been fixed in the next release.

It isn't batch-friendly directly. But a .bat can also invoke _progres.exe and run ABL, which can declare Windows functions as external procedures, so it might be possible to make it work.

Good news Tom. If you need any help testing then let me know.

Makes sense Tom. Thanks. Need to get my access to the machine sorted so I can investigate in depth.

etc/appsrv.cfg is your friend The extensive and highly detailed documentation in the header servers as your "user guide": # appsrv.cfg # # type name "query command" # # - names (column 2) are case sensitive! # - the "name" field will be substituted for "&1" when the command is run # # i.e. # ws ws1 "wtbman -i &1 -query 2>&&1" # # admin proadsv "proadsv -q 2>&&1" # admin server does not actually use the name field -- but we need a name entry # ns NS1 "nsman -i &1 -q 2>&&1" # apsv asbroker1 "asbman -i &1 -q 2>&&1" # ws wsbroker1 "wtbman -i &1 -q 2>&&1" You can then add a resource in the usual manner. Just use -1 for the dbname Unless you only have one db or you have one that it makes sense to tie the app servers to, you will probably want an etc/pt3agent.resource.cfg file dedicated to your app servers. Regardless the ptInitDC needs to have AppSrvStatus added to it. If it is a stand-alone app server agent (no db) then you will probably not want any other data collectors running. Something like this (etc/pt3agent.appsrv.cfg): # pt3agent.cfg # # you must restart after changes -- this cfg file is not monitored # # pt3agent.friendlyName.cfg will override this config for a friendlyName instance of pt3agent # ptInitDC "AppSrvStatus" As always, you can (and should) test your configuration with the ChUI ProTop before getting too crazy. If you called your resource "appsrv": protop appsrv Will fire up the ChUI client. The dashboard and other db centric screens will be null but you can dismiss them if you'd like. The "@" command brings up app server data.

Yes, it's true. I blame Paul. He keeps taking time off instead of "working"...