home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18083 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  7.4 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!U.WASHINGTON.EDU!DEREK
  2. From: DEREK@U.WASHINGTON.EDU
  3. Newsgroups: comp.os.vms
  4. Subject: Plans for mixed Alpha/VAX cluster... WARNING!
  5. Message-ID: <C4A431AEA25FE48CFF@MAX.U.WASHINGTON.EDU>
  6. Date: 17 Nov 92 01:19:00 GMT
  7. Sender: usenet@ucbvax.BERKELEY.EDU
  8. Organization: The Internet
  9. Lines: 146
  10.  
  11. OK, folks, I have been meaning to write about the following problem for
  12. quite some time, but just hadn't gotten around to it.  A posting by
  13. Don Stokes (don@vuw.ac.nz), however, catalyzed me into action!  :)
  14.  
  15. Last May, Andy posted the following note.  (I don't know who Andy is either.
  16. He only signed with his first name.)  
  17.  
  18. >From:    IN%"INFO-VAX@SRI.COM" 18-MAY-1992 03:25
  19. >Subj:    Upgrade VMS 5.0-2 to 5.5 failure...
  20. >
  21. >Say... *I* had problems upgrading from VMS V5.0-2 to VMS 5.5... I got some
  22. >kind of error saying it couldn't find the "CHGSYSPAR" program... this was
  23. >right at the end of phase 1, when it was setting the system parameters to
  24. >reboot and start phase 2.  Very frustrating... I wound up having to install
  25. >VMS as opposed to upgrading, then had to restore & reinstall pertinent files...
  26. > 
  27. >Andy
  28.  
  29. Well, I had an experience with this problem, too!
  30.  
  31. About two years ago, we ran into a weird problem during a VMS upgrade to V5.4.
  32. Things were proceeding along "swimingly" we reached phase 2, at which point
  33. it bombed out with a "file not found" error on the file "CHGSYSPAR.EXE".
  34. The folks who were doing the upgrade tried it again, and it failed again with
  35. the same error.  They made a cursory examination of the KITINSTAL procedure,
  36. and decided that we were somehow missing the image.  So they restored the
  37. file from the distribution media, and tried again.  It failed again.  They
  38. went back to the KITINSTAL and became very puzzled, because they discovered
  39. that the image was RETRIEVED from the VMSnnn.A saveset!  "Obviously", the
  40. upgrade procedure had a logic flaw in it.  (It had just finished deleting 1100
  41. or so files, and it looked like it had deleted the file it had just restored.)
  42. So they unpacked the .A saveset, modified KITINSTAL.COM to copy CHGSYSPAR
  43. from a copy saved specifically for this purpose, re-created the .A saveset,
  44. and completed the upgrade.  Whew!
  45.  
  46. I started looking at the problem the following Monday.  This was quite a
  47. puzzle.  I researched the problem for quite some time.  Colorado was stumped.
  48. No one had reported such problems before.  I even spoke with the engineer who
  49. was then responsible for VMSINSTAL.  He hadn't heard of this problem, either.
  50. Well, we just wrote it off as random "cosmic ray" (AKA an "alpha" particle) :)
  51. which struck multiple times.   :)
  52.  
  53. It wasn't until about 6 months later that I solved this problem.
  54.  
  55. So, what does Don's posting have to do with any of this?  Good question!
  56. (Anyone else appreciate James Burke's "Connections", etc., series?)
  57.  
  58. Don wrote:
  59.  
  60. >...  [VMS$COMMON] is used by practically nothing at all.  I
  61. >smashed my system disk up a while ago, and made a fairly hairy recovery.
  62. >Several  days later I discovered that [VMS$COMMON] hadn't been re-created,
  63. >but the system hadn't noticed.  Obviously, [SYS0.SYSCOMMON] was present,
  64. >and that's all that mattered.
  65.  
  66. My guess is that Don did not perform an IMAGE restore of his system disk,
  67. but that doesn't really matter for my point.  However, it COULD produce
  68. the problem that both we and Andy experienced.
  69.  
  70. So, what happened some six months after our problem?  Well, I decided to
  71. do an "ANALYZE /DISK /NOREPAIR" on the system disk of the system which had
  72. had the problem.  In doing so, I discovered an EXTRA SYSCOMMON.DIR!  In
  73. going back through our logs, I discovered that a little more that three
  74. months BEFORE our upgrade, several images had "disappeared" from the
  75. SYS$SYSTEM directory.  To correct the problem, without shutting down the
  76. system, someone had performed a BACKUP "file restore" of the directory
  77. tree [SYS0.SYSCOMMON].  This created a SYSCOMMON.DIR which was NOT
  78. linked with the VMS$COMMON directory, which sounds like the situation
  79. Don says he had (has).
  80.  
  81. (As for why the files started disappearing in the first place, I seem to
  82. recall tracking it back to an installation of RDB the day before.)
  83.  
  84. So, why is this a problem, and how would it cause a problem for the upgrade?
  85. Well, an upgrade of VMS uses the SYSF root as a temporary holding place for
  86. some of the new images.  In order to keep track of both the old and new images,
  87. the KITINSTAL procedure creates, and uses, several names for the various
  88. directories.  These are:
  89.  
  90.       "old_sysexe"    old [SYSEXE] in SYS$SPECIFIC:, such as
  91.                         DUA0:[SYS0.SYSEXE]
  92.  
  93.       "new_sysexe"      new [SYSEXE] in "new" SYS$SPECIFIC:,
  94.                         i.e., DUA0:[SYSF.SYSEXE]
  95.  
  96.       "clroot_sysexe"   [SYSEXE] directory in the CLUSTER common root, if
  97.                         such exists.  You might expect this to be defined
  98.                         as the translation of SYS$COMMON:[SYSEXE],
  99.                         DUA0:[SYS0.SYSCOMMON.SYSEXE], but it is actually
  100.                         defined as DUA0:[VMS$COMMON.SYSEXE]!
  101.  
  102. Using these symbols, the procedure first deletes any "old" copies of specific
  103. upgrade-related files, such as CHGSYSPAR.EXE, from the "old_sysexe" and
  104. "clroot" directories.  Then, it copies new files from the distribution to
  105. both the "new_sysexe" and "clroot_sysexe" directories.
  106.  
  107. Now, IF SYS$COMMON is the same directory as [VMS$COMMON], everything is OK.
  108. In fact, things would be OK except for one thing.  KITINSTAL invokes the
  109. procedure VMS$UPG_SYSPARFILES.COM which, naively, tries to run the new
  110. CHGSYSPAR image out of SYS$SYSTEM, and NOT out of "new_sysexe"!  Granted,
  111. it "should" work, but I still insist that this is a logic error.  After all,
  112. SYS$SYSTEM is defined to point to the OLD system, which is under demolition.
  113.  
  114. Now that you have all heard my tale of woe, you should all be asking 
  115. "why did the upgrade succeed if the directories were so messed up?"
  116. After all, SYSCOMMON.DIR still has all of the OLD images and files left in
  117. it -- doesn't it?
  118.  
  119. Yes, it does.  So didn't this cause a problem for us right after we completed
  120. the upgrade?  One would expect at least a FEW ident and cld-image mismatches.  
  121. It turns out that one of the last things done by the upgrade is to execute a
  122. command like:
  123.  
  124.       $ SET FILE /ENTER=[SYS0]SYSCOMMON.DIR VMS$COMMON.DIR
  125.  
  126. This pretty effectively "loses" our old, "bad" SYSCOMMON directory, and
  127. "fixes up" everything for the new version.
  128.  
  129. Except....  for the lost files, which, in our case, used up almost 300,000
  130. blocks of space.  Fortunately, we are using a large disk, so we weren't
  131. adversely impacted by this.
  132.  
  133. Yes, we ran for 3 months with an "incorrect" directory structure, and you
  134. can too ... but, don't expect an easy upgrade if you do.
  135.  
  136. And, yes, after I discovered the "root"  :)  of the problem I contacted the
  137. engineer.  He effectively said "Oh, yeah.  That could be a problem."  I
  138. suggested that he modify the KITINSTAL procedure to CHECK for, and notify
  139. the user of, an invalid directory structure.  Nonetheless, no change has
  140. yet been made.  Furthremore, as of VMS V5.5, the VMS$UPG_SYSPARFILES
  141. procedure STILL invokes CHGSYSPAR out of SYS$SYSTEM.
  142.  
  143. -Derek S. Haining
  144.  University Computing Services
  145.  University of Washington
  146.  Seattle, Washington  98195 
  147.  (206) 543-5579
  148.  
  149.  DEREK@MAX.BITNET
  150.  DEREK@MAX.U.WASHINGTON.EDU
  151.  
  152.  
  153. Questions?  Comments?  Always happy to receive them -- even if they ARE
  154. flames.  It lets me know that SOMEONE bothered to read what I so painstakingly
  155. wrote!  :)
  156.  
  157.