defaria.com/blogs/Status/archives/2005_10.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml" id="sixapart-standard">
   4 <head>
   5    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6    <meta name="generator" content="Movable Type 5.2.3" />
   7
   8    <link rel="stylesheet" href="http://defaria.com/blogs/Status/styles-site.css" type="text/css" />
   9    <link rel="alternate" type="application/atom+xml" title="Atom" href="http://defaria.com/blogs/Status/atom.xml" />
  10    <link rel="alternate" type="application/rss+xml" title="RSS 2.0" href="http://defaria.com/blogs/Status/index.xml"$>" />
  11
  12    <title>Status for Andrew DeFaria: October 2005 Archives</title>
  13
  14    <link rel="start" href="http://defaria.com/blogs/Status/" title="Home" />
  15    <link rel="prev" href="http://defaria.com/blogs/Status/archives/2005_09.html" title="September 2005" />
  16    <link rel="next" href="http://defaria.com/blogs/Status/archives/2005_11.html" title="November 2005" />
  17 </head>
  18 <body class="layout-one-column">
  19    <div id="container">
  20       <div id="container-inner" class="pkg">
  21
  22          <div id="banner">
  23             <div id="banner-inner" class="pkg">
  24                <h1 id="banner-header"><a href="http://defaria.com/blogs/Status/" accesskey="1">Status for Andrew DeFaria</a></h1>
  25                <h2 id="banner-description">Searchable status reports and work log</h2>
  26             </div>
  27          </div>
  28
  29          <div id="pagebody">
  30             <div id="pagebody-inner" class="pkg">
  31                <div id="alpha">
  32                   <div id="alpha-inner" class="pkg">
  33
  34                      <p class="content-nav">
  35                         <a href="http://defaria.com/blogs/Status/archives/2005_09.html">&laquo; September 2005</a> |
  36                         <a href="http://defaria.com/blogs/Status/">Main</a>
  37                         | <a href="http://defaria.com/blogs/Status/archives/2005_11.html">November 2005 &raquo;</a>
  38                      </p>
  39
  40
  41
  42
  43                      <h2 class="date-header">October 31, 2005</h2>
  44                      <a id="a000463"></a>
  45                      <div class="entry" id="entry-463">
  46                         <h3 class="entry-header">PQA Issues/CQ 2002.05 setup</h3>
  47                         <div class="entry-content">
  48                            <div class="entry-body">
  49                               <ul>
  50   <li>Documented <a href="http://intranet.broadcom.com/~adefaria/Clearquest/PQAIssues.php">PQA issues</a>
  51
  52   <li>Installed old Clearquest on pcsjca-ccrmt03</li>
  53
  54   <li>Investigated more about the DST Clearcase issue</li>
  55 </ul>
  56
  57                               <p class="entry-footer">
  58                                  <span class="post-footers">Posted by  at  5:15 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000463.html">Permalink</a>
  59
  60
  61                               </p>
  62                            </div>
  63                         </div>
  64                      </div>
  65
  66
  67
  68                      <h2 class="date-header">October 28, 2005</h2>
  69                      <a id="a000461"></a>
  70                      <div class="entry" id="entry-461">
  71                         <h3 class="entry-header">PQA: URL Link Issue</h3>
  72                         <div class="entry-content">
  73                            <div class="entry-body">
  74                               <ul>
  75   <li>Documented new URL format</li>
  76
  77   <li>Investigated the feasibility of accommodating a mapping of old URL link with old ID -> new URL</li>
  78 </ul>
  79
  80                               <h2>Clearquest Web URLs</h2>
  81
  82 <p>With the old Clearquest ASP based Web Platform the following URL would direct you directly to the defected specified in &lt;id&gt;:</p>
  83
  84 <blockquote>
  85  http://&lt;<i>server</i>&gt;/cqweb/url/default.asp?id=&lt;<i>id</i>&gt;
  86 </blockquote>
  87
  88 <p>This link was often set in email messages generated by action hooks in the schema (e.g. when commitmentLevel's value changed).</p>
  89
  90 <p>With the new Clearquest Java based Web Platform this URL has changed. The new format is a lot longer due to the fact that it is also more flexible:</p>
  91
  92 <blockquote>
  93 http://&lt;<i>Server</i>&gt;/cqweb/main?command=GenerateMainFrame&service=CQ&schema=&lt;<i>DBSETName</i>&gt;&contextid=&lt;<i>DBName</i>&gt;&entityDefName=&lt;<i>entityDefName</i>&lt;&entityID=&gt;<i>entityID</i>&gt;
  94 </blockquote>
  95
  96 <p>Where:</p>
  97
  98 <blockquote>
  99 <i>Server</i>: Name of web server (e.g. extranet.broadcom.com)<br>
 100 <i>DBSETName</i>: Connection ID (e.g. 2005.02.00)<br>
 101 <i>DBName</i>: Name of database (e.g. Cont)<br>
 102 <i>entityDefName</i>: Name of entity record (e.g. Defect)<br>
 103 <i>entityID</i>: ID to display<br>
 104 </blockquote>
 105
 106 <p>For example:
 107
 108 <blockquote>
 109 </p>http://p4test/cqweb/main?command=GenerateMainFrame&service=CQ&schema=2005.02.00&contextid=Cont&entityDefName=Defect&entityID=Cont00012352
 110 </blockquote>
 111
 112 <p>The action hooks in the schema need to change to generate this new URL if the new Clearquest Java based Web Platform is to be used. This will fix all future emails that are generated with such a link.</p>
 113
 114 <p>We cannot fix past emails that already exist in people's mail folders. A thought was given to the idea of configuring the web server such that it would allow the old links to work. I tried, believe me, to see if this was relatively doable. It is not.</p>
 115
 116 <p>Here's what I thought of doing:</p>
 117
 118 <ol>
 119   <li>Configure RWP so that http://<server>/cqweb/url resolves to another place.</li>
 120
 121   <li>Configure RWP so that .asp files are considered cqperl scripts. Note RWP is Apache based with Java Tomcat Servelets. I do not think I can configure this RWP to handle true, bona fide ASP pages. Besides I know very little about ASP.</li>
 122
 123   <li>In this place write a default.asp that is actually a cqperl script. This script would take the id= parameter, look up the id under old_id then generate a redirect in the form of the new URL substituting the new ID.</li>
 124 </ol>
 125
 126 <p>Of course, all of this is non standard, thus unsupported by Rational. Additional, although I managed to do #1 and I'm quite sure I could do #3, I got stuck at #2. The problem is that Rational also doesn't support any Perl cgi stuff from RWP. In fact RWP is for Rational's Web Applications only - they don't even support you running static web pages/sites through RWP. So there is no mod_perl.so for me to load into Apache, let alone a mod_perl.so that supports cqperl -which is a non-standard Perl that only Rational supports.</p>
 127
 128 <p>And with this I think we just need to give up the hope of supporting old URL links to old ID numbers, fix it so that new URL links are of proper format and perhaps implement a simply query for "Look up by Old ID" for the customers.</p>
 129
 130                               <p class="entry-footer">
 131                                  <span class="post-footers">Posted by  at  2:00 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000461.html">Permalink</a>
 132
 133
 134                               </p>
 135                            </div>
 136                         </div>
 137                      </div>
 138
 139
 140
 141                      <h2 class="date-header">October 27, 2005</h2>
 142                      <a id="a000462"></a>
 143                      <div class="entry" id="entry-462">
 144                         <h3 class="entry-header">PQA: LDAP</h3>
 145                         <div class="entry-content">
 146                            <div class="entry-body">
 147                               <ul>
 148   <li>Worked on trying to test out LDAP Authentication</li>
 149 </ul>
 150
 151                               <p class="entry-footer">
 152                                  <span class="post-footers">Posted by  at  2:16 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000462.html">Permalink</a>
 153
 154
 155                               </p>
 156                            </div>
 157                         </div>
 158                      </div>
 159
 160
 161
 162                      <h2 class="date-header">October 26, 2005</h2>
 163                      <a id="a000460"></a>
 164                      <div class="entry" id="entry-460">
 165                         <h3 class="entry-header">PQA: More issues</h3>
 166                         <div class="entry-content">
 167                            <div class="entry-body">
 168                               <ul>
 169   <li>Investigating PQA issue regarding email links</li>
 170
 171   <li>Implementing cleanup of Dynamic Lists</li>
 172
 173   <li>Handed off test DB backup to Vinh</li>
 174
 175   <li>Investigated data conversion problems</li>
 176 </ul>
 177
 178                               <h2>PQA: Remaining Issues</h2>
 179
 180 <p>The following issues came up at this meeting:</p>
 181
 182 <ol>
 183   <li>Requirement to support old style Email Link's (See below)</li>
 184
 185   <li>Update Production Web Server to latest Clearquest version (See below)</li>
 186
 187   <li>Remaining data conversion issues (Emailed Vinh asking for details)</li>
 188
 189   <li>Dynamic List cleanup (Emailed Vinh asking for updates)</li>
 190
 191   <li>Test DB hand off (Emailed Vinh pointing to backups of my converted database for him to test)</li>
 192 </ol>
 193
 194 <p>Vinh provided an example: http://extranet.broadcom.com/cqweb/url/default.asp?id=Prod00014218. There are several problems with this. First the default.asp indicates an IIS server and an ASP web application. The new version of RWP is not IIS based rather it is Apache based. I cannot find a default.asp in RWP at all. Thus the above style link will not work.</p>
 195
 196 <p>Vinh says that he generates through hooks in CQ. I suspect what is happening is this: When a defect changes state action hooks kick in and determine it's time to send email to notify the appropriate people that a change in state has happened. At this time Vinh's hooks change/generate these links. As such Vinh needs to change his hooks to generate new URLs that conform to the new Clearquest software. One question I have is how did Vinh come up with http://<servername>/url/default.asp?id=<ID> as a syntactical template meaning "Show this specific defect"? I cannot find where this is documented.</p>
 197
 198 <p>I tried http://p4test/url/default.asp?id=<ID> on p4test and that doesn't work. Perhaps this is just an issue of figuring out what the correct URL template is and changing the hook. The hook could also be modified to perhaps add links for http://<server>/<path>/<script>?old_id=<ID> if that is possible. This would then take care of all future emailed URL's. I'm not sure how to account for old emails that may have now invalid links.</p>
 199
 200 <p>I did see that the new Web interface has a Email Defect link which produces URLs of the form: http://p4test/cqweb/main?command=GenerateMainFrame&service=CQ&schema=2005.02.00&contextid=Cont&entityID=33580034&entityDefName=Defect</p>
 201
 202 <p>(Decidedly not user friendly).</p>
 203
 204 <p>The question remains whether or not to go with upgrading the production server to the newest version of Clearquest so we can get the new version of Clearquest Web. It is a different web interface. Ray is looking into getting another machine so we can have both new and old versions of Clearquest Web. One issue is that if we do go to the merged database and new Clearquest Web and run for a while then decide there is some critical flaw, going back to the old Web server will also mean going back to the old databases and losing any work done during the time we were on the new setup.</p>
 205
 206 <h2>Data Conversion Problems</h2>
 207
 208 <p>Vinh wrote:</p>
 209
 210 <blockquote type=cite>
 211   <p>by compare with Prod0009710, not match values for these</p>
 212
 213   <ol>
 214     <li>SW Version</li>
 215
 216     <li>Time From Resolve To Verify</li>
 217
 218     <li>Closed Date</li>
 219   </ol>
 220 </blockquote>
 221
 222 <p># 1 was due to a bug - I fixed this.</p>
 223
 224 <p># 2 and 3 are due to the fact that these fields are set to readonly. The odd thing is that they do not appear to have any good. The question then is how do they obtain values? My guess is that these values are fielded in by some other sort of hook script at some time. My workaround is to add these to the list of fields that must be toggled to optional in order for the conversion to work and toggled back after the conversion. My fear is what other fields are like these?</p>
 225
 226 <p>The list of readonly fields in the schema are:</p>
 227
 228 <ol>
 229   <li>Fixed_In_Project</li>
 230
 231   <li>Close_Date (Mentioned above)</li>
 232
 233   <li>Submit_Date (Already toggled to optional)</li>
 234
 235   <li>Submitter (Already toggled to optional)</li>
 236
 237   <li>Notes_Log</li>
 238
 239   <li>old_id (Already toggled to optional)</li>
 240
 241   <li>TimeFromSubmitToVerify</li>
 242
 243   <li>TimeToVerify (Time From Resolve To Verify mentioned above)</li>
 244
 245   <li>Audit_Log (Already toggled to optional)</li>
 246 </ol>
 247
 248 <p>My guess here is that the other fields (#1, 5 & 7 above) are also empty. The solution therefore it to toggle all readonly fields in the list above to optional before performing the merge.</p>
 249
 250                               <p class="entry-footer">
 251                                  <span class="post-footers">Posted by  at  4:14 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000460.html">Permalink</a>
 252
 253
 254                               </p>
 255                            </div>
 256                         </div>
 257                      </div>
 258
 259
 260
 261                      <h2 class="date-header">October 25, 2005</h2>
 262                      <a id="a000459"></a>
 263                      <div class="entry" id="entry-459">
 264                         <h3 class="entry-header">Daylight Savings Time & Clearcase</h3>
 265                         <div class="entry-content">
 266                            <div class="entry-body">
 267                               <ul>
 268   <li>Looked into potential problems with DST and Clearcase</li>
 269
 270   <li>Investigated problem with Deliver between Projects</li>
 271
 272   <li>Investigated performance problems on Windows Build machines in San Diego</lI>
 273 </ul>
 274
 275                               <h2>DST and Clearcase</h2>
 276
 277 <p> Utilizing pcsjca-ccrmt03 and ccase-sj1-4 I set up the following snapshot views:</p>
 278
 279 <ul>
 280   <li>adefaria_view2: View database on //pcsjca-ccrmt03/VWS/ADEFARIA.vws - snapshot view contents in my home directory, P drive P:/adefaria_view2</li>
 281
 282   <li>adefaria_view3: View database also on //pcsjca-ccmnt03/VWS/ADEFARIA3.vws - snapshot view contents on //ccase-sj1-4/adefaria/adefaria_view3. This is a samba share I set up on ccase-sj1-4.</li>
 283 </ul>
 284
 285 <p>These snapshot views loaded the Tools vob.</p>
 286
 287 <p>Next I:</p>
 288
 289 <ul>
 290   <li>Went into adefaria_view2, Tools/Benchmark and checked out a file</li>
 291
 292   <li>Went into adefaria_view2, Tools/Benchmark and forcefully hijacked a file</li>
 293
 294   <li>Went into adefaria_view3, Tools/convert and checked out a file</li>
 295
 296   <li>Went into adefaria_view3, Tools/convert and forcefully hijacked a file</li>
 297
 298   <li>Turned off NTP and Windows Time Service</li>
 299 </ul>
 300
 301 <p>Next I performed the following tests:</p>
 302
 303 <ol>
 304   <li>Changed the time back one hour on both pcsjca-ccrmt03 and ccase-sj1-4. This simulates the upcoming Daylight Savings Time change where both server and client theoretically change times at the same time.</li>
 305
 306   <li>Performed an update of Benchmark/convert for adefaria_view2 and adefaria_3. Looked for "everything being hijacked". Did not experience that. Instead I saw what I expected, update only complained about the one legitimate hijacked file - as it should. The other checked out file listed as checked out - as expected. No other files were listed as hijacked.</li>
 307
 308   <li>Changed the time on the server (ccase-sj1-4) back 1 hour. Left the client (pcsjca-ccrmt03) set where it was. This simulates the situation where the server changes time for DST but the client doesn't.</li>
 309
 310   <li>Repeated #2 - same results</li>
 311
 312   <li>Changed the time back one hour on the client but left the server one hour ahead. This simulates the situation where the client changes time for DST but the server doesn't.</li>
 313
 314   <li>Repeated #2 - same results</li>
 315 </ol>
 316
 317 <p>So I'm confused as to what the problem is. Am I doing something wrong?</p>
 318
 319                               <p class="entry-footer">
 320                                  <span class="post-footers">Posted by  at  3:54 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000459.html">Permalink</a>
 321
 322
 323                               </p>
 324                            </div>
 325                         </div>
 326                      </div>
 327
 328
 329
 330                      <h2 class="date-header">October 22, 2005</h2>
 331                      <a id="a000458"></a>
 332                      <div class="entry" id="entry-458">
 333                         <h3 class="entry-header">PQA Dynamic Lists</h3>
 334                         <div class="entry-content">
 335                            <div class="entry-body">
 336                               <ul>
 337   <li>Changed Dynamic Lists to properly handle bad data</li>
 338 </ul>
 339
 340                               <h2>Dynamic Lists and Bad Data</h2>
 341
 342 <p>I now have pqamerge properly creating Dynamic Lists. In the past I would call SetFieldChoiceList, which would allow validate and commit to work, but which wouldn't actually add a member to the Dynamic List. I've since changed that.</p>
 343
 344 <p>The first problem I hit was that Clearquest would treat "1.A" as the same as "1.a". So when pqamerge attempted to add "1.a" to the Dynamic List it would fail. I needed to compare ignoring case. In Perl usually one uses a regex for that and specifies "i" to ignore case.</p>
 345
 346 <div class="code"><pre>
 347 if ($var =~ /^$pattern$/i) {
 348   &lt;<i>matched ignoring case</i>&gt;
 349 } # if
 350 </pre></div>
 351
 352 <p>But some of the values of the various Dynamic Lists contain regex meta characters (e.g. "?" or "(") which caused me problems. I've fixed those now.</p>
 353
 354 <div class="code"><pre>
 355 if ("\L$var\E" eq "\L$pattern\E") {
 356   &lt;<i>matched ignoring case</i>&gt;
 357 } # if
 358 </pre></div>
 359
 360 <p>The above basically says to downshift characters between the "\L" and the "\E". Then a regular eq is used so as to avoid problems with interpreting regex meta characters.</p>
 361
 362                               <p class="entry-footer">
 363                                  <span class="post-footers">Posted by  at  1:50 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000458.html">Permalink</a>
 364
 365
 366                               </p>
 367                            </div>
 368                         </div>
 369                      </div>
 370
 371
 372
 373                      <h2 class="date-header">October 21, 2005</h2>
 374                      <a id="a000457"></a>
 375                      <div class="entry" id="entry-457">
 376                         <h3 class="entry-header">AddListMember</h3>
 377                         <div class="entry-content">
 378                            <div class="entry-body">
 379                               <ul>
 380   <li>Fixed bug in pqamerge so that it now properly adds new entries to dynamic lists</li>
 381 </ul>
 382
 383                               <h2>AddListMember</h2>
 384
 385 <p>I was dynamically adding to Dynamic lists by calling SetFieldChoiceList. This allowed validate and commit to work and for the record to be added however it doesn't actually add to the Dynamic list! You can see this later by attempting to modify a record. It's dynamic list items will show in red and you will not be able to apply the changes because it will state that the value is not a valid choice of that dynamic list.</p>
 386
 387 <p>This is quite a surprise to me. I found that I need to call AddListMember to actually get this to add to the Dynamic list. This appears to be working so I need to redo the merge again.</p>
 388
 389
 390                               <p class="entry-footer">
 391                                  <span class="post-footers">Posted by  at  1:51 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000457.html">Permalink</a>
 392
 393
 394                               </p>
 395                            </div>
 396                         </div>
 397                      </div>
 398
 399
 400
 401                      <h2 class="date-header">October 20, 2005</h2>
 402                      <a id="a000456"></a>
 403                      <div class="entry" id="entry-456">
 404                         <h3 class="entry-header">enable_ldap/Another PQA Merge</h3>
 405                         <div class="entry-content">
 406                            <div class="entry-body">
 407                               <ul>
 408   <li>Wrote and enable_ldap Perl script</li>
 409
 410   <li>Vinh Ton has provided me with yet another schema and corresponding databases</li>
 411 </ul>
 412
 413                               <h2>Another Merge</h2>
 414
 415 <p>Performing yet another merge so I will once again document the steps I take:</p>
 416
 417 <ul>
 418   <li>Restored the databases CQSchema03, CQ_Controller_Test and CQ_Controller_Prod. Doing so wipes out the old data</li>
 419
 420   <li>When importing you must go into the CQSchema03 tables for master_dbs and change the server to p4test. Otherwise you will be effecting the data on the other server!</li>
 421
 422   <li>Enter Clearquest Designer and mark the following fields as optional:</li>
 423
 424     <ul>
 425       <li>Submitter</li>
 426
 427       <li>Submit_Date</li>
 428
 429       <li>Audit_Log</li>
 430
 431       <li>old_id</li>
 432    </ul>
 433
 434   <li>Change commitmentLevel_Value_Changed hook to simply return</li>
 435
 436   <li>Test Work, Check in Schema and Upgrade Database</li>
 437
 438   <li>Import OEMUsers.cqu and Users.cqu</li>
 439
 440   <li>Upgrade Database</li>
 441
 442   <li>Run pqamerge</li>
 443
 444   <li>Test</li>
 445
 446   <li>Reverse the schema changes performed above and apply the changes</li>
 447
 448   <li>Backup new CQSchema03, CQ_Controller_Test and CQ_Controller_Prod</li>
 449 </ul>
 450
 451 <p>Use the following for a Check in Comment:</p>
 452
 453 <blockquote>
 454   <p>Changing Submitter, Submit_Date, Audit_Log and old_id to be optional for data conversion</p>
 455
 456   <p>Also changed commitmentLevel_ValueChanged hook to return before sending email.</p>
 457 </blockquote>
 458
 459                               <p class="entry-footer">
 460                                  <span class="post-footers">Posted by  at  6:19 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000456.html">Permalink</a>
 461
 462
 463                               </p>
 464                            </div>
 465                         </div>
 466                      </div>
 467
 468
 469
 470                      <h2 class="date-header">October 19, 2005</h2>
 471                      <a id="a000455"></a>
 472                      <div class="entry" id="entry-455">
 473                         <h3 class="entry-header">Most PQA Issues resolved...</h3>
 474                         <div class="entry-content">
 475                            <div class="entry-body">
 476                               <ul>
 477   <li>Resolved most of the remaining issues with PQA Merge Vinh Ton</li>
 478 </ul>
 479
 480                               <h2>Remaining Issues</h2>
 481
 482 <p>I have incorporated all of your changes and have imported your CQ_Controller_Prod, CQ_Controller_Test and CQSchema03 databases. I don't see any new users. Weren't they in the CQAllUsers database?</p>
 483
 484 <p>In any event here's how I proceeded:</p>
 485 <ul>
 486   <li>Made changes to pqamerge. This included handling a few new fields that I didn't notice before as well as adjustments to accommodate the changes in your last email. Also set <b>Cont:old_id</b> = the old id from the <b>TO</b> or <b>Prod</b>. Now we have a cross reference field. You will need to change your form to expose this field to the users.</li>
 487
 488   <li>Imported CQ_Controller_Prod, CQ_Controller_Test and CQSchema03. I see the changes that you've made to the schema.</li>
 489
 490   <li>Imported OEMUsers.cqu and Users.cqu.</li>
 491
 492   <li>Changed <b>Submitter</b>, <b>Submit_Date</b>, <b>Audit_Log</b>,
 493 and <b>old_id</b> to be optional</li>
 494
 495   <li>Changed <b>Global Script:</b> <i>RecordHistory</i> to simply <tt>Exit Function</tt></li>
 496   <li>Changed <i>CommitmentLevel_ValueChanged</i> to <tt>Exit Sub</tt>
 497 before sending email.</li>
 498
 499   <li>Added <b>delete</b> action to defect record for admin only. This
 500 is needed for <tt>pqaclean</tt> to work.</li>
 501
 502   <li>Ran <tt>pqamerge</tt></li>
 503 </ul>
 504
 505 <p>By and large this worked! There was a user who was missing. This user, <i>tngo</i>,
 506 was not listed as being subscribed to either TO nor Prod, rather to BT. I suspect that he used to be subscribed to Prod but then later was removed. If there are more users like this then there will be similar errors.</p>
 507
 508
 509                               <p class="entry-footer">
 510                                  <span class="post-footers">Posted by  at  5:23 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000455.html">Permalink</a>
 511
 512
 513                               </p>
 514                            </div>
 515                         </div>
 516                      </div>
 517
 518
 519
 520                      <h2 class="date-header">October 18, 2005</h2>
 521                      <a id="a000454"></a>
 522                      <div class="entry" id="entry-454">
 523                         <h3 class="entry-header">PQA Merge: User Issues</h3>
 524                         <div class="entry-content">
 525                            <div class="entry-body">
 526                               <ul>
 527   <li>Starting to look into user accounts issues</li>
 528
 529   <li>Send out form for LDAP Authentication Information</li>
 530
 531   <li>Coded up pong.sh and pong.tcl to check and see if ccase-rmna-3 is up or down</li>
 532
 533   <li>Created initial set of PQA User/Group Account files</li>
 534 </ul>
 535
 536                               <h2>PQA User/Group Account Files</h2>
 537
 538 <p>Here's what I did for user accounts. I've attached all the files and
 539 will refer to them by name here.</p>
 540
 541 <h3>OEM Users</h3>
 542
 543 <p>First I took the export list from Clearquest (<tt>userinfo.txt.orig</tt>).
 544 This is the untouched original export file.</p>
 545
 546 <p>Next I extracted user names that begin with "oem" -&gt; <tt>OEMUsers.cqu</tt>. Then I noticed that some of these users only appeared to be subscribed to NAS or BT. I then separated those out to <tt>OldOEMUsers.cqu</tt>.</p>
 547
 548 <h3>New Groups</h3>
 549
 550 <p>Patterning off of <tt>userinfo.txt.orig</tt> file for groups I created <tt>NewGroups.cqu</tt> to match the new groups you describe on your Users tab of the Excel Workbook. The group records from  <tt>userinfo.txt.orig</tt> I stored off in <tt>Groups.cqu</tt> and then separated off groups that were only NAS or BT to <tt>OldGroups.cqu</tt>.</p>
 551
 552 <h3>Other Users</h3>
 553
 554 <p>This left me with all of the other users which were split up into <tt>Users.cqu</tt> and <tt>RemovedUsers.cqu</tt> based on whether they
 555 subscribed to Prod or TO.</p>
 556
 557 <h3>Changing databases= line</h3>
 558
 559 <p>For all files I made the following assumption: If the databases= line
 560 contained no values then that means "all databases". So any users or
 561 groups with a databases= line with no values I assume subscribed to TO
 562 or Prod. I left these databases= lines alone.</p>
 563
 564 <p>For other users or groups, if TO or Prod appeared in the databases=
 565 line I removed all values and put in Cont.</p>
 566
 567 <p>Please let me know if this comes close to what you wanted WRT users and groups.</p>
 568
 569
 570                               <p class="entry-footer">
 571                                  <span class="post-footers">Posted by  at  3:22 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000454.html">Permalink</a>
 572
 573
 574                               </p>
 575                            </div>
 576                         </div>
 577                      </div>
 578
 579
 580
 581                      <h2 class="date-header">October 17, 2005</h2>
 582                      <a id="a000453"></a>
 583                      <div class="entry" id="entry-453">
 584                         <h3 class="entry-header">PQA Merge Issues/Pong</h3>
 585                         <div class="entry-content">
 586                            <div class="entry-body">
 587                               <ul>
 588   <li>Documented remaining <a href="http://intranet.broadcom.com/~adefaria/Clearquest/">PQA Conversion Issues</a></li>
 589
 590   <li>Audit_Log is not handled properly currently. Querying Vinh</li>
 591
 592   <li>Resolved problem with Submitter and Submit_Date. Need to change schema to make those fields OPTIONAL as well as add return statements to the Perl action hooks</li>
 593
 594   <li>Investigated using LDAP authentication with Clearquest</li>
 595
 596   <li>Wrote a simple expect script (pong) and bash script to verify that a machine is up and send email if it isn't. Problem is ccase-rmna-1 lacks expect!</li>
 597 </ul>
 598
 599                               <h2>Audit_Log</h2>
 600
 601 <p>As it stands <b>Audit_Log</b> is probably not being handled the way you think it should be. My investigation seems to indicate that <b>Audit_Log</b> is, as its name suggest, an auditing of what changes were made. In transferring from the old databases to the new one, the new <b>Audit_Log</b> is essentially a blank slate. It is the responsbility of the Action Script <tt>RecordHistory</tt> to update the <b>Audit_Log</b>. Thus the only recording in <b>Audit_Log</b> for the transfer is that the record was added! In    other words all history is lost! I don't think that's what you want. We will need to similarly change <b>Audit_Log</b> to be a simple <i>OPTIONAL</i> field with no Action Scripts in order for <tt>pqamerge</tt> to transfer the Audit_Log</b>.</p>
 602
 603 <h2>LDAP Authentication</h2>
 604
 605 <p>Regarding LDAP authentication: There is a whole new chapter in the Clearquest Admin Guide about this and we'll need to coordinate this with an <i>LDAP Administrator</i> (Ray, who's our LDAP Administrator?). On the plus side users would no longer have to remember separate  usernames/passwords for Clearquest. In fact, new users would not even need to be added because if they are in the ActiveDirectory then they have a login from Clearquest. Of course I suspect that security is then achieved by Clearquest groupings, which, as far as I can tell, are still manually created in Clearquest Designer's User Administration screen. Additionally, LDAP permitting, other fields will be instantaneously mapped properly like Full Name, Phone Number and the ever popular Email Address! In other words, LDAP authentication is doable but a little complicated, requires coordination with the LDAP administrator and requires a number of carefully executed commands.</p>
 606
 607 <p>One issue or thing to test would be if older Clearquest clients can
 608 still authenticate with LDAP. If not then the user community would need
 609 to update their Clearquest.</p>
 610
 611 <h2>Pong</h2>
 612
 613 <p>I now have a script called pong.sh (and a corresponding expect script called pong.tcl) that will "pong" a system and send email if it does not respond. By "pong" I mean it will telnet to the machine, attempt to login as vobadm and check for a "proper" prompt. If it fails then email is sent to the members of our project (Ray is working on a bona fide email alias...).</p>
 614
 615 <p>I planned on running this from ccase-rmna-1 in vobadm's crontab (BTW: There was a blank line in the crontab, which causes Solaris to complain (Other OSes are this picky. I removed that blank line).</p>
 616
 617 <p>The problem now is that ccase-rmna-1 lacks expect! :-( </p>
 618
 619                               <p class="entry-footer">
 620                                  <span class="post-footers">Posted by  at  8:00 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000453.html">Permalink</a>
 621
 622
 623                               </p>
 624                            </div>
 625                         </div>
 626                      </div>
 627
 628
 629
 630                      <h2 class="date-header">October 16, 2005</h2>
 631                      <a id="a000452"></a>
 632                      <div class="entry" id="entry-452">
 633                         <h3 class="entry-header">PQA Clearquest:: Spacing out</h3>
 634                         <div class="entry-content">
 635                            <div class="entry-body">
 636                               <ul>
 637   <li>Fixed minor problems with trailing spaces on fields</li>
 638
 639   <li>Fixed minor problem with space filled <b>Software_Revision</b></li>
 640
 641   <li>Fixed problem where field names were reversed.</li>
 642
 643   <li><b>Submitter</b> and <b>Submit_Date</b> are set by action hooks to the current username and current date/time. We'll need to turn
 644  this off if we want the old <b>Submitter</b> and <b>Submit_Date</b>.</li>
 645
 646   <li>Implemented <i>Attachment Handling</i></li>
 647 </ul>
 648
 649
 650
 651                               <h3>Trailing spaces</h3>
 652
 653 <p>There are some minor problems with the data involving spaces. For example, a <b>Prod:HUT_Version</b> is set to "<i>BCM95704CA40 v1.0 revA0 </i>" - Note that it has a trailing space. Well <b>AddToFieldChoiceList()</b> attempts to add this value but the Clearquest API trims the trailing space! This results in a validation error as "<i>BCM95704CA40 v1.0 revA0 </i>" is <b>not</b> equal to "<i>BCM95704CA40 v1.0 revA0</i>". The solution here is to trim the trailing space before calling <b>AddToFieldChoiceList()</b>.</p>
 654
 655 <h3>Space filled Software_Revision</h3>
 656
 657 <p><b>Prod:Software_Version</b> would sometimes come in as " " instead of "". My code was only checking for "" and changing that to "N/A". It now also checks for " ".</p>
 658
 659 <h3>Field name reversal</h3>
 660
 661 <p>Some fields, for example <b>ReportedBy</b>, were supposed to be renamed to another field name, i.e. <b>Reported_By</b>, in the destination database but my code reversed the field naming change. It's odd that Clearquest was OK with adding <b>ReportedBy</b> field to <b>Cont</b> as there was no <b>ReportedBy</b> field in <b>Cont</b>. Adding the correct field name solved a problem with <b>Visibility</b> and its action hook.</p>
 662
 663 <h3>Attachments take time!</h3>
 664
 665 <p>While the <i>TransferAttachments()</i> routine now works, it adds a significant amount of time to the processing of defects with attachments. Some attachments are as large as 82 Meg! There are zip files, Excel spreadsheets, screen dumps in the very inefficient BMP file format and Ethreal dumps and even tape I/O dumps. <i>TransferAttachments()</i> operates by extracting the files from the source database to disk then calling <i>AddAttachment()</i> to copy the files back into the new DB. While not the most efficient way to do this I see no other way given the current Clearquest API.</p>
 666
 667 <p>As a measure, previously it took 16 minutes and 44 seconds to merge 1382 defect records from <b>TO</b> -> <b>Cont</b>, with attachments it took <b>4 hours and 11 minutes!!!</b></p>
 668
 669 <p>Ah, figured out why it took so long. I was using a snapshot view that was housed on my laptop. So the attachment files were being written to the current working directory, my snapshot view on the laptop. So those writes and reads were over the network. To make matters worse my laptop was not even at Broadcom, rather it was at my house. So those 82 meg files had to travel from Broadcom though my small DSL connection and even through a VPN! No wonder it took so long!</p>
 670
 671 <p>Now running it in ~vobadm/My Documents on the server and it's much quicker... Only 25 minutes and 21 seconds.</p>
 672
 673                               <p class="entry-footer">
 674                                  <span class="post-footers">Posted by  at 12:57 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000452.html">Permalink</a>
 675
 676
 677                               </p>
 678                            </div>
 679                         </div>
 680                      </div>
 681
 682
 683
 684                      <h2 class="date-header">October 15, 2005</h2>
 685                      <a id="a000451"></a>
 686                      <div class="entry" id="entry-451">
 687                         <h3 class="entry-header">PQA Clearquest: Resolving remaining issues with bad data</h3>
 688                         <div class="entry-content">
 689                            <div class="entry-body">
 690                               <p>This is to document all of the issues related with bad data in the source databases that is impeeding the PQA Merge process. Along with the issues I will present what I did to work around the problems and what I suggest we should do to provide a smooth transition of these databases</p>
 691
 692                               <h2>Resolving Data Conversion Problems in PQA Database Merge</h2>
 693
 694 <h3>New fields that are mandatory</h3>
 695
 696 <p>The following fieilds are new in the destination database (Cont) and are also mandatory thus must be filled in with something:</p>
 697
 698 <ul>
 699   <li><b>Cont:Found_On_Gold:</b> This field is defaulted to <i>No</i>.</li>
 700 </ul>
 701
 702 <h3>Fields with blank or invalid data</h3>
 703
 704 <p>The following fields have blank or invalid data in the source database thus fail validation when added to the new database:</p>
 705
 706 <ul>
 707   <li><b>TO:SQATestCase:</b> This field, when blank, is set to the string "N/A". This field is also renamed to <b>Cont:PQATestCase</b>.</li>
 708
 709   <li><b>TO:Title_2:</b> This field, when blank, is set to the string "N/A". This field is also renamed to <b>Cont:TItle</b>.</li>
 710
 711   <li><b>Prod:Software_Version:</b> This field, when blank, is set to the string "N/A".</li>
 712
 713   <li><b>Prod:HUT_Version:</b> This field, when blank, is set to the string "N/A". This field is also renamed to <b>Cont:Board_Revision</b>.</li>
 714
 715   <li><b>Prod:Software_Version:</b> This field, when blank, is set to the string "N/A".</li>
 716
 717   <li><b>Prod:SQATestCase:</b> This field, when blank, is set to the string "N/A". This field is also renamed to <b>Cont:PQATestCase</b>.</li>
 718 </ul>
 719
 720 <h3>Fields with data that are no longer valid in new database</h3>
 721
 722 <p>The following fields have data in the source database but fail validation when added to the new database due to reasons like not being on the list of acceptable values for the field in question:</p>
 723
 724 <ul>
 725   <li><b>Prod:Category</b> This field sometimes has the value of <i>Hardware</i> or <i>System Bios</i> which are not valid choices in the new database. For now I am changing <i>Hardware</i> -> <i>Hardware - Chip</i> and <i>System Bios</i> -> <i>Software</i>. I suggest we add <i>Hardware</i> and <i>System Bios</i> to the constant list as <i>HARDWARE</i> and <i>SYSTEM BIOS</i> (Capitalized) so we can easily find and correct these later.</li>
 726
 727   <li><b>Prod:Issue_Classification:</b> This field sometimes has the value of <i>Hardware</i> which is not a valid choice in the new database. For now I'm changing <i>Hardware</i> -> <i>Requirement</i>. I suggest we add <i>Hardware</i> to the constant list as <i>HARDWARE</i> (Capitalized) so we can easily find and correct these later.</li>
 728
 729   <li><b>Prod:Resolution:</b> This field sometimes has the value of <i>HW Fix</i> or <i>MAC Core</i> which are not valid choices in the new database. For now I am changing <i>HW Fix</i> -> <i>HW - Fix</i> and <i>MAC Core</i> -> <i>SW Fix</i>. I suggest we add <i>HW - Fix</i> and <i>MAC Core</i> to the constant list as <i>HW - FIX</i> and <i>MAC CORE</i> (Capitalized) so we can easily find and correct these later.</li>
 730
 731   <li><b>Prod:HUT_Revision:</b> This field is sometimes set to "n/a". This is translated to "N/A" (note capitalization).</li>
 732 </ul>
 733
 734 <h3>Fields that need truncating</h3>
 735
 736 <p>The following fields have data that is too large to fit in the size of the corresponding field in the destination database:</p>
 737
 738 <ul>
 739   <li><b>Prod:ActionNotes:</b> This field is defined with a maximum length of 50 characters in the TO database, 250 characters in the Prod database and 50 characters in the Cont database. Some entries in the Prod database are greater than 50 characters thus require truncation. I suggest that we increase the maximum length of <b>Cont:ActionNotes</b> to 250 characters to avoid this problem.</li>
 740 </ul>
 741
 742                               <p class="entry-footer">
 743                                  <span class="post-footers">Posted by  at  6:41 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000451.html">Permalink</a>
 744
 745
 746                               </p>
 747                            </div>
 748                         </div>
 749                      </div>
 750
 751
 752
 753                      <h2 class="date-header">October 14, 2005</h2>
 754                      <a id="a000450"></a>
 755                      <div class="entry" id="entry-450">
 756                         <h3 class="entry-header">PQA Merge - Action Hooks & Attachments</h3>
 757                         <div class="entry-content">
 758                            <div class="entry-body">
 759                               <ul>
 760   <li>There are action hooks in Cont that send out email. I fear my testing may be generating lots of unnecessary email. Would like to have the Action Hook's email procedures coded to be conditional based on say an env  var so we can turn off email during the production merge.</lI>
 761
 762   <li>Attachments are currently not handled because they are different and require special code to iterate through them to copy them to the destination database</li>
 763
 764   <li>Need to have the delete action available on the defect record so pqaclean can work. I've modified my schema for that</li>
 765
 766   <li>Changed pqamerge to only get the dbid's then to obtain the entity records when needed. Previously I would build a query with all fields. That query took from 6-40 minutes to run before I could even obtain the first record! Also the memory size of Perl grew very big. This algorithm is much faster with the query taking under 1 second!</li>
 767
 768   <li>Working on problems with the source data.</li>
 769 </ul>
 770
 771                               <h3>Bad data. BAD DATA! Go sit in the corner!</h3>
 772
 773 <p>I'm discovering that not all the data in the source databases are clean to start with. For example, HUT_Version -> Board_Revision. in TO all defects have valid HUT_Versions. With Prod some of the HUT_Versions are blank! That's not good as that's an invalid value. For example, use Clearquest to bring up record Prod00002978's Board_Revision (It's shown in Clearquest as Board_Revision but is tied to the field HUT_Version) is blank. Select <strong>Modify</strong> and the field will be <font color=red>red</font>. On that same record you'll notice that <strong>Category</strong> is also <font color=red>red</font>. This is because <strong>Category</strong> is a <em>Constant list</em> and there is no <em>Hardware</em> in that constant list! There are <em>Hardware - Board</em> and <em>Hardware - Chip</em> however. Which do I choose?</p>
 774
 775                               <p class="entry-footer">
 776                                  <span class="post-footers">Posted by  at 11:14 AM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000450.html">Permalink</a>
 777
 778
 779                               </p>
 780                            </div>
 781                         </div>
 782                      </div>
 783
 784
 785
 786                      <h2 class="date-header">October 13, 2005</h2>
 787                      <a id="a000449"></a>
 788                      <div class="entry" id="entry-449">
 789                         <h3 class="entry-header">PQA Merge</h3>
 790                         <div class="entry-content">
 791                            <div class="entry-body">
 792                               <ul>
 793   <li>Added Display, Logger and new TimeUtils to pqaclean and pqamerge</li>
 794
 795   <li>Finally got ProjectExists() to work. Turns out I was using the wrong CQPerlExt constant causing pqamerge to blow up</li>
 796
 797   <li>Received guidance from Vinh regarding certain field transformations. Incorporated them into pqamerge</li>
 798
 799   <li>Pqamerge now merging all of TO:defect records with a few exceptions that I'm fixing</li>
 800 </ul>
 801
 802
 803                               <p class="entry-footer">
 804                                  <span class="post-footers">Posted by  at  4:09 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000449.html">Permalink</a>
 805
 806
 807                               </p>
 808                            </div>
 809                         </div>
 810                      </div>
 811
 812
 813
 814                      <h2 class="date-header">October 12, 2005</h2>
 815                      <a id="a000448"></a>
 816                      <div class="entry" id="entry-448">
 817                         <h3 class="entry-header">PQA Clearquest: Project fields</h3>
 818                         <div class="entry-content">
 819                            <div class="entry-body">
 820                               <ul>
 821   <li>Started coding TransferDefects(). This is where the rubber hits the road</li>
 822 </ul>
 823
 824                               <h3>Project Fields</h3>
 825
 826 <p>Queried Vinh:</p>
 827
 828 <p>Vinh, you may be seeing me asking more questions as I get into coding pqamerge. This email is about Project. Let me see if I understand this:</p>
 829
 830 <p>There are the following "project" related fields:</p>
 831
 832 <ul>
 833   <li><b>TO:Project:</b> Reference to Project stateless record. Since there are no Project records in the TO database I assume this field is not used and should be ignored from TO.</li>
 834
 835   <li><b>Prod:Project:</b> There are records in Prod. I assume these should be translated to <b>Cont:Found_In_Project</b>.</li>
 836
 837   <li><b>Prod:Project_Name:</b> Apparently not used  and should be ignored?</li>
 838
 839   <li><b>TO:Found_In_Project:</b> Short string dynamic list consisting of <em>Release T2.0</em>, <em>Release T2.1</em>, <em>Release T2.5</em> and <em>Release T3.0</em>. I assume that this translates to <b>Cont:Found_In_Project</b> which is a reference to <b>Cont:Project</b>?</li>
 840 </ul>
 841
 842 <p>There are other "project" related fields that I'm a little confused about:</p>
 843
 844 <ul>
 845   <li><b>TO:CommittedToProject:</b> Short string, dynamic list</li>
 846
 847   <li><b>TO:DeferredToProject:</b> Short string, dynamic list</li>
 848
 849   <li><b>Prod:CommittedToProject:</b> Short string, <u>constant</u> list</li>
 850
 851   <li><b>Prod:DeferredToProject:</b> Short string, <u>constant</u> list</li>
 852
 853   <li><b>Cont:CommittedToProject:</b> Short string, dynamic list</li>
 854
 855   <li><b>Cont:DeferredToProject:</b> Short string, dynamic list</li>
 856 </ul>
 857
 858 <p>Should all of these be changed to references to the Cont:Project stateless record?</p>
 859
 860 <h3>Values for new mandatory fields</h3>
 861
 862 <p>I've added routines to dynamically create those dynamic lists, however I am having problems with the following fields. These fields are new for Cont and are mandatory. Since I don't have old data to fill them in with I do not know what you want them to be set to. Here are the fields and my guesses:</p>
 863
 864 <ul>
 865   <li><b> Board_Revision:</b> Default value: ???</li>
 866
 867   <li><b>Found_On_Gold:</b> This is a constant list of "Yes" or "No". I assume "No"</li>
 868
 869   <li><b>PQATestCase:</b> This is a constant list of "Yes" or "N/A". I assume "N/A"</li>
 870 </ul>
 871
 872                               <p class="entry-footer">
 873                                  <span class="post-footers">Posted by  at 11:40 AM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000448.html">Permalink</a>
 874
 875
 876                               </p>
 877                            </div>
 878                         </div>
 879                      </div>
 880
 881
 882
 883                      <h2 class="date-header">October 11, 2005</h2>
 884                      <a id="a000447"></a>
 885                      <div class="entry" id="entry-447">
 886                         <h3 class="entry-header">PQA Clearquest</h3>
 887                         <div class="entry-content">
 888                            <div class="entry-body">
 889                               <ul>
 890   <li>Resolved problems being able to log into the new Cont database by redoing the importation of CQSchema, CQ_Controller_Prod and CQ_Controller_Test</li>
 891
 892   <li>Imported user accounts database from old schema to new schema. This was done by simply setting all users to all databases. While this is not what we will do for the production move it allows me to continue coding and testing</li>
 893
 894   <li>Started coding pqamerge. Got to the point of being able to transfer Customer and Project records</li>
 895
 896   <li>Coded pqaclean. This is a little script to effectively erase the destination database. This allows me to run pqamerge over and over from a clean slate. Had to add a delete action to the defect record</li>
 897 </ul>
 898
 899                               <p class="entry-footer">
 900                                  <span class="post-footers">Posted by  at  9:15 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000447.html">Permalink</a>
 901
 902
 903                               </p>
 904                            </div>
 905                         </div>
 906                      </div>
 907
 908
 909
 910                      <h2 class="date-header">October 10, 2005</h2>
 911                      <a id="a000446"></a>
 912                      <div class="entry" id="entry-446">
 913                         <h3 class="entry-header">PQA Clearquest</h3>
 914                         <div class="entry-content">
 915                            <div class="entry-body">
 916                               <ul>
 917   <li>Hooked up new PQA schema database and data database</li>
 918
 919   <li>Starting to code merge routines</li>
 920
 921   <li>Created PQA Schedule (See below)</li>
 922 </ul>
 923
 924                               <h3>Moving MS/SQL Databases</h3>
 925
 926 <p>Moving a MS/SQL Database from one host to another involves a bit of tweaking to get the new system to recognize that it has a new database. I will attempt to detail here what needs to be done. </p>
 927
 928 <p>In order to import Clearquest databases to a new MS SQL Database Server:</p>
 929
 930 <ol>
 931   <li>Place imported datafile onto new machine.</li>
 932
 933   <li>Start the MS SQL Server Enterprise Manager (C:\Windows\system32\mmc.exe /s "C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.msc")</li>
 934
 935   <li>Expand tree until you see "(local)" then "Databases". Right click on Database and select New Database to create an empty new database. Name the database appropriately. On the Data Files tab we changed the default path of C:\Program Files\Microsoft SQL Server\MSSQL\data\&lt;database name&gt;.mdf to a more approriate place. Also check the Transaction Log tab to adust path.</li>
 936
 937   <li>Restore database by right clicked on the new database you created and selecting All Tasks: Restore Database. Under Restore select From Device then click Add then find the restored db file. Under Options change the paths for Move to physical file name.</li>
 938
 939   <li>For Clearquest Schema databases only (You may need to restart the SQL Server Enterprise Manager after the above restore of the database): Since Clearquest uses a database to hold the schema and that schema points to known user databases, importing a Clearquest schema will have entries that point over to <b>projection</b> databases! These need to change:
 940
 941     <ul>
 942       <li>In SQL Sever Enterprise Manager locate your imported schema database and double click on Tables.</li>
 943
 944       <li>Find master_dbs, right click on master_dbs and select Open Table: Return All Rows.</li>
 945
 946       <li>Change the server column to the name of the new server</li>
 947
 948       <li>Select Run (the ! symbol in the toolbar)</li>
 949     </ul>
 950
 951   <li>Folllow instructions at <a href="http://support.microsoft.com/default.aspx?scid=kb;%5bLN%5d;Q240872">How to resolve permission issues when you move a database between servers that are running SQL Server</a> for fixing permissions problems.</li>
 952
 953   <li>Import user databases. Note the fix above regarding master_dbs:server is <b>not</b> required for user databases</li>
 954 </ol>
 955
 956 <h3>Merge Routines and Connecting to Multiple Schemas</h3>
 957
 958 <p>With two schema databases I was having problems with my Perl script connecting to the databases. In the past I had:
 959
 960 <div class="code"><pre>
 961       ## Internal variables ##
 962       my $session;
 963       my $login           = "admin";
 964       my $password    = "*****";
 965       my $masterdb    = ""; # Don't need a masterdb (Using default?)
 966       my $db_name;
 967     ...
 968       sub StartSession {
 969         $db_name = shift;
 970
 971         $session = CQPerlExt::CQSession_Build ();
 972
 973         $session->UserLogon ($login, $password, $db_name, $masterdb);
 974       } # StartSession
 975 </pre></div>
 976
 977 <p>Now when I run this in the presence of two schema databases I get:</p>
 978
 979 <div class=box>
 980     The database "MASTR" belonging to master database "2002.05.00" is an invalid name. Enter the correct name of a ClearQuest user database. at c:/Program Files/Rational/ClearQuest/lib/CQPerlExt.pm line 3713.
 981 </div>
 982
 983 <p>I think I need to specify the proper $ masterdb name but I don't know what that might be... Hmmm... Seems that $masterdb is really just the Connection name that you'd see when you start Clearquest Designer or Clearquest Client and there are multiple schemas to choose from. That's odd because that could be potentially anything as the user could rename it. However if I use PQA_Old on p4test (which is what I named the old schema connection) then it works.</p>
 984
 985 <p>OK, more work on this tomorrow. I have already defined the new defect record in my Perl module. I just have to start coding the merge routines now...</p>
 986
 987 <h3>PQA Schedule</h3>
 988
 989 <p>The following is a rough estimate of the work needed to be completed to get to the point where we are ready to convert the live production databases</p>
 990
 991 <ul>
 992   <li> Restore new Schema DB and Data DB (<font color="#999">1 Day</font>)</li>
 993
 994   <li> Investigate record/field mappings (<font color="#999">2 Days</font>)</li>
 995
 996   <li>Determine order fo record additions (<font color="#999">1 Day</font>)</li>
 997
 998   <li>Investigate requirements for adding of records to Clearquest (<font color="#999">2 Days</font>)</li>
 999
1000   <li>Code/Test merge procedures (<font color="#999">3 Day</font>)</li>
1001
1002   <li>Test conversion on <b>p4test</b> (<font color="#999">4 Days</font>)</li>
1003 </ul>
1004
1005 <p><b>Total:</b> 13 Days</p>
1006
1007                               <p class="entry-footer">
1008                                  <span class="post-footers">Posted by  at 12:11 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000446.html">Permalink</a>
1009
1010
1011                               </p>
1012                            </div>
1013                         </div>
1014                      </div>
1015
1016
1017
1018                      <h2 class="date-header">October  8, 2005</h2>
1019                      <a id="a000445"></a>
1020                      <div class="entry" id="entry-445">
1021                         <h3 class="entry-header">SJ VOB Move</h3>
1022                         <div class="entry-content">
1023                            <div class="entry-body">
1024                               <p>The VOB move for San Jose went fairly well. Without the normal user load on the servers the dumping and loading process was much quicker. I've attached Jennifer's spread sheet and updated it to reflect which vobs we've moved and how long it took as well as what sort of reduction we got in the DB sizes. All moved vobs are tagged on ccase-sj1-7 and Clearcase is still off on ccase-sj1-1 - for now. We will turn that on before Jennifer and Chin start with their testing. Yet left to do is the Multisite chreplica and re instituting of the cronjobs, etc. - nothing that would imped users Monday morning as well as clean up of backup areas assuming we reach a go on the go/no go tomorrow afternoon.</p>
1025
1026 <p>I've also attached a tar image of the log files that we managed to capture for the dump and load process.</p>
1027
1028                               <p class="entry-footer">
1029                                  <span class="post-footers">Posted by  at  3:13 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000445.html">Permalink</a>
1030
1031
1032                               </p>
1033                            </div>
1034                         </div>
1035                      </div>
1036
1037
1038
1039                      <h2 class="date-header">October  7, 2005</h2>
1040                      <a id="a000444"></a>
1041                      <div class="entry" id="entry-444">
1042                         <h3 class="entry-header">ctmerge</h3>
1043                         <div class="entry-content">
1044                            <div class="entry-body">
1045                               <ul>
1046   <li>Started incorporating ctmerge and other old Clearcase/Clearquest oriented scripts in to adm vob</li>
1047
1048   <lI>Investigated some Multisite issues WRT this SJ VOB move</li>
1049
1050   <li>Working with Shivdutt on copying VOB storage over to /projects/cc-test</li>
1051 </ul>
1052
1053                               <p class="entry-footer">
1054                                  <span class="post-footers">Posted by  at  6:01 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000444.html">Permalink</a>
1055
1056
1057                               </p>
1058                            </div>
1059                         </div>
1060                      </div>
1061
1062
1063
1064                      <h2 class="date-header">October  6, 2005</h2>
1065                      <a id="a000443"></a>
1066                      <div class="entry" id="entry-443">
1067                         <h3 class="entry-header">PQA.pm/adm VOB</h3>
1068                         <div class="entry-content">
1069                            <div class="entry-body">
1070                               <ul>
1071   <li>Converted Code Page routines into a PQA.pm Perl Module</li>
1072
1073   <li>Changed routines to check all fields. Clearquest returns character data for fields such as DATE_TIME fields. These record definitions are now complete and will be useful when it comes time to perform the conversion</li>
1074
1075   <li>Waiting for new schema to start coding/testing conversion process. Contacted David Shaw who had helped us last time to get the databases onto our test server</li>
1076
1077   <li>Finally get adm VOB working and am starting to add my stuff into this VOB in a controlled fashion. This is not just a place to dump all of our scripts rather it's a place to start centralizing our code in a manner consistent with proper software engineering principals (Structured coding, code reuse, generalization, object oriented design principals, etc.)</li>
1078 </ul>
1079
1080                               <p class="entry-footer">
1081                                  <span class="post-footers">Posted by  at 11:28 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000443.html">Permalink</a>
1082
1083
1084                               </p>
1085                            </div>
1086                         </div>
1087                      </div>
1088
1089
1090
1091                      <h2 class="date-header">October  5, 2005</h2>
1092                      <a id="a000441"></a>
1093                      <div class="entry" id="entry-441">
1094                         <h3 class="entry-header">HTML Characters/VOB Distribution</h3>
1095                         <div class="entry-content">
1096                            <div class="entry-body">
1097                               <ul>
1098   <li>Changed CheckCodePage to use HTML character equivalents</li>
1099
1100   <li>Derived a plan of redistributing VOBs between VOB servers based on VOB database size</li>
1101 </ul>
1102
1103                               <h3>HTML Characters</h3>
1104
1105 <p>Decided to translate non US ASCII characters into their HTML equivalents. Therefore &copy; changes to "&amp;copy;" For characters that have no handy name equivalent used the form of &amp;#<i>n</i>; where <i>n</i> is the decimal number for the character.</p>
1106
1107 <h3>VOB Distribution</h3>
1108
1109 <p>Based on Jennifer's email and adjusting for size of DB here is how I'd split the vobs between ccase-sj1-1 and ccase-sj1-7. This distribution balances the vob database size between the two machines.</p>
1110
1111 <table  align="center" border="1" cellpadding="2" cellspacing="0" height="100%"  width="95%" bgcolor="white">
1112   <tbody>
1113     <tr>
1114       <th colspan="3" bgcolor="teal" align="center"><font color="white">Proposed split of vobs</font></th>
1115     </tr>
1116     <tr bgcolor="#33ccff">
1117       <th>Vob</th>
1118       <th>ccase-sj1-1</th>
1119       <th>ccase-sj1-7</th>
1120     </tr>
1121     <tr>
1122       <td>\UCM-Projects</td>
1123       <td>436.8</td>
1124       <td>&nbsp;</td>
1125     </tr>
1126     <tr bgcolor="#ddd">
1127       <td>\SetTop</td>
1128       <td>&nbsp;</td>
1129       <td>4545.9</td>
1130     </tr>
1131     <tr>
1132       <td>\magnum</td>
1133       <td>442.7</td>
1134       <td>&nbsp;</td>
1135     </tr>
1136     <tr bgcolor="#ddd">
1137       <td>\BSEAV</td>
1138       <td>&nbsp;</td>
1139       <td>452.1</td>
1140     </tr>
1141     <tr>
1142       <td>\rockford</td>
1143       <td>97.4</td>
1144       <td>&nbsp;</td>
1145     </tr>
1146     <tr bgcolor="#ddd">
1147       <td>\TestTools</td>
1148       <td>&nbsp;</td>
1149       <td>15.4</td>
1150     </tr>
1151     <tr>
1152       <td>\DVTSJ</td>
1153       <td>17.5</td>
1154       <td>&nbsp;</td>
1155     </tr>
1156     <tr bgcolor="#ddd">
1157       <td>\TiVo</td>
1158       <td>&nbsp;</td>
1159       <td>49.4</td>
1160     </tr>
1161     <tr>
1162       <td>\LinuxSupport</td>
1163       <td>&nbsp;</td>
1164       <td>18.8</td>
1165     </tr>
1166     <tr bgcolor="#ddd">
1167       <td>\SetTopGI</td>
1168       <td>377.9</td>
1169       <td>&nbsp;</td>
1170     </tr>
1171     <tr>
1172       <td>\SetTopMot</td>
1173       <td>288.8</td>
1174       <td>&nbsp;</td>
1175     </tr>
1176     <tr bgcolor="#ddd">
1177       <td>\Ref_Linux_Kernel</td>
1178       <td>&nbsp;</td>
1179       <td>1647.2</td>
1180     </tr>
1181     <tr>
1182       <td>\BSE_MS</td>
1183       <td>482.5</td>
1184       <td>&nbsp;</td>
1185     </tr>
1186     <tr bgcolor="#ddd">
1187       <td>\tmmsky</td>
1188       <td>&nbsp;</td>
1189       <td>14.7</td>
1190     </tr>
1191     <tr>
1192       <td>\nds</td>
1193       <td>14.5</td>
1194       <td>&nbsp;</td>
1195     </tr>
1196     <tr bgcolor="#ddd">
1197       <td>\Mot_P3_TCMTC</td>
1198       <td>&nbsp;</td>
1199       <td>0.2</td>
1200     </tr>
1201     <tr>
1202       <td>\CommEngine</td>
1203       <td>1506.7</td>
1204       <td>&nbsp;</td>
1205     </tr>
1206     <tr bgcolor="#ddd">
1207       <td>\BSSS</td>
1208       <td>&nbsp;</td>
1209       <td>28.9</td>
1210     </tr>
1211     <tr>
1212       <td>\softmodem</td>
1213       <td>11.7</td>
1214       <td>&nbsp;</td>
1215     </tr>
1216     <tr bgcolor="#ddd">
1217       <td>\applications</td>
1218       <td>&nbsp;</td>
1219       <td>8.4</td>
1220     </tr>
1221     <tr>
1222       <td>\bsp</td>
1223       <td>2.4</td>
1224       <td>&nbsp;</td>
1225     </tr>
1226     <tr bgcolor="#ddd">
1227       <td>\CP64_TC</td>
1228       <td>&nbsp;</td>
1229       <td>21.2</td>
1230     </tr>
1231     <tr>
1232       <td>\Mot_P3_TvMon</td>
1233       <td>68.6</td>
1234       <td>&nbsp;</td>
1235     </tr>
1236     <tr bgcolor="#ddd">
1237       <td>\DSR207</td>
1238       <td>&nbsp;</td>
1239       <td>5</td>
1240     </tr>
1241     <tr>
1242       <td>\dsr207_tvmon</td>
1243       <td>5.2</td>
1244       <td>&nbsp;</td>
1245     </tr>
1246     <tr bgcolor="#ddd">
1247       <td>\BcmLib_Dsr530</td>
1248       <td>&nbsp;</td>
1249       <td>5</td>
1250     </tr>
1251     <tr>
1252       <td>\BcmLib_Dsr550</td>
1253       <td>11.1</td>
1254       <td>&nbsp;</td>
1255     </tr>
1256     <tr bgcolor="#ddd">
1257       <td>\DSR550P3_BSP</td>
1258       <td>&nbsp;</td>
1259       <td>3.5</td>
1260     </tr>
1261     <tr>
1262       <td>\Documentation</td>
1263       <td>&nbsp;</td>
1264       <td>30.6</td>
1265     </tr>
1266     <tr bgcolor="#ddd">
1267       <td>\SQA</td>
1268       <td>317.9</td>
1269       <td>&nbsp;</td>
1270     </tr>
1271     <tr>
1272       <td>\Web</td>
1273       <td>112.7</td>
1274       <td>&nbsp;</td>
1275     </tr>
1276     <tr bgcolor="#ddd">
1277       <td>\Test</td>
1278       <td>30.3</td>
1279       <td>&nbsp;</td>
1280     </tr>
1281     <tr>
1282       <td>\Firmware</td>
1283       <td>&nbsp;</td>
1284       <td>95</td>
1285     </tr>
1286     <tr bgcolor="#ddd">
1287       <td>\echostarUK</td>
1288       <td>483.9</td>
1289       <td>&nbsp;</td>
1290     </tr>
1291     <tr>
1292       <td>\kylin</td>
1293       <td>53.9</td>
1294       <td>&nbsp;</td>
1295     </tr>
1296     <tr bgcolor="#ddd">
1297       <td>\CFE</td>
1298       <td>&nbsp;</td>
1299       <td>25.2</td>
1300     </tr>
1301     <tr>
1302       <td>\brcm_wince</td>
1303       <td>1.1</td>
1304       <td>&nbsp;</td>
1305     </tr>
1306     <tr bgcolor="#ddd">
1307       <td>\Tools</td>
1308       <td>&nbsp;</td>
1309       <td>7</td>
1310     </tr>
1311     <tr>
1312       <td>\Motorola_lib</td>
1313       <td>6.3</td>
1314       <td>&nbsp;</td>
1315     </tr>
1316     <tr bgcolor="#ddd">
1317       <td>\MOT_97320</td>
1318       <td>&nbsp;</td>
1319       <td>10.5</td>
1320     </tr>
1321     <tr>
1322       <td>\BcmLib_Dsr580</td>
1323       <td>3.3</td>
1324       <td>&nbsp;</td>
1325     </tr>
1326     <tr bgcolor="#ddd">
1327       <td>\BcmLib_Dsr580_Venom2_P2</td>
1328       <td>&nbsp;</td>
1329       <td>4.7</td>
1330     </tr>
1331     <tr>
1332       <td>\BcmLib_Dsr500</td>
1333       <td>&nbsp;</td>
1334       <td>11.1</td>
1335     </tr>
1336     <tr bgcolor="#ddd">
1337       <td>\BCM_HAL</td>
1338       <td>24.4</td>
1339       <td>&nbsp;</td>
1340     </tr>
1341     <tr>
1342       <td>\DVI3K</td>
1343       <td>15.1</td>
1344       <td>&nbsp;</td>
1345     </tr>
1346     <tr bgcolor="#ddd">
1347       <td>\DViTV</td>
1348       <td>&nbsp;</td>
1349       <td>3.1</td>
1350     </tr>
1351     <tr>
1352       <td >\DSR550P3</td>
1353       <td>&nbsp;</td>
1354       <td>21.6</td>
1355     </tr>
1356     <tr bgcolor="#ddd">
1357       <td>\ArchiveSetTop</td>
1358       <td>189.8</td>
1359       <td>&nbsp;</td>
1360     </tr>
1361     <tr>
1362       <td>\Dvtsw</td>
1363       <td>296</td>
1364       <td>&nbsp;</td>
1365     </tr>
1366     <tr bgcolor="#ddd">
1367       <td>\TestPriv</td>
1368       <td>&nbsp;</td>
1369       <td>3</td>
1370     </tr>
1371     <tr>
1372       <td>\bxUCM_support_7315sc</td>
1373       <td>4</td>
1374       <td>&nbsp;</td>
1375     </tr>
1376     <tr bgcolor="#ddd">
1377       <td>\HAL_test</td>
1378       <td>&nbsp;</td>
1379       <td>1.8</td>
1380     </tr>
1381     <tr>
1382       <td>\BCM_test</td>
1383       <td>10.2</td>
1384       <td>&nbsp;</td>
1385     </tr>
1386     <tr bgcolor="#ddd">
1387       <td>\UCM-CQTest</td>
1388       <td>&nbsp;</td>
1389       <td>31.1</td>
1390     </tr>
1391     <tr>
1392       <td>\delivertest</td>
1393       <td>0.5</td>
1394       <td>&nbsp;</td>
1395     </tr>
1396     <tr bgcolor="#ddd">
1397       <td>\UCMrmcomp</td>
1398       <td>&nbsp;</td>
1399       <td>0.4</td>
1400     </tr>
1401     <tr>
1402       <td>\UCM-Test</td>
1403       <td>3.6</td>
1404       <td>&nbsp;</td>
1405     </tr>
1406     <tr bgcolor="#ddd">
1407       <td>\BSE-SYS</td>
1408       <td>&nbsp;</td>
1409       <td>8.8</td>
1410     </tr>
1411     <tr>
1412       <td>\A1</td>
1413       <td>0.3</td>
1414       <td>&nbsp;</td>
1415     </tr>
1416     <tr bgcolor="#ddd">
1417       <td>\echostar</td>
1418       <td>600.6</td>
1419       <td>&nbsp;</td>
1420     </tr>
1421     <tr>
1422       <td>\bknittel_web_pvob</td>
1423       <td>0</td>
1424       <td>&nbsp;</td>
1425     </tr>
1426     <tr bgcolor="#ddd">
1427       <td>\bknittel_web</td>
1428       <td>&nbsp;</td>
1429       <td>0</td>
1430     </tr>
1431     <tr>
1432       <td>\ss-test</td>
1433       <td>1145.7</td>
1434       <td>&nbsp;</td>
1435     </tr>
1436     <tr bgcolor="#ddd">
1437       <td>\last</td>
1438       <td>&nbsp;</td>
1439       <td>0</td>
1440     </tr>
1441     <tr>
1442       <td>\bxUCM_proj</td>
1443       <td>3.4</td>
1444       <td>&nbsp;</td>
1445     </tr>
1446     <tr bgcolor="#ddd">
1447       <td>\bxUCM_support</td>
1448       <td>&nbsp;</td>
1449       <td>11.3</td>
1450     </tr>
1451     <tr>
1452       <td>\bxUCM_system</td>
1453       <td>0.8</td>
1454       <td>&nbsp;</td>
1455     </tr>
1456     <tr bgcolor="#33ccff">
1457       <td><b>Total</b></td>
1458       <td><b>7067.6</b></td>
1459       <td><b>7080.9</b></td>
1460     </tr>
1461   </tbody>
1462 </table>
1463
1464
1465                               <p class="entry-footer">
1466                                  <span class="post-footers">Posted by  at  4:29 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000441.html">Permalink</a>
1467
1468
1469                               </p>
1470                            </div>
1471                         </div>
1472                      </div>
1473
1474
1475
1476                      <h2 class="date-header">October  4, 2005</h2>
1477                      <a id="a000440"></a>
1478                      <div class="entry" id="entry-440">
1479                         <h3 class="entry-header">rgy_swtichover/Triggers</h3>
1480                         <div class="entry-content">
1481                            <div class="entry-body">
1482                               <ul>
1483   <li>Responded to IBM Rational Support regarding rgy_switchover</li>
1484
1485   <li>Added prohibit_operation to trigger list</li>
1486
1487   <li>Instituted the <i>evil twin</i> trigger</li>
1488
1489   <li>Obtained Chris' CQ merge scripts and started looking in to that</li>
1490
1491   <li>Went back to analyzing the PQA CQ data for invalid characters</li>
1492 </ul>
1493
1494                               <h3>rgy_switchover</h3>
1495
1496 <p>IBM Rational responded</p>
1497
1498 <blockquote>
1499   <p>Steven Chaves wrote:</p>
1500
1501   <p>Andrew,</p>
1502
1503   <p>Even though there is no documentation saying that about DHCP, UNIX, and Clearcase environment, I would agree with you that rgy_switchover is useless in your situation. It seems to have no problem if you have no Interop environment. I believe that documents show say that works for one platform not Interop environments.</p>
1504 </blockquote>
1505
1506 <p>My response to this was:</p>
1507
1508 <blockquote>
1509   <p>Where in the documents does it state that rgy_switchover is only supported in non interop environments?</p>
1510
1511   <p>I would think that it would be fairly common to have a Clearcase shop in which there are some Unix servers and many Windows clients - even Unix/Linux clients. You are saying that in such environments rgy_switchover is essentially broken in that it doesn't accomplish what it was intended to do.</p>
1512
1513   <p>I feel, but have not managed to proof yet, that if the Windows machine name resolved through DNS then rgy_switchover would work fine. Can you test this scenario? Create an environment where you have two Unix servers, one being the primary registry server and the other the backup registry server. Have 4 clients, 2 Unix and 2 Windows with DHCP assigned IP addresses. Configure 1 Windows machine with a machine name that resolves in DNS via nslookup to it's IP address. The other Windows client's machine name should not resolve in DNS. Same thing with the Unix machine, one resolves, one doesn't.</p>
1514
1515   <p>Then do rgy_switchover. I think you will find that all machines whose names resolve to IP addresses through DNS will switchover and all machines whose names don't resolve in DNS will fail to switchover.</p>
1516
1517   <p>If that's the case then the documentation should clearly indicate that rgy_switchover will fail on any machine whose name does not resolve to it's IP address in DNS.</p>
1518
1519   <p>Ray, why don't Windows machine names (e.g. my machine - ltsjca-adefaria) resolve in DNS using nslookup? I think it is possible to set it up so that Windows machine names resolve in DNS and are still DHCP assigned.</p>
1520 </blockquote>
1521
1522 <h3>Prohibit Operation</h3>
1523
1524 <p>Many companies add a trigger such that any new element created is immediately changed to be owned by vobadm. This way individuals do not own the element - vobadm does - which is closer to say "these aren't your elements - they are the company's". It also has the nice side effect of automatically disallowing certain potentially dangerous operations like rmelem from being done by non-owners. So then only vobadm can rmelems.</p>
1525
1526 <p>Here at Broadcom they take a different approach: Rather than changing ownership to vobadm they put a trigger on rmelem and rmver with an -nuser vobadm. I'm not sure I agree with not allowing users to rmver.</p>
1527
1528 <p>Luckily I was able to add -nusers vobadm to the "Type" line in triggers.dat and it was just passed along. We really should implement an "Options" line for additional options.</p>
1529
1530                               <p class="entry-footer">
1531                                  <span class="post-footers">Posted by  at 11:30 AM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000440.html">Permalink</a>
1532
1533
1534                               </p>
1535                            </div>
1536                         </div>
1537                      </div>
1538
1539
1540
1541                      <h2 class="date-header">October  3, 2005</h2>
1542                      <a id="a000439"></a>
1543                      <div class="entry" id="entry-439">
1544                         <h3 class="entry-header">SJ Vob move/Triggers</h3>
1545                         <div class="entry-content">
1546                            <div class="entry-body">
1547                               <ul>
1548   <li>Discussed how to best handle the upcomming SJ vob move</li>
1549
1550   <li>Added handling for UCMOBJECT triggers and the few additional triggers on the docs vob</li>
1551 </ul>
1552
1553                               <h3>SJ Vob Move</h3>
1554
1555 <p>I got to thinking over the weekend more about this vob move and trying to tie it to why we are moving the vobs. If we are trying to gain performance then how do we know that this move will accomplish that? It occurred to me that we have not adequately identified the performance problem we are trying to solve. If performance is the issue then just changing architectures is not likely to solve that problem.</p>
1556
1557 <p>Lacking any real description of the performance problem the users are experiencing the best we can do is optimize performance for vob service. In general, Rational recommends that you do not over load a server with too many vobs. More specifically you need to be concerned about the total size of your vob databases. What you are trying to do is insure that you have enough memory to fit the databases of the most commonly used vobs.</p>
1558
1559 <p>The old Solaris machine has 1 CPU and 4 gig of memory. The new Linux box also has 4 gig of memory but 2 CPUs. Observation reveals that the Solaris machine is not CPU bound - increasing CPU horsepower or number of CPUs will not increase performance.</p>
1560
1561 <p>I feel the best course of action at this point would be to identify the commonly used vobs and separate them between the Solaris and Linux machines thus decreasing the load on both servers, increasing the overall amount of memory (8 gig - 4 on one and 4 on the other) and allow for parallelization. Additionally, only 1/2 of the data need move. Need to sell this to Jennifer and Chin.</p>
1562
1563                               <p class="entry-footer">
1564                                  <span class="post-footers">Posted by  at  7:50 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000439.html">Permalink</a>
1565
1566
1567                               </p>
1568                            </div>
1569                         </div>
1570                      </div>
1571
1572                   </div>
1573                </div>
1574             </div>
1575          </div>
1576       </div>
1577    </div>
1578 </body>
1579 </html>