Topics created by Rob Fitzpatrick

if ( not _Connect-device matches "*batch*" ) and _connect-batch <> "yes" then tt_Dashboard.con_self = tt_Dashboard.con_self + 1.

So "self" is counted for non-batch self-service connections. It (mostly) equates to local interactive connections.

Somehow I suspect that you are going to suggest that that might be sub-optimal 😉

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

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

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

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 🎣

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

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

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.

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.

I dunno, you're a pretty shady character...

@tom said in PT3.3s: cosmetic bug: splash screen:

I have not been able to reproduce the behavior that you describe.

I seem to have a talent for that.

I won't be rushing out that patch 😉

Got it. Fixed in patch 01.

Another data point for you: I just updated a 3.3r installation to 3.3s.

Saw this line in pt3inst.log:

protop.pf already exists in etc, saving a copy as /opt/protop/etc/protop.pf.04.19

The new protop.pf does contain -inp 16384. So it looks like all is well with pt3upd.sh.

Busted.

The "x" versions are pre-release stuff. It can, and does, change rapidly. Sometimes it contains nasty bugs. The "x" releases are deliberately not made visible on the download dropdown - you have to know to fetch it with curl or pt3upd.sh and hope that I didn't just build something with a bug in it.

I make no attempt to version the "x" stuff -- there have been hundreds of pt3.3sx builds -- if you have one it is probably not the same as anyone else's 😉

Certain people have been urging me to get better about the versioning process.

On the bright side there are release notes 🙂