« August 2004 | Main | December 2004 »
View server had a problem again. More and more it seems to be a problem with the NIC card on rtnlprod02. Managed to log into rtnlprod02 and look around. Couldn't see any processes at all in the TaskManager even though the 4 CPUs were 70-90% busy! Couldn't look at the Network tab - said there was no network adapter. Additionally the following appeared in the System event log:
Event Type: Error Event Source: NIC Agents Event Category: Service Event ID: 1285 Date: 9/21/2004 Time: 2:07:32 PM User: N/A Computer: RTNLPROD02 Description: NIC Agent: Connectivity has been lost for the NIC in slot 0, port 1. [SNMP TRAP: 18006 in CPQNIC.MIB] Data: 0000: 00 00 06 00 00 00 00 00 ........ 0008: 01 00 ..
Held code review for cmconfig.vbs. Spent the rest of the day implementing changes. Some changes were minor while a few others were good catches of possible problems.
Working mainly on cmconfig.vbs. Solution for the env problem was to set both the user environment and the process environment then call cmverfiy.cmd from cmconfig.vbs. The code now does the folowing:
There is a slight problem with the "set everything and verify it" script cmconfig.cmd. The idea was that that one script would perform 3 separate actions:
The problem is with #2 being VBScript and #3 happening as a result of executing from the cmconfig.cmd script. While setccconf.vbs does indeed set the proper configuration environment variables as soon as it ends those settings are no longer set anymore by the evoking script only. All other (new) processes know about the change to the environment variables. To illustrate this odd phenomena:
$ type setenv_var.vbs
Set sh = WScript.CreateObject ("WScript.Shell")
Set env = sh.Environment ("USER")
env ("foo") = "bar"
$ type senenv_var.cmd
@echo off
set foo=bar
$ echo foo = %foo%
foo = %foo%
$ cscript setenv_var.vbs
$ echo foo = %foo%
foo = %foo%
$ call setenv_var.cmd
$ echo foo = %foo%
foo = bar
$ cmd /c echo foo = %foo%
foo = bar
Why it works for a .cmd script but not for a .vbs script I don't know.
So I will change cmconfig.cmd to do #1 and #2 above but skip #3. This means two things:
The reason for #2 is that even after cmconfig.cmd is run environment variables such as CLEARCASE_PRIMARY_GROUP and CLEARCASE_GROUPS will not have been "exported" into that cmd's environment (unless somebody can tell me how to set the parent's environment variables from VBScript...).
For the point and click crowd this should be OK. The email message you send the customer should have two links: one to cmconfig.cmd and one to cmverify.cmd. If the customer clicks the cmconfig.cmd link then cmconfig.cmd should run, in it's own process, and go away. Subsequently if the user clicks on cmverify.cmd that will run in it's own cmd process and it should pick up the appropriate environment variable settings.
There have been many requests for enhancements to the configuration scripts including updating the TOOLS database on successful verification and performing additional checks such as "is this user really in the AD group". I believe I will only be able to solve the above problem by having the setccconf.vbs script actually envoke the cmverify.cmd directly so that the environment variables that setccconf.vbs just set are exported into the cmverify.cmd's environment.
Found that there are situations where one needs to have CLEARCASE_PRIMARY_GROUP set. Worked with Mike to implement groups in the TOOLS database. Spent a large part of today implementing setccconfig.vbs. This command will replace setregion and sets 3 things:
In order to do this the username is used to retrieve information from the TOOLS database. If the username is found then we get the project record and obtain the region. Next we check CC Primary Group and CC Groups. These fields will not always be filled in (previous entries lacked them but future entries should have them filled in. We then set CLEARCASE_PRIMARY_GROUP and CLEARCASE_GROUPS if there are any.
CC Groups in the TOOLS database will contain all Clearcase groups that the user belongs to - including their Primary group. In a lot of cases the user's CC Groups will be only one and equal to the Primary group. In that case CLEARCASE_GROUPS is not set. If the user is a member of more than one group then it will be their Primary group and additional groups in the CC Groups field. In that case Primary group is removed from that list and the rest are set into CLEARCASE_GROUPS.
Worked on setccconf.vbs