I think I have solved my problem. I worked on generating manual reports with tilescore.pl. And when including DVD store I got the following error.
Month '2016' out for range 0..11 at /cygdrive/c/VMmakr2/tilescore.pl line 657.
I also then realized that a full run didn't generate a wrf for oliodb either, so it wasn't actually a problem that I didn't have one for ds2db
So I had one of our devs help me through the code and the problem is the parsing of the date from the ds2web wrf files. My timezone is SAST with date format YYYY/MM/DD. The code for DS2 seems to expect it in YYYY/DD/MM. So we hacked the code to work with SAST. Interestingly enough I don't see this problem with Olio, so maybe the script can be improved?
These are the parts of the wrf files it parses for Olio:
[BENCHMARK] Benchmark start: 2017-01-17 23:11:01, maxUsers=400
And here is DS2
Controller (2017/01/17 11:11:21 PM): all threads connected - issuing Start
tilescore.pl can parse Olio but not DS2.
The issue is you didn't setup the templates and/or VMs with the correct time formatting "USA standard (Month/Day/Year)". I'm not sure what you intend to do with the results of your testing but the benchmark source files (including the tilescore.pl script) should never be modified in any way. All subsequent runs would be considered non-complaint. I recommend updating your environment for compliance.
Correct, DS2DB and OlioDB VMs do not generate a WRF file, they are backend databases only.
As far as I can tell from the documentation it only states:
NOTE The vCenter Server, the ESXi hosts, the workload virtual machines, and the clients (both physical and virtual) must also be configured to the same time zone.
The entire VMmark test environment must be configured to the same time zone.
but it doesn't actually dictate which time zone & time format.
Would have been useful had that been stated much earlier in the documentation rather than the footnote under miscellaneous troubleshooting for STAX errors (which I'm not experiencing):
If you observe “Out of bounds error by harness during time sync” in the STAX messages window, make sure the date and time format used by all Windows-based systems (that is, all clients and the vCenter server) is the USA standard (that is, month/day/year) as opposed to the UK standard (that is, day/month/year).
As for hacking the script, I'm sure these things can always be improved. Olio report section handles the date format, why not ds2? At this stage the output is for internal use, so I can manage without the explicit blessing of VMware
I agree and have already filed a bug for the documentation to be improved. Sounds like you're good to go for now. Good luck.