I think you are missing the point here, nelsoc. WCG is supplying the data. I, and I suspect other members, expect, because of WCG's status, to be above suspicion. In other words to be truthful and honest at all times with members and partners.

I sent WCG a private E-mail earlier this morning, which to date WCG has failed to respond, so I will make this public. All WCG has to do is alter the front page membership claim to read " All time membership 85.XXXk", until the matter is resolved. How hard is this to do?

If WCG needs further help I am sure we can work together to find an answer, we are on the same team, not on opposite sides. You know where we are.

Hello photobytony,

The problem is that the server is, as far as I can tell, simply maintaining a cumulative total in which each successful installation of the WCG program adds 1 to the Device Total and also adds 1 to the member total if the 'Previous Member' box is not checked. This is a totally truthful Cumulative Total. There is no reason to suspect the server is fiddling with the bits.

But we want new figures that record the ACTIVE devices and members. The first thing is to define active. My preferred definition is the longest time allowed for a result to be returned. Currently that is 3 weeks. So any device / member returning a result within 3 weeks would be defined as active. For simplicity, I would like for that duration to be an input into the program, since it will change with new projects and I would like to minimize the complexity of the program. For similar reasons, I want to ignore the complex issues involved in actually removing / inactivating teams, members, devices and team memberships. The idea is to provide 2 simple figures for active members and active devices (computers).

Back in the 1970's, we would do this sort of thing on a monthly basis and call it an 'aging' report. We would run it once a month during 'month-end' and try to get all the monthly jobs done over 2 or 3 days. I can see several ways to do this. The simplest program would simply run over the database looking at the time of the last result returned for a device and at the creation date for a device. [Since any device created in the last 3 weeks would charitably be called active, even if it had not returned a result.] A simple temporary Boolean column for the member owning a device would allow us to see if we had already credited a member with an active / new device. If not, then set the column value for that member to TRUE and increment the active member total.

This could be run at midnight GMT along with team statistics. I can see several variants possible, depending on database design and speed issues. Just the same, it IS programming, with all the careful testing and verification issues that multiply the time required to implement even simple changes in a database design.

Just now, we have to set up a number of test databases to use as part of the testing and verification phases for boarding new programs and new clients. Also, knreed is getting a much deserved week-long vacation starting this weekend before returning to fight forest fires with the programmers working on these future changes.

I admit, I am not personally happy with figures that are wandering farther and farther from what I regard as reality. But we do have good figures for results and CPU time. When I try to figure out time and labor required for changes on the server software, I put this nice-to-have feature behind, for example, spending time helping new project suppliers with their server issues so that we do not get blind-sided by server problems on the other end of our connection. This is all too likely an event as we start to work with new research organizations who are taking on the problems inherent with huge databases for the first time in response to the availability of the WCG as a new computing resource.

I said in a post in another thread today that we present the appearance of just coasting while working on a well-established project, letting the computers do all the work. It is understandable that this seems like the time to make some desirable adjustments. But the picture that I get from the back-channel messages that Community Admins receive is a lot more frenetic than the surface appearance. When busy programmers start throwing up their hands and chanting "Not a priority" to a request for a nice-to-have feature change, my personal inclination is to back off and accept it without a lot of recriminations.

What I am trying to say is - - I agree that this would be a nice change to implement, but right now I counsel patience.

mycrofth