Status for Andrew DeFaria

• Exposed salira2 vob
• Set up multisite schedule for sons-sc-cc to mimic sons-clearcase. Before this sync receives were only performed once! Things started backing up in the storage bays. All cleared out now.
• Attempted to build 4.0. Had problems in dynamic view
• Managed to build in 4.0 snapshot view.
• Figured out that certain exe's were missing execute permission in Clearcase Element Properties. Seems Clearcase 2003.06.00 is a bit more picky about those than Clearcase 2002.05.00! Build now works in dynamic view as well

TIme Spent: 2 hours

Simon Zhu wrote:

Similar to sc_3.1_dev, I made config spec sc_4.0_dev. It does not make any difference since I could not find “cenopon” under salira2 when I load the view. It seems to me that the VOB was not fully replicated. You may take a look. Thanks.

The szhu_view4.0 has a config spec of:

#element * CHECKEDOUT
#element * /main/LATEST
include //sons-sc-cc/views/official/salira/neopon/cs/sc_4.0_dev
#load \salira\neopon
load \salira2

And the following lines appeared in sc_4.0_dev:

# Now pickup any new elements created at the other site
element * .../rel_3.1/LATEST -mkbranch sc_4.0
element * .../china_4.0/LATEST -mkbranch sc_4.0

This should be:

# Now pickup any new elements created at the other site
element * .../rel_4.0/LATEST -mkbranch sc_4.0

element * .../china_4.0/LATEST -mkbranch sc_4.0

We can see this in the version tree for the root folder \salira2 :

Prior to fixing the config spec the "eye" pointed to /main/0, which, of course is empty.

Next I attempted simply a make. Most of it worked! Except:

[LINKING]      vxWorks_st.elf 
Converting to bin...
/bin/bash: maketools/convert: Permission denied
make: *** [scs.bin] Error 126
[ccadmin] sons-sc-cc:ls maketools

I don't know why I get permission denied when attempting to run maketools/convert. This is only happening in a dynamic view. I created a 4.0_snap view and the build worked fine.

Ah ah! It appears that the execute bit on the Properties of the Element for maketools/convert.exe was not set, even on sons-clearcase. However it also appears that Clearcase 2002.05.00 didn't care about that but the new Clearcase 2003.06.00 does. I toggled the execute bits on for convert.exe (and other .exe's in maketools) and all is fine.

Since your view is a snapshot view you'll need to simply do a ct setcs -current.

Posted by at 10:39 PM | Permalink

• Got XAM ant build to work. Test build almost working
• Ported Build.pl for use in XAM

I assume you mean the state of XAM. Here's what I've done:

• Moved .../platform/L3/platform/src/com/hp/platform/fcas -> .../platform/XAM/server/src/com/hp/platform/fcas
• Moved .../platform/L3/platform/src/test/com/hp/platform/fcas -> .../platform/XAM/server/src/test/com/hp/platform/fcas
• Moved .../riss/W2/xam/client -> .../platform/XAM/client/c

By "moved" I mean that I copied those areas from the old place to the new place, added them to source control and rmnamed the old areas. This is as per Rational's recommendation for moving things in a UCM environment.

Next I attempted to build fcas in the new area. It became quickly apparent that we need to port over the buildTools directory with its build_common.xml if we wish to replicate the build environment of L3.

With Rahul's help I managed to build the server component in XAM. I have not tackled the client component nor test at this time. I've checked in the buildTools/build_common.xml and the build.xml under the server area.

Here's how you can build XAM:

• If necessary rebase your RISS15_xam substream or create view from RISS15_xam
• Change directory to .../platform/XAM/server/src/com/hp/platform/fcas
• type "ant -Dbase_dir=/vobs/platform/XAM -DviewBase=/vobs"

Note: viewBase would be different if you are using a snapshot view.

Since XAM will be separated from L3 the question is: How are dependencies handled? For example, this XAM "depends on" or "imports" code from L3's core and csfr. To address this we added:

<pathelement path="${viewBase}/platform/L3/code"/>

to the ext.classpath in build_common.xml even though the comment for this states:

<!--
    Class path element for Build. Don't add libraries here Libraries
    should go under devenv/buildenv/lib those libs will be
    automatically picked up by the following element
-->

You see we now have two different types of libraries, ext.classpath libraries that are built elsewhere and just deposited into devenv/buildenv/lib and our own libraries that are built in another component (in this case the L3 component).

Also, the above ${viewBase}/platform/L3/code assumes that that directory exists and contains compiled class files. It assume that L3 was built before XAM is built. This introduces the notion of dependencies between components.

Finally you'll note that we don't build from the /vobs/platform/XAM level, rather we descend down into the /vobs/platform/XAM/server/src/com/hp/platform/fcas level to do our ant build. Questions:

• Do we need a Build.pl to sit in /vobs/platform/XAM to build everything underneath it?
• Can't ant do recursive ants like make does recursive makes?

Posted by at 7:15 PM | Permalink

• Tracked down the problem with building on sons-sc-cc. Turns out Tornado-2.0 is slightly different

TIme Spent: 2 Hours

Here's what I see. Looking into why I'm getting this error I searched Tornado-2.0 for the definition of endEtherAddressForm and I find it in Tornado-2.0/host/resource/synopsis/drv.syn ~line 42. On sons-clearcase I see:

endEtherAddressForm() - form an Ethernet address into a packet

M_BLK_ID endEtherAddressForm
    (
    M_BLK_ID pMblk,    /* pointer to packet mBlk */
    M_BLK_ID pSrcAddr, /* pointer to source address */
    M_BLK_ID pDstAddr  /* pointer to destination address */
    )

However on sons-sc-cc I see:

endEtherAddressForm() - form an Ethernet address into a packet

M_BLK_ID endEtherAddressForm
    (
    M_BLK_ID pMblk,    /* pointer to packet mBlk */
    M_BLK_ID pSrcAddr, /* pointer to source address */
    M_BLK_ID pDstAddr, /* pointer to destination address */
    BOOL     bcastFlag /* use link-level broadcast? */
    )

Note the extra parm. Now I copied //sons-clearcase/Tools -> //sons-sc-cc/Tools but I know that Simon was doing something WRT WindRiver. Perhaps that changed Tools on sons-sc-cc? Here's what I tried:

• Renamed //sons-sc-cc/Tools/Tornado-2.0 -> //sons-sc-cc/Tools/Tornado-2.0.save
• Recopied //sons-clearcase/Tools/Tornado-2.0 -> //sons-sc-cc/Tools/Tornado-2.0
• Performed build - it worked! All of it! Not just olc!

I noticed that there is a Tornado-2.0 folder in the D drive, a Tornado-2.0 folder in D:\Tools and a Tornado-2.0+ in D:\Tools.

Posted by at 11:31 PM | Permalink

• Looked into build issues on sons-sc-cc
• Adjusted smake

Time Spent: 2 hours

This problem with drive letters being unavailable when one remotely logs in is one that I had battled with for a while in the past as history shows.

Unfortunately I don't have a great solution yet except to say that most people do not log into the server directly to do a build as you are doing. However there's a light at the end of the tunnel and that light is smake. Smake makes an optimization by setting TOOLS_DIR to the local disk drive instead of the T drive when building on sons-clearcase (and sons-cc for that matter as well as a sonsbld1 that we were once trying to set up). As a result I've changed smake to add sons-sc-cc to the list:

if [ $myhost = "sons-sc-cc" ]; then
  export TOOLS_ROOT=D:/Tools && nice make -e "$@"
elif [ $myhost = "sons-clearcase" ]; then
  export TOOLS_ROOT=E:/Tools && nice make -e "$@"
elif [ $myhost = "sons-cc" -o $myhost = "sonsbld1" ]; then
  export TOOLS_ROOT=C:/Tools && nice make -e "$@"
else
  nice make "$@"
fi

So if you use smake instead of just make on sons-sc-cc TOOLS_ROOT will be set to D:/Tools (where Tools are locally on sons-sc-cc) and then it will call make. This should solve this problem for local makes. For remove smakes (an smake you invoke from your desktop - you guys still do that right?) the following code changes fix that:

if [ $build_server = "sons-sc-cc" ]; then
  rsh -n $build_server "ct $(pwd) && export TOOLS_ROOT=D:/Tools
&& nice make -e $@"
elif [ $build_server = "sons-cc" -o $build_server = "sonsbld1" ]; then
  rsh -n $build_server "cd $(pwd) && export TOOLS_ROOT=C:/Tools
&& nice make -e $@"
else
  rsh -n $build_server "cd $(pwd) && export TOOLS_ROOT=E:/Tools
&& nice make -e $@"
fi

The added benefit of this approach is that builds a a lot faster since you are not loading the compiler over the network connection of the T drive (even though the T drive points back to the local machine in the case of sons-sc-cc).

Oh, another optimization I did on sons-sc-cc - I change the share cache to cache programs that are run. So for users running builds locally on there desktops (well not yet but when we get fully switched over) and they load say the C compiler from vxWorks, it will be cached on their local desktop and subsequent compilations should also run a lot faster!

I'm still not able to build, however. Here's a build from a clean view. Note that I removed the * from your /etc/passwd line szhu so I could use rsh to switch users from ccadmin -> szhu:

[ccadmin] sons-sc-cc:rsh -l szhu sons-sc-cc
No directory /us/SZhu!
Logging in with home = "/".
Last login: Tue Apr 18 11:06:10 from sc-szhu.salira.com
CYGWIN_NT-5.2 SONS-SC-CC 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin
WARNING: HOME directory did not exist! Logging in with HOME = /tmp

SZhu@SONS-SC-CC ~
$ id
uid=1143(SZhu) gid=513(Domain Users) groups=513(Domain Users)
  
SZhu@SONS-SC-CC ~
$ cd /dview/3.1.ccadmin/salira/neopon/build/
SZhu@SONS-SC-CC
/dview/3.1.ccadmin/salira/neopon/build
$ which smake
/view/official/Tools/bin/smake
SZhu@SONS-SC-CC
/dview/3.1.ccadmin/salira/neopon/build
$ smake
Build server: sons-sc-cc View: 3.1.ccadmin [local]
User: SZhu Dir: /dview/3.1.ccadmin/salira/neopon/build
Performing build locally on sons-sc-cc
sons-sc-cc:make 

                   +---------------------------+
                  /       S a l i r a         /|
                 /          NEOPON           / |
                /---------------------------/  |
                |             |O|           |  /
                | Building... |L|           | /
                |             |C|           |/
                +---------------------------+
-------------------------------------- (neopon/src/bsp) olc
[ASSEMBLE]     sysALib.s
[COMPILE C]    sysLib.c
[COMPILE C]    sysTffs.c
D:/TOols/Tornado-2.0/target/src/drv/tffs/tffsConfig.c: In function `tffsShowAll':
In file included from sysTffs.c:63:
D:/TOols/Tornado-2.0/target/src/drv/tffs/tffsConfig.c:205: warning: comparison between signed and unsigned
D:/TOols/Tornado-2.0/target/src/drv/tffs/tffsConfig.c: In function `tffsBootImagePut':
D:/TOols/Tornado-2.0/target/src/drv/tffs/tffsConfig.c:389: warning: comparison between signed and unsigned
[COMPILE C]    8260I2C.c
8260I2C.c: In function `i2cInit':
8260I2C.c:260: warning: cast from pointer to integer of different size
8260I2C.c:261: warning: cast from pointer to integer of different size
8260I2C.c:265: warning: cast from pointer to integer of different size
8260I2C.c:266: warning: cast from pointer to integer of different size
[COMPILE C]    Fpga_download.c
[COMPILE C]    usrConfig_st.c
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrTffs.c: In function `usrTffsLnConfig':
In file included from usrExtra.c:203,
                 from usrConfig_st.c:123:
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrTffs.c:154: warning: implicit declaration of function `dosFsMkfsOptionsSet'
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWdb.c: In function `vxTaskCreate':
In file included from usrExtra.c:236,
                 from usrConfig_st.c:123:
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWdb.c:581: warning: unused parameter `stackBase'
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWindview.c: In function `wvOn':
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWindview.c:269: warning: unused parameter `arg4'
[COMPILE C]    usrConfig.c
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrTffs.c: In function `usrTffsLnConfig':
In file included from usrExtra.c:203,
                 from usrConfig.c:123:
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrTffs.c:154: warning: implicit declaration of function `dosFsMkfsOptionsSet'
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWdb.c: In function `vxTaskCreate':
In file included from usrExtra.c:236,
                 from usrConfig.c:123:
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWdb.c:581: warning: unused parameter `stackBase'
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWindview.c: In function `wvOn':
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWindview.c:269: warning: unused parameter `arg4'
[COMPILE C]    fpd_end.c
fpd_end.c: In function `np3400EndAddressForm':
fpd_end.c:1247: too few arguments to function `endEtherAddressForm'
make[2]: *** [../../../build/olc/obj/fpd_end.o] Error 1
make[1]: *** [obj/bsp/olc.olist] Error 2
make: *** [olc/vxWorks_st.elf] Error 2

Regarding checkin and bug ID labeling, when you check into Clearcase using sons-clearcase you are saying that the trigger that is supposed to label the check in with the bug ID is failing to do so. I will look into this later too.

I'm not seeing this. In fact I'm seeing evidence saying it's working. The triggers log to /view/official/Tools/logs/triggers.log. Looking at the bottom of that file (tail -f works nicely) shows me:

CheckinPreop.pl: 4/18/2006@17:38: vdsouza: Checkin checks started for V:\vdsouza3.1\salira\neopon\src\gdb\gdb_csr_dump.c on rel_3.1 branch
CheckinPreop.pl: 4/18/2006@17:38: vdsouza: Successful precheckin of V:\vdsouza3.1\salira\neopon\src\gdb\gdb_csr_dump.c on rel_3.1 branch with bug ID
CheckinPostop.pl: 4/18/2006@17:38: vdsouza: Created label for BUGS200006029
CheckinPostop.pl: 4/18/2006@17:38: vdsouza: Attached label BUGS200006029 to V:\vdsouza3.1\salira\neopon\src\gdb\gdb_csr_dump.c
CheckinPostop.pl: 4/18/2006@17:38: vdsouza: Successful postcheckin of V:\vdsouza3.1\salira\neopon\src\gdb\gdb_csr_dump.c on rel_3.1 branch with bug ID BUGS200006029

And indeed gdb_csr_dump.c has a label of BUGS200006029:

[ccadmin] sons-clearcase:files4bug 6029
Files involved in bug ID BUGS200006029:
        /salira/neopon/src/gdb/main/rel_2.0/hainan_integration/rel_2.2/rel_3/1/gdb_csr_dump.c

1 file involved in bug ID BUGS200006029

Do you have an example of where this is failing?

Posted by at 7:45 PM | Permalink

• Researched problem with Tony and Bingchun's machines WRT cqd/cqc
• Attempted to fix problems with Clearquest Desktop Installation

Time Spent: 2 Hours

Here's the progress I made last night:

• Determined that part of the problem with Tony Liu's machine and Bingchun's machines was due to the fact that Clearquest was not even installed on their machines. Installed Clearquest 2002.05.00 on Tony's machine - Bingchun installed Clearquest on his own machine.
• Despite the above cqc was still unable to connect to cqd. Determined that a call to gethostbyaddr in cqd was failing for some still unknown reason. The subsequent called to get the host's name would fail in Perl. Not sure why that causes the server to hang, however getting the hostname is only really so that cqd could report nice hostnames. So instead I changed the code to do:

# Service this client
my $hostinfo = gethostbyaddr ($cqclient->peeraddr);
my $host = !defined $hostinfo ? "Unknown" : $hostinfo->name || $cqclient->peerhost;
  

So if the hostinfo is not attainable with the gethostbyaddr call we'll simply use the host of "unknown". This means that Tony and Bingchun should be able to at least checkin their files.

• Fixed shortcut in //sons-sc-cc/Rational/Clearquest to be named "Install Clearquest" so people can update to the new version of Clearquest.
• Attempted to update the machine adefaria with the new version of Clearquest. Need to uninstall the old version of Clearquest first. Bummer.
• Uninstalled Clearquest on adefaria and installed new version of Clearquest. I was able to make a connection to the new Clearquest server (sons-sc-cc) but I was unable to make a connection to the old and current production version of Clearquest on sons-clearcase!
• I was unable to make a connection to the old version of Clearquest on sons-clearcase on either of Tony's or Bingchun's machines. To summarize, I installed CQ Version 2003.06.00 on adefaria and CQ Version 2002.05.00 on Tony's and Bingchun's machines but none of these were able to establish a CQ connection (via the Clearquest Maintenance Tool) to the current production Clearquest SQL Anywhere database on sons-clearcase! For Clearquest, people in China usually use the web interface anyway. I need to talk to Rational about why I am unable to connect to the old, production Clearquest database.
• Uninstalled CQ 2003.06.00 on adefaria and reinstalled CQ 2002.05.00. Alas even after reinstalling CQ Version 2002.05.00 I still can't create a connection to sons-clearcase on adefaria! Must be something I'm doing wrong but I'm too tired to figure it out.
• I was unable to look into rsh/telnet issues and build issues that Simon reported.
  

Posted by at 7:38 PM | Permalink

• Studying Ant

Recently I started looking into Ant more seriously. Seems like it'd be a good thing to do for my career. But I must tell you, I'm not quite convinced that Ant's a solution to anything except to say that it's probably a more comfortable make for people who think in terms of Java only.

Here's some quotes from the main Ant page:

Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles.

Make wrinkles?!? What wrinkles? Wrinkles are the sign of age and wisedom. Just because you don't understand it do not play it off as if it's bad.

Why another build tool when there is already make, gnumake, nmake, jam, and others? Because all those tools have limitations that Ant's original author couldn't live with when developing software across multiple platforms. Make-like tools are inherently shell-based -- they evaluate a set of dependencies, then execute commands not unlike what you would issue in a shell. This means that you can easily extend these tools by using or writing any program for the OS that you are working on. However, this also means that you limit yourself to the OS, or at least the OS type such as Unix, that you are working on.

That's true. But no more true than the fact that if you want to run make on any other system you also need to have make available on that other system! I take the above to mean that you have a tendency to extend your build to what is natural on the OS in question and thus you start using Unix shell commands and the like. OK. However where, in the scheme of things, can one not run Unix shell commands now a days? Surely Unix and Linux have that covered, and Mac OS/X is basically Unix under the hood too. What you mean Windows? Well Cygwin also has that pretty much covered. So then, why avoid a well known, well understood and time test utilitiy such as make?

Makefiles are inherently evil as well. Anybody who has worked on them for any time has run into the dreaded tab problem. "Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times. Tools like Jam took care of this to a great degree, but still have yet another format to use and remember.

Ant is different. Instead of a model where it is extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, calling out a target tree where various tasks get executed. Each task is run by an object that implements a particular Task interface.

Which I guess would be find if you are better at writing Java classes instead of shell commands or other scripts. And why is it that all new, improved, better things must incorporate whatever is in vogue at the time? Do we really need XML files instead of just straightforward ASCII text? And must everything be an object?

Granted, this removes some of the expressive power that is inherent by being able to construct a shell command such as `find . -name foo -exec rm {}`, but it gives you the ability to be cross platform -- to work anywhere and everywhere. And hey, if you really need to execute a shell command, Ant has an task that allows different commands to be executed based on the OS that it is executing on.

Ant is only as cross platform as the platforms that ant has been ported to! With things like Cygwin there no need to throw the baby out with the bath water over a few misplaced tabs. Still I guess ant has it's place and I'm sure it's comfortable for Java developers. Sure having an object oriented design probably isn't bad but now people need to learn yet another language - Java - even if they are not developing in Java. And they need to learn XML, etc. And you don't only lose the power and expressiveness of the shell but it seems to me you just lost support for just about all the other langauges as well. AFAICT I see no built in support for Ada, FORTRAN, Pascal, etc.

Posted by at 5:06 PM | Permalink

• Managed to migrate the production user database
• Clearquest desktop users need to upgrade their software. Meantime they can use the web interface
• Verified cqd and triggers work
• Documented how to switch a desktop to the new server
• Documented how to build on the new server

Time Spent: 4 Hours

Production User Database Migrated!

More progress in this area.

I decided to try to use the Sybase Central tool to see if I could verify or otherwise fix this potentially bad database. I also looked at running Chkdisk as the eventlog was reporting some bad sectors on the disk. Unfortunately chkdisk cannot fully check the disk since the database is on the C drive and the C drive is currently busy. Normally you just set a flag and chkdisk will run after next boot. But such a chkdisk will take a long time on a big disk.

Meantime in Sybase Central I decide to do fresh backups of the databases which seem to go OK. These backup databases look no different really than the regular databases so I run validate on the backup database. Hmmm.... Doesn't seem to have any errors. So I tried the installutil copyuserdb to copy the backup database as if is was the real production database to the new server. Hmmm.... That worked!

Next I had to go into Clearquest Maintenance Tool and select Schema Respository: Upgrade: Selected Connection and upgrade the production user database. That worked!

I checked the Clearquest web (http://sons-sc-cc/cqweb/login) and the new database is indeed there and working!

Clearquest Desktop Clients Need to Upgrade

Problem: Clearquest 2002.05.00 desktop clients cannot access this new database!

I tried creating a connection profile to this new database and then importing it on the old server running 2002.05.00.This did not work! Later I read in the Rational Suite Migration Guide:

Your network environement can contain misxed versions of ClearCase and ClearQuest clients (where some clients are at v2003 and some clients are at ealier versions) if these products are in a standalone environment, that is:

....

If your vendor database is SQL Anywhere, you do not plan to upgrade to SQL Anywhere 8.0 until all ClearQuest clients and databases have been upgraded to version 2003.

So we'll have to upgrade desktop clients to 2003.06.00! Luckily people can use the Clearquest Web Client...

Clearquest Daemon Works with Minor Tweaks

Checked that cqd and cqc work with the new server. All that need to be changed is to change the default server from sons-clearcase -> sons-sc-cc in cqc.pm.

Checked and Triggers Work in New Environment

I was able to check to see that the triggers function in the new environment.

Switching Your Desktop to the New Server

Use the following steps switch your desktop to the new server:

1. Stop all Clearcase activity. Close any Clearcase Explorer windows and any shells in Clearcase views.
2. In a Cygwin shell type ct umount -all to unmount all vobs.
3. Go to Control Panel: Clearcase
4. Click on the Services tab then Stop Clearcase
5. Click OK to the dialog saying Clearcase has stopped
6. Click OK to close the Clearcase Control Panel Applet
7. Start the Clearcase Control Panel again
8. On the registry tag, change the registry server to sons-sc-cc
9. Click OK to close the Clearcase Control Panel again
10. On the Registry tab click the drop down arrow for Windows Region. You should see the new SC region. Select it.
11. Click on Apply
12. Click on the Services Startup tab and then Start Clearcase
13. Close the Clearcase Control Panel
14. Start a Cygwin shell and type ct hostinfo -l. You should see something like:
    
    

    [ccadmin] adefaria:ct hostinfo -l
    Client: adefaria
      Product: ClearCase 2002.05.00+
      Operating system: Windows NT 5.1 (build 2600) Service Pack 2
      Hardware type: Pentium
      Registry host: sons-sc-cc
      Registry region: SC
      License host: sons-clearcase
    

    As you can see we are now pointing to the sons-sc-cc registry host and the SC region. Sons-clearcase is still the license server at this time. Type ct lsview and you should see:

    [ccadmin] adefaria:ct lsview
      official             \\sons-sc-cc\Views\SALIRA\ccadmin\official.vws
      3.1.ccadmin     \\sons-sc-cc\Views\SALIRA\ccadmin\3.1.ccadmin.vws
      szhu_view_2     \\sons-sc-cc\Views\SALIRA\szhu\szhu_view_2.vws
        

    A noticeably smaller list of views that are on sons-sc-cc in the SC region

Follow a similar set of steps to switch back to the old registry server (sons-clearcase) and region (US). No reboots required (provided you properly stop Clearcase and do things like get out of views and umount vobs).

Attempting an Official Build on sons-sc-cc

This procedure can be done either by following the procedure above to switch your desktop to the new server or simply use rsh/telnet to log into sons-sc-cc. Once there:

1. Make user that the 3.1.ccadmin view is started
   

   $ ct startview 3.1.ccadmin
   

2. Make sure the salira vob is mounted:
   
   

   $ ct mount \\salira
   

3. Change directory to the build area:
   
   

   $ cd /dview/3.1.ccadmin/salira/neopon/build
   

4. Type make:
   

   $ make
   

Posted by at 6:55 PM | Permalink

Attempting to transfer databases using MS Access

OK, trying this methodology:

• Used installutil copyschemarepo command to copy schema.db -> schema.mdb
• Moved schema.mdb to new server
• Used installutil copyuserdb command to copy salira_test.db -> test.db.
• Moved test.db to new server
• Tried several times to use installutil command to copy salira_bugs.db (the production database) -> bugs2.db. System aborted several times. Not sure if this is due to bad disk blocks or not. This is a major problem as this is the data we care about.

Back on the new server:

• If I do Connection: New and point to the schema.mdb file it wants to overwrite it! Instead I did File: Import Profile of a profile of the old databases. Of course these say SQL_ANYWHERE. I change this to MS_ACCESS and point to the schema.mdb file and this seems to work.
• Attempt to do Schema Repository: Move. In doing so I set the Physical Database Name by browsing to the folder via the ellipsis button. This leaves me with D:\Clearquest\schema.db. Clicking on Finish give ms:
  

  The filename you have specified is not a Share. If other users will need access to this database, you should browse through "Network Neighborhood" to place is in a share. Continue with this name?
  

  I select No because I do want other users to be able to access this database. Next I change the D:\Clearquest\salira.db -> \\sons-sc-cc\Clearquest\schema.db and click Finish. At this point I get a error dialog stating that it was "Unable to connect to the database server". After much scratching of the head I realize that I should use D:\Clearquest\schema.db, ignore the warning, then go back in and set the Physical Database Name to \\sons-sc-cc\Clearquest\schema.db.
  
  Oh, a side issue: After failing using a Physical Database Name of \\sons-sc-cc\Clearquest\schema.db the Rational Clearquest Maintenance Tool still creates a schema.db file. If you go Back and correct the Physical Database Name to a local path and click Finish you'll get a database I/O error. Turns out you have to remove this schema.db file first. These two (what else could I call them but) BUGS caused me to lose many hours of sleep.
  
  Managed to move the schema.mdb -> schema.db.
• Switching to the Clearquest Designer now to Database: Update User Database Properties. As I only have the test.mdb file to convert I change the user database properties for the test database.
• Now I select Database: Move User Database to move the test user database to SQL_ANYWHERE

At this point I'd like to run Clearquest Designer and do Test Work so I can at at least verify that I can access the converted to SQL_ANYWHERE test.db. Unfortunately there is a checked out version of the schema in the schema database that I copied over and I'm not the owner of that checked out schema. And I can't login as that user.

By chance I tried Schema Repository: Upgrade: Selected connection in the Clearquest Maintenance Tool and in stepping through those dialog boxes it say "The schema repository that you want to upgrade has checked-out schemas. If you continue the upgrade process, the checked out schema versions cannot be upgraded and will be deleted from the system". I continue onward and manage to "upgrade" the schema and test database. I proceed into Clearquest Designer and manage to Test Work and viola! I got it up. I am nothing if not tenacious!

Total Time: 2 hours

Posted by at 10:50 PM | Permalink

• Fixed bug with saving test.log where I was attempting to save it before I returned from the subroutine. We now save the test.log even if test suite is successful. This is good because continuous building reuses the view area thus destroying any test.logs created before.
• Fixed bug in build::CheckForShutdown where we called LogEvent without a $log parameter. This caused CheckForShutdown to abort the build while in CIT daemon mode and thus we didn't see the error. It also left the shutdown file thus subsequent starts merely shutdown (actually aborted) until one manually removed the shutdown file. Bad bug! Bad, bad!
• Looking into why the test suite works when called at the Build.pl level but fails when called from the streamBuild.pl level.

Posted by at 12:15 PM | Permalink

• Installed SQL Anywhere 8.0.3 Patch to fix problem with Services folder not appearing in Sybase Central
• Spent time trying to figure out how to get a service configured. Eventually figured out that I need to specify -n <machine> as part of the parms or starting the service would just hang
• Instructions given from Rational spoke of converting databases on a single server. This is not what we are doing there. Tried various things in an attempt to extend the directions to two servers and get the installutil command to run. Nothing was working.
• Scoured the Rational documents and the net for "preparedbforupgrade" - turned up little except some guys personal web site talking about how the Rational Suite - Upgrade Guide describes the upgrade procedure with two servers and here's the single server procedure. That's nice, and it's pretty much the exact technote that the Rational support engineer pointed me to. However where's the double server procedure!
• Scoured the Rational site, this time for Rational Suite - Upgrade Guide. Found it! It was a in a pdf file! Apparently the Rational site search engine doesn't search inside pdf files. They should take a lesson from Google! Also searched the system for this pdf file (rs_upgrade.pdf) and it was not on the system. Now why isn't it part of what gets installed?
• Started doing the steps for converting the database as described in the Rational Suite - Upgrade Guide. See below for more.

Time Spent: 4 hours

Still issues with SQL Anywhere upgrade

According to the Rational Suite - Upgrade Guide I need to import the connection profile from the SQL Anywhere 5.0 server then update it to add on the new SERVER_VER connection option (I believe I need to specify SERVER_VER=8.0.3 since I've now patched to 8.0.3) then save that connection profile. If I change the database server name to the new name but leave the Physical Database Name pointing to the old server then I get an error. If I change the database server name and point the Physical Database Name to a copy of the schema.db on the new server I can't connect either. If I leave those pointing to the old server and only add on the SERVER_VER parm then the connection updates. But now access to Clearquest fails on the old server complaining that SERVER_VER is invalid! How are you supposed to do this?!? Step by step instructions would be great!

Even if I were to be able to get the above done I would hesitant to perform the next step because it describes using the Clearquest Maintainance Tool to move the schema and user databases!

Move your schema repository. In the ClearQuest Maintenance Tool, in the Existing Connections area, select the connection to your existing SQL Anywhere 5.0 databases, then click Schema Repository > Move. Enter database information for a new database under your SQL Anywhere 8.0 server. For example, enter a different filename in the same directory as the existing database. Click Finish.

I don't want to move databases - I want to simply copy them. Moving them would mean that current production would have to halt until I got it back up and running on the new server.

Posted by at 12:37 AM | Permalink

• Changed the build process to save the test logfile
• Changed the build_status to use an iframe for the continuous log file

Posted by at 6:49 PM | Permalink

• Attempted to migrate Clearquest databases to new server. I was unable to. I've opened up a PMR with IBM Rational #8552849R and expect to get email from them tomorrow.
• Attempting to switch the machine adefaria over to this newly created registry server (sons-sc-cc). Decided to reboot the machine. It never came back up! If you can boot this machine that would be great. You might need to go into the Clearcase Control Panel and set the registry server back to sons-clearcase and set the region to US. It might require a reboot to be effective. Why, when I rebooted it, it failed to come back up?

Time Spent: 4 hours

Migrating databases to new SQLAnywhere 8.x

Spent most of the day banging against SQL Anywhere. We need to migrate the databases (both the schema.db and the salira_bugs.db) to the new server. With the new server comes new DBMS software (Sorry but SQL Anywhere 5.5.05 which is what you have on sons-clearcase is being sunsetted anyway).

Now I've done some extensive Clearquest work over at Broadcom it was all MS SQL based in the back end.

The first problem I have is that there is not service for SQL Anywhere like there used to be over on sons-clearcase. I managed to find C:\Program Files\Rational\SQLAnywhere8\win32\dbeng8.exe and dbsrv8.exe and that appears to be the process to start, there still isn't any automatically starting service for SQL Anywhere 8. That plus when run it prompts with a dialog box that queries about the database to use. I was always under the impression that a DBMS server just runs for any and all databases on the machine. I can just specify the server and leave the database blank but other times when running Sybase Central it complains that it can't start the DB server.

I thought that I could simply use Sybase Central to backup the databases on sons-clearcase then use the restore function of Sybase Central on sons-sc-cc. There are also options like Migrate Database, etc. to deal with differences in databases between old and new versions of SQL Anywhere. All of these had problems for me...

Backup/Restore

I backed up the salira_bugs.db file over to \\sons-sc-cc\Clearquest\backup\salira_bugs.db. Next I attempted to restore it on sons-sc-cc I get "Unable to start database server".

Connect to backup database

When I attempt to simply connect to that db I get:

You are attempting to connect to a version 5.5.03 database running on a version 8.0.2-3601 server. In order for the Sybase Central to use this database, the database must be unloaded and reloaded into a new database (Sybase Central only supports version 7.0.0 and later database). The Unload Database wizard can step you through this process, after which Sybase Central will diconnect from this database.

Do you want to unload and reload this database? (If not, Sybase Central will disconnect from this database now.)

If I step through this wizard I eventually get:

java.lang.UnsatisfiedLinkError: unloadDatabase
Could not unload the database 'salira_bugs'.

Migrate Database

If I attempt to Migrate Database I get a message saying "You must be connected to the database to which you want to migrate" which, of course, I can't...

Creating and Erase Database

I have not managed to create a database through Sybase Central (but I have been able to create it through Clearquest Maintainance Tool and the Clearquest Designer - see below). When I try I get: Unable to start database server.

For databases created via Clearquest tools I cannot erase them using Erase database. Instead I get the same thing: Unable to start database server. So far when I need to delete a database I merely remove the databse files themselves.

I can create a schema database and even user databases through the Clearcase Maintainance Tool and Clearquest Designer respectively. But we don't want a new schema nor empty user databases - we want to migrate the old scheme that has our modifications and we want to migrate our old database!

Moving Databases

There's also an option to move a database from one server to another. Now I don't want to move databases right yet - I want to copy them. However this move seems to copy the database and then lock the original database. So I tried it out on the test2 database. Effectively you go into the Clearquest Designer on sons-clearcase and then select Database: Move Database then go through the dialog box specifying that you want to move the database over to sons-sc-cc. That works and test2.db does appear over on sons-sc-cc. But when I attempt to connect to it Sybase Central again goes through the unload/load procedure which fails the same way as described above.

Posted by at 7:07 PM | Permalink

• Upgraded sons-sc-cc to be a registry server
• Removed old replicas in the SC region on sons-clearcase
• Rereplicated the vobs from sons-clearcase. Note sons-clearcase aborted a few times when doing this. I noticed some disk block errors in the Event Viewer. Good thing you have a new system with RAID!
• Cleaned up some more of lost+found
• Looked into the scripts to evaluate the impact of the server switch. There will be some changes but by and large they will be minimal.
• Both Clearcase Web and Clearquest Web are up and functional.

Time Spent: 4 hours

Posted by at 7:47 PM | Permalink

Work Performed

• Reinstalled Clearcase with Multisite this time as a server on sons-sc-cc
• Changed certain links to point to sons-sc-cc instead of sons-clearcase
• Created new site_parms.SC
• Replicated salira, salira2, Tools and hardware vobs. Made sure the synchronization is working. Even China now recognizes the new SantaClara replica.
• Created new SC region on sons-clearcase as that's currently our registry server until we switch over
• Cleaned up a little bit of lost+found. Somebody should be doing this (see below).
• Added triggers

Work to be done

(List not exhaustive nor necessarily in sequence)

• Move registry service from sons-clearcase -> sons-sc-cc
• Move license -> sons-sc-cc
• Perform successful build on sons-sc-cc
• Set up test client and point it ot the new registry server to test access, checkin/out and build
• Set up ctmerge jobs
• Set up Clearquest on sons-sc-cc
• Migrate Clearquest database -> sons-sc-cc
• Set up cqd on sons-sc-cc
• Set up Clearcase sitedefs.dat for client installations
• Resolve problem with albd_server process not starting on boot

Time spent: 5 hours

lost+found

The lost+found directory in vobs is there to catch elements that would have otherwise disappeared as a result of a Clearcase action. For example, you create a new directory and put a file in it. Then you decide you don't want that directory so your rmname it. Where does the file under it go? Answer: lost+found. This gives you a chance to recover it should you need to and know where to get it. But most often users either don't want to recover it or simply recreate it. This creates lost+found junk.

Posted by at 1:30 AM | Permalink

After speaking to Ron and getting the remote access working I did a few more things last night I:

• Installed Clearcase. After Ron had changed the name of the machine to sons-sc-cc all was fine with the Clearcase installation. And multitool (Multisite's cleartool) is even there!
• Installed the Clearcase patch so you're totally up to date.
• Installed Clearquest
• Copied over \\sons-clearcase\Tools -> \\sons-sc-cc\Tools
• Installed and configured Cygwin. This took a while to get all the config stuff there, etc. Created a \\sons-sc-cc\Tools\Cygwin local package area. Sons-sc-cc has the latest Cygwin now.
• Created Clearcase stgloc's for Vobs and Views
• Created empty shell vobs for salira, salira2, tools and hardware. These will be where I Multisite to.
• Defragged drives on new machine.
• Made sure sons-sc-cc was up to date with WindowsUpdate.

Tonight I intend to create the initial replica packets for the vobs then ship them over to sons-sc-cc and setup Multisite syncing. I will first Multisite a vob like Tools or perhaps hardware just to go through the procedure and get the syncing jobs set up. Then I will do both salira and salira2.

There's probably still loose ends that need to be looked at but my plan is basically to be able to build in salira (I don't know how to build in salira2!) using only sons-sc-cc.

At that point we could create some views there for say Simon and teach him how to switch regions to the new SC region. Then he'd be working with the new vob server. He could build and otherwise check it out.

Time Spent: 3 Hours

Posted by at 5:35 PM | Permalink