@tom Sorry... off to the coffee machine...

Looks like it dates back to pt3.3n. It is fixed now.

@tom said in Alert re lkHWM near lkTableSize: Regarding the specific alert: there is a lkTblPct field which I use for a similar purpose. Rather than the HWM it reflects the locks in use at that moment. In some ways that is better -- the HWM sticks around until you restart and if something went bump in the night is going to keep alerting once you hit the threshold. Good to know, thanks.

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

Portal v4 has a lot of enhancements to stuff like this. Real Soon Now.

Which reminds me of another needed alert "not having audit archive db"

I think I probably need more visuals. I'm not forming a picture in my head of what you are describing.

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#.

This is almost always for one of these reasons: The -tablerangesize or -indexrangesize parameters are not set to cover the active tables & indexes. The ChUI "T" command will show you what values are recommended and create a sample .pf file for you in the ProTop temp directory. Unfortunately you cannot change these values online. A db restart will be needed. The activity on the tables and indexes does not meet the threshold criteria. You can review the thresholds on the portal "Resource" screen. For development and test environments you probably want very low values. For Production you want higher values -- a chart with 2,000 objects on it will be unusable (that is why we have a minimum activity threshold). You should also verify that etc/pt3agent*.cfg has the TableActivity and IndexActivity data collectors enabled. If they are missing from ptInitDC then that data is not being sent to the portal.

That didn't take long! Thanks for the tip, I'll look into it

@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.

@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.

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!