That did the trick, thanks!

Done.

Further to this, and assuming that I should see the same "culprits" in table and index CRUD within the top ten of each, I have an issue that I think I haven't reported before. In this case, the number two table ("vendor") in reads (Raw/Summary) doesn't show up in PT. Here is PT data and my data:

Tbl# Area# Table Name RM Chain #Records Frag% Scat Turns AvgRow Create Read v Update Delete OS Read ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 274 7 sd-joint 502 29666 0.00% 1 1067.01 42 0 31653874 0 0 246 277 11 sd-payt 250412 44931896 0.22% 1 0.01 189 227 306531 886 0 5379 -2 6 _Field 10318 76.55% 6 16.33 315 0 168536 0 0 0 85 7 corp-individ 409 109744 52.71% 1 1.03 289 0 113334 0 0 4012 271 7 sd-cash-drawer 508 733 0.00% 1 52.01 117 0 38121 254 0 23 282 15 sd-teller-tran 336 19871693 0.00% 1 0.00 108 20 34233 0 0 20767 284 7 sd-xact 503 572 0.00% 1 54.48 84 0 31161 0 0 7 270 7 sd-acct-xact 507 8382 0.00% 1 3.54 50 0 29714 0 0 18 201 7 occup 507 164 0.00% 1 140.01 33 0 22961 0 0 2 -1 6 _File 688 92.30% 5 30.25 450 0 20810 0 0 0 Table Table name Reads Reads/sec O/S Reads Hit % Creates Updates Deletes ───── ──────────────────────────────── ────────────── ────────────── ────────────── ─────── ────────── ────────── ────────── 274 sd-joint 31,653,874 3,521 246 99.999 0 338 vendor 1,209,643 135 51 99.996 0 277 sd-payt 306,531 34 5,379 98.245 227 886 -2 _Field 168,536 19 100.000 0 85 corp-individ 113,334 13 4,012 96.460 0 271 sd-cash-drawer 38,121 4 23 99.940 254 282 sd-teller-tran 34,233 4 20,767 39.336 20 0 284 sd-xact 31,161 3 7 99.978 0 270 sd-acct-xact 29,714 3 18 99.939 0 201 occup 22,961 3 2 99.991 0 -1 _File 21,641 2 100.000 0

Confirmed. Thanks!

Thanks Tom. After updating ttinfo.p, I got it to work.

Ok, good to know what to expect. Thanks!

Yes indeed that's what I'm looking for! I'll have a look and see. Thanks Tom.

The parenthesis are a bad idea. You really want to do it like this:

if "%DLC%"=="" set DLC=D:\Progress\OpenEdge11.7

Yes, it's true.

I blame Paul. He keeps taking time off instead of "working"...

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.

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

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.

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.

@kynan great!

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.

@tom said in Configure the User Information Viewer:

I'm thinking that the statement cache should automatically appear or disappear based on whether or not it is enabled for a particular client.

That's reasonable. Though I'd still like to be able to turn the individual browses on or off. 😉

It would also be nice to have the act of turning off User Information Viewer revert to a view that is more useful, as opposed to just removing the header section. E.g. if the act of going into it cached the current list of displays (e.g. d, t, i, u), so they could be restored when u is pressed again. Food for thought.

@tom said in OE 12 support:

Lastly, I also (sneakily) patched the pt3.14 release a week or so ago. If your "as of" date on that is in May rather than March then you should also have the oe12 changes (but not the "4" hotkey).

That explains it, I got the error from the original March version.

Should be fixed in pt3.141x. I decided to simply use the first part of the device name unless the device name is "batch" and only if the name is otherwise blank. If that fails then use the usr#.

Nope. You're right -- that's a bit more difficult to calculate and it seems much less likely.

But I'll add it to the "think about it" list 🎣