Question Interpreting _latch-lock

ron

Member
Hi,

I'm collecting VST details, mainly to see before/after statistics for a soon-to-be change from 10.1C to 11.6.

In the _Latch VST I see a value of 2349332849 for the TXT latch (with promon) - but when I look with the VST I get -1945571795. (The figures were taken a few seconds apart, so there would be a small difference.)

I don't know how to interpret the negative number. However, ( 2 * 2147483648 ) - 1945571795 = 2349395501

... which is "close" - but how can I "know" to add 2 x 2 gig ?

Any wise words?

Ron.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Many of the "counter" fields in the VSTs were originally integer types and were later changed to int64 once that became an available data type and it became clear that the data in question could overflow an integer.

You can check this yourself in different versions of the VST schema:
Code:
find _file "_latch" no-lock.
for each _field no-lock of _file:
  display _field-name
          _data-type.
end.


The _Latch-Busy, _Latch-Lock, and _Latch-Wait fields all changed from integer to int64 between 10.1C and 11.4, though offhand I can't tell you exactly when.
 

ron

Member
Thanks Rob. Overflowing the int counter being the cause was what I understood - what "intrigued" me was that promon was able to display the value correctly. I suppose that's because the actual internal counter Progress uses is "big" (and what promon displays) - but it is when the data is moved into the restricted format of the VST definition that the value (effectively) gets corrupted.

Since I want the "correct" value - I may have to screen-scrape promon to get the numbers.

Ron.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Yes, there are some other fields like that too. If I remember correctly, TCP port numbers above 2^31 display as expected in promon but as negative numbers in a VST query.
 

TomBascom

Curmudgeon
One of them is a signed integer, the other is unsigned. The unsigned one has an extra bit available before it overflows.

There is also no way to tell if the value has overflowed more than once...

This is one reason why I prefer to deal in the increment between two samples a reasonable interval apart (like 5 minutes). Once in a while a sample might go negative but you can just ignore those. The vast majority will be correct and the values are much more meaningful.
 

TheMadDBA

Active Member
Tom is right... samples over large time frames become less and less meaningful. Except to notice that horrible things have been happening to your DB over time. Which should lead to you to look at smaller sample sizes to resolve the issues.
 
Top