Conference vaxaxp::vmsnotes

587.0. "7.1 upgrade, system dead" by ALLOUT::STEWART (Bob Stewart) Tue May 13 1997 17:46

Under the threat that my VMS 6.2 Alpha workstation was going to fail to boot on
May 19th, 1997, I decided to upgrade to VMS 7.1 on May 5th, 1997. The most
immediate effect of the upgrade was that the system failed to boot on May 5th,
1997, and a good part of May 6th, 1997. With the able assistance of friends in
Spit Brook, the system is now working almost as well as ever, and may be safe
until the real Y2K problem rolls around.

Anyway, for the benefit of anyone else upgrading to 7.1, here is a blow-by-blow
report, with various things to watch for.

***********

Read the upgrade manual: The upgrade manual said that firmware might need to be
upgraded. It said that I had to shut down the system to find out what revision
I currently have. This is an irritation. It is especially irritating since the
manual threatens that if you don't upgrade, the system will print out a message
telling you what version you now have, as it crashes. This suggests that VMS
must have a way of finding out what the version is. So maybe the manual could
tell me what the version is, and save me a reboot? Maybe the upgrade procedure
could look at the version, and tell me?


Firmware upgrade: The booklet does not describe what to do after the upgrade
completes! No clue on the screen either, exit is not in the list of commands.
Scary, sitting there with firmware exposed, and no documented way to exit.
Some sort of procedure should be given. Guess I better have a talk with the
firmware guys.  :-)


First try at upgrading VMS: The upgrade procedure stopped, complaining about
[SYS0.SYS$LDR]SYS$CPU_ROUTINES_0D02.EXE;2 being in specific instead of common. 
I sure didn't put it there..., some patch kit for 6.2 must be busted. Why
couldn't the upgrade do the rename itself? Also, the display said to use option
4 to rename it from DCL, it should have said option 7.


Upgrading VMS:


Default install of PC management station on workstations is silly.


The upgrade procedure did not display the required and available disk space as
claimed in the manual. (I did not take defaults, maybe it only works for
default upgrades?)


The installation of DECW 1.2-4 that happened as part of the upgrade did not
bother to ask whether I wanted the new desktop to be my default desktop. It
is documented to ask this question in the DECW upgrade manual.


Upgrade Reboot:


Reboot failed after the upgrade! System useless! The symptom is a PROCGONE
bugcheck with DECram as the current process. Booting the CD and running
ANAL/CRASH on the dump shows R0 = 2398. This is "Version Mismatch, please
relink". The cause of the failure is a version mismatch of the DECRAM execlet.
Rename decram$execlet to get around this. Good thing this works, because the
various DECram files on the system give no clue on how to un-install DECram.
Does anyone know? I suggest getting rid of it before upgrading to 7.1 instead
of afterward. The upgrade manual ought to warn the user about obsolete
execlets, and describe how to look for them. The upgrade procedure really ought
to look for obsolete execlets BEFORE upgrading my system into oblivion!


It is interesting that the upgrade process first reboot attempt takes a dump
even though I had the system set up to not save dumps. It came in handy this
time. On the other hand, I can see where it might result in an unexpected
"device full" on the system disk. Having the system disk suddenly full, on top
of being unbootable, could get really awkward. It might pay to have an extra
200,000 blocks more available on the system disk than the upgrade manual says
you will need. Maybe the upgrade manual should document this little bit extra?


Post-upgrade, trying to get the system happy again:


Manual section 8.5 says that new templates are added for "some" com files. It
should say which ones, otherwise every person doing upgrades has to look for
themselves. You can't tell for sure, except by guesswork from the dates.

In this case, it appears that systartup_vms.com is the only template file
changed. Since the old template file was deleted by the upgrade, there is no
way to know for sure what changed. It appears that starting decnet has changed.
The description of how decnet gets started (by magic?) is a bit lacking...


DECnet failed to start following the upgrade. So much for the upgrade manual
claim that upgrading to DECnet-Plus will be trouble free. The upgrade manual
gives no clue what to do. The release notes say to look at a manual on the doc
CD. Be careful, read the manual. It tells you to run the net$config procedure,
but there are a bunch of tricky things this com file does, like delete all your
symbols, and set a run-once flag on the FAST option. 

By the way, if you are keeping a full e-net database on your node, be prepared
for the net$config procedure to run for a looooooooooong time.

After you run net$config, it claims DECnet has started, but NOTES for instance
still will not work until you reboot yet again. Some products only work if they
start before DECnet I guess.


The post-upgrade directions say to install the security update for TCPIP. Why
the upgrade procedure didn't just do it is a mystery. The manual does not tell
us the PRODUCT NAME to be used with the PCSI  installation command for the
update, or how to select which PCSI file in the directory. I used another
infinitely slow reboot from the CD to do the update.


Changes from the upgrade broke my DCL system-checker code in a couple minor
ways. NETSERVER.LOG is now NET$SERVER.LOG, and SHOW MEM/POOL/FULL output has
changed. Not the upgrade's fault, these are undocumented.


There is some new file SYS$SYSROOT:[SYSMGR]NET$NCP_APPLICATIONS.COM;43 that
builds up new versions very quickly. This is going to become a nuisance if it
doesn't settle down. I have no clue what it does, or why it needs so many
versions saying the same thing.


The first run of my nightly backup com file after the upgrade, failed! It
worked fine with 6.2. The error is truly strange. Here is the offending command
and the 7.1 DCL error

$   Backup /Verify/norewind/Ignore=Interlock -
      dka0:[SYS0.SYSCOMMON.SYSMGR]-
      /EXCLUDE=( [SYS0.SYSCOMMON.SYSMGR]SECURITY.AUDIT$JOURNAL;* , 
 [SYS0.SYSCOMMON.SYSMGR]ucx*.com;* ,  [SYS0.SYSCOMMON.SYSMGR]posix*.com;* , 
 [SYS0.SYSCOMMON.SYSMGR]*.template;* ,  [SYS0.SYSCOMMON.SYSMGR]*.com;1 )  -
%DCL-W-NOPAREN, value improperly delimited - supply parenthesis
 \[SYS0.SYSCOMMON.SYSMGR]*.COM;1\
      MKB600:CMGR6-MAY-1997.b /Save_Set /block_size = 32768  /label= INDIAN


******** The /EXCLUDE line was wrapped with the editor for readability, it was
actually one long line, created by symbol substitution, so don't be bothered by
the "missing" continuation characters. **********

The error message is caused by the blank space between 1 and ) !!!!!!!!!
If this space is removed, DCL eats the command! Note that it has to be that 
exact space character, it is not the line length that is the problem, removing 
some other space to shorten the line has no effect. Version 6.2 DCL did not 
give this error.


The End!  (so far...)

    re .0
    
    I hope you are going to submit all that via formal channels. At least
    some of it would seem to require Engineering's attention.

    re: .0
    
    just a reminder: plain upgrading the OS to V7.1 alone will *not*
    necessarily prevent you from hitting the 10K delta-time problem.
    What it does, it saves you from installing the patch, because V7.1
    already has that fix included.
    
    But if your current programs running on V6.2 flavor are not relinked,
    and they were linked for example /NOSYSSHR, you'r still in trouble.
    
    Bottom line: upgrading to V7.1 saves you from installing the patch,
    but you still need to do the investigation!
    
    BTW, you can view the console version from under SDA via 
    SDA> CLUE CONFIG.
    
    /cmos<