« December 2006 | Main | March 2007 »
I have been working resolving problems with the cclic_report for this month. The script to do this has been failing due to a subtle bug in the algorithm used for obtaining the necessary files to translate the various user IDs and map them to Org 9 numbers and the like.
The script looks in a series of files out on the file system in order to obtain information to build mapping tables it needs to do the translation. These files are of the form:
/data/cmetrics/recv/<site>/<type>.<year>/<date>
Where:
These files are automatically generated by dsmetrics however they are not guaranteed to be up to the minute. The script attempts to workaround this by first starting with the current day then working backward one day at a time for up to 30 days. Thus if say /data/cmetrics/dal-design/passwd.2006/2006-12-31 has not yet be generated 2006-12-30 will be checked, then 2006-12-29 and so on.
Problem is that that algorithm assumes that the data store (e.g. /data/cmetrics/<site>/<type>.<year>) has at least 30 days of information. This assumption breaks when the year changes since the year is contained in the parent directory. So, for example, given today is 1/8/2007, if .../passwd.2007/2007-01-08 has not be generated we can only check for 07, 06, .., 01. Checking for .../paswd.2007/2006-12-31 makes no sense and will never work.
Updating of the various files under /data/cmetrics seems sporadic. Currently the script is still not runnable as there is no /data/cmetrics/recv/tii-shared/password.2007 entries at all! The script is failing with:
$ ./cclic_report.pl -v
cclic_report.pl (v{VERSION}) starting
Getting full path to data files
Unable to find /data/cmetrics/recv/tii-shared/passwd.2007/2006-12-10 at ./cclic_report.pl line 137
main::findFile('/data/cmetrics/recv/tii-shared/passwd.2007') called at ./cclic_report.pl line 249
I can see no real quick or easy solution for this except to wait for tii-shared's 2007 files to be generated...
It was hoped that we cout point things to "login servers" instead of machines specifically designated as DesignSync servers as had been the case for gpdb_add_project.pl. These script really only require cleartool and access, through the automount map, to the sync_custom area in order to pick up the SiteRegistry.reg file.
However gpdb_add_vob.pl uses a heuristic in an attempt to determine what project a particular vob is associated with. The heuristic states that the vob storage path will have as part of it's path, a project directory. While this is often, but not always, the case here in Dallas, it is not the case at all in Nice! Thus, even though gpdb_add_vob.pl can log into remote sites to gather information about vobs, when logging into Nice it finds that no vob in Nice adheres to this convention and thus it cannot add vob records for any vob in Nice. Nice had been using vob attributes for things like the AID of the owner of the vob but there is no attribute for the project that a vob is associated with!