Both bottom two of the distribution, so far, are 'error' results ending in 'rc - 0x100' and little hope there seems for the next two repairmen to complete differently. Dubious if they would.

restored to 26133.491513.
[05:22:26] Starting new Job
[05:22:26] Qink name = fldman
[05:22:38] Qink name = gesman
[05:22:40] Qink name = scfman
Application exited with RC = 0x100
[09:16:59] Finished Job #6
[09:16:59] Starting job 7,CPU time has been restored to 39822.467590.
[09:16:59] Skipping Job #7
09:17:06 (4698): called boinc_finish

E225650_ 557_ S.332.C44H33N5.BRTJOOAAAPRXBR-UHFFFAOYSA-N.15_ s1_ 14_ 3-- - In Progress 10/5/14 14:40:33 10/9/14 02:40:33 0.00 0.0 / 0.0
E225650_ 557_ S.332.C44H33N5.BRTJOOAAAPRXBR-UHFFFAOYSA-N.15_ s1_ 14_ 2-- - In Progress 10/5/14 14:40:31 10/9/14 02:40:31 0.00 0.0 / 0.0
E225650_ 557_ S.332.C44H33N5.BRTJOOAAAPRXBR-UHFFFAOYSA-N.15_ s1_ 14_ 1-- 700 Error 10/4/14 19:41:41 10/5/14 08:52:09 11.17 279.5 / 0.0
E225650_ 557_ S.332.C44H33N5.BRTJOOAAAPRXBR-UHFFFAOYSA-N.15_ s1_ 14_ 0-- 700 Error 10/4/14 19:39:16 10/5/14 14:39:02 11.04 288.7 / 0.0

According the xml export api the outcome was 3, error and a validation state of 2, means invalid. Which is it?

Outcome: Return results based on the outcome of their processing. 1 means success, 3 means error, 4 means no reply, 6 means validation error, 7 means abandoned./
ValidateState: Return results based on the validation status. 0 means pending validation, 1 means valid, 2 means invalid, 4 means pending verification, 5 means results failed to validate within given deadline.

The exit code is zero, not specified in api, but to the agent meaning there was no error recorded on the host, all normal, therefor more appropriately it really being an 'invalid'

This conundrum has been brought up before, and yes it's understood some tasks will not do what the program is supposed to do, but should this not be a wcg/cleanenergy problem, and not an issue of the volunteer who gets the 'error' slap in the face? 22 hours down the hole and more to go, on this one alone. The validator rules can surely be set to not spit out 'error' and let you internally park these results aside, yes? On reading in past 'rc = nnn' was treated as 'not the volunteers problem', so why now?

Let's monitor this one and see if an earlier take out is justified when rc =100 occurs, i will.

On the search history front, found threads going back to 2010, that include replies like 'we'll give credit', which is the least of my interest. The issue is, they record as node error, therefor the host is forced out of reliability and wastes the next 20 computing with a wingman, when it could genuinely do it alone. Compute those wasted hours per day. FYI, this was a technicians reply in 2013 http://www.worldcommunitygrid.org/forums/wcg/viewpostinthread?post=431871 saying it's a validator margin issue to be corrected.

Please fix the public faced treatment. Disconcerting, disturbing, volunteer away-driving.