Some announcements would be great. I only know about 3.3sx (the x means experimental apparently) because Tom asked me to try to solve a Windows bug.

I asked Kynan to post here to hopefully pool knowledge.

So far we have tried reducing the -B on the database. This is 32bit Progress executables.
We have also tried running the dbmonitor manually from an elevated proenv session.

Neither of these have worked.

But bad error handling probably doesn't help...

I know it's bad design, but...

We have an AppServer called esd_test and a Webspeed broker called ESD_Test. This works great, despite being a terrible idea. But, ProTop has a bit of a problem with it. See below from pt3agent.appsrv.debug. asbman and wtbman are able to differentiate these on case.

[18/10/22@23:24:40.061+0200] P-002656 T-006120 1 4GL -- Logging level set to = 1
[18/10/22@23:24:40.197+0200] P-002656 T-006120 1 4GL -- ** tt_apsvList gibt es schon mit "ESD_Test". (132)
[18/10/22@23:24:40.197+0200] P-002656 T-006120 1 4GL -- ** ABL Debug-Alert Stack Trace **
[18/10/22@23:24:40.197+0200] P-002656 T-006120 1 4GL -- --> chkConfig dc\apsv.p at line 800 (.\dc\apsv.r)
[18/10/22@23:24:40.197+0200] P-002656 T-006120 1 4GL -- mon-init dc\apsv.p at line 899 (.\dc\apsv.r)
[18/10/22@23:24:40.197+0200] P-002656 T-006120 1 4GL -- dcLaunch lib/ptsrv.p at line 198 (.\lib\ptsrv.r)
[18/10/22@23:24:40.197+0200] P-002656 T-006120 1 4GL -- clientLaunch lib/ptsrv.p at line 241 (.\lib\ptsrv.r)
[18/10/22@23:24:40.197+0200] P-002656 T-006120 1 4GL -- doRequest lib/ptsrv.p at line 481 (.\lib\ptsrv.r)
[18/10/22@23:24:40.197+0200] P-002656 T-006120 1 4GL -- makeRequest util\pt3agent.p at line 387 (.\util\pt3agent.r)
[18/10/22@23:24:40.197+0200] P-002656 T-006120 1 4GL -- util\pt3agent.p at line 1640 (.\util\pt3agent.r)

By the way, this is a list of (probably) some of the differences between Workgroup and Enterprise: https://knowledgebase.progress.com/articles/Article/P122980
lruskips is one I often forget.

Your efficiency never ceases to amaze me!

Thanks Tom.
The reality of life is that, certainly in Europe, a LOT of end users have a Workgroup license because the cost is significantly less, financially at least. The added cost of poor performance is less likely to be taken into account!
I'm all for incessantly reminding people that Workgroup is bad. But maybe add a catch-all alert of "This is a workgroup database, what were you thinking?", and suppress the extra noise. At least that way you have the chance of seeing the real alerts among the noise.

Would it be possible/feasible/beneficial/etc to suppress alerts on the portal for features that are not actually available because of the RDBMS license installed? So for a site that has a workgroup license (boo, hiss, etc), I know I should plan to move to enterprise really, but in the meantime I don't want to be reminded all the time about the fact that large files isn't enabled, or the BIW isn't running, or -spin is set small (and other ones that escape me for now). They just clog up the Alerts feed meaning it's harder to spot the real alerts.
I suppose I could probably edit the config to suppress them, but then when I do go to Enterprise, I'd have to remember to re-edit the config to include them again.

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

Would it be possible to add certain headline information from the 'c' screen to the web portal so you can see things such as -B, DB/BI/AI Block Size, BI Cluster Size, etc, etc without having to log onto a server to look? Happy for this to be a premium feature - you've got to make money, but it's something I often think would be useful.
You're going to tell me it'e already there. I can sense it!!

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