From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX"  7-JAN-1991 21:52:09.57
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	VMS 5.4-1A upgrade comments

Received:  by crdgw1.ge.com (5.57/GE 1.80)
	 id AA16507; Mon, 7 Jan 91 21:39:31 EST
Received: From RELAY.CDNNET.CA by CRVAX.SRI.COM with TCP; Mon,  7 JAN 91 14:16:07 PST
Received: by relay.CDNnet.CA (4.1/1.14)
	id AA13971; Mon, 7 Jan 91 14:08:48 PST
From: <Ed.Wilts@bsc.galaxy.bcsystems.gov.bc.ca>
Date:  7 Jan 91 21:05
To: INFO-VAX <INFO-VAX@sri.com>
Message-Id: <72504170101991/8897 01>
Subject: VMS 5.4-1A upgrade comments

 For those that are concerned about the VMS 5.4 upgrade, here's some 
 comments after our cluster upgrade.  Our configuration includes 2 8650s, 3 
 6440s, an 8800, and an 8830.  There are 2 system disks in the cluster.  We 
 normally have about 1000 users on our cluster at any one time, and try to 
 run 7x24.  We did a rolling upgrade from VMS 5.2 to VMS 5.4-1A.  We had no 
 choice but to upgrade with our 9420 arriving (it showed up today, 2 days 
 after our software upgrade).  VMS 5.4-1A finally arrived 2 days before our 
 upgrade started; we had VMS 5.4-0A on our testbed since mid-October.  I'm 
 writing this on Monday afternoon; the upgrade started Saturday.  Not all 
 problems may have been identified yet.
 
 Total time before all systems up on 5.4-1A:  24 hours
 We rolled from VMS 5.2 to 5.3 on half the cluster, booted it, then rolled 
 the second half to 5.3 and 5.4-1A, and finally did the first half from 5.3 
 to 5.4-1A.  We did not upgrade our LAT software since we didn't have 
 adequate time to test it first.
 
 Problems encountered:
 
 Jnet incoming mail crashes the Mail_Daemon process with a bad parameter 
 value.  Joiner come through with a patch this morning in response to an 
 e-mail message yesterday.  Great service!
 
 The command file VMSU1054-PURGE.COM that is supposed to be run to purge 
 system files folling the 5.4-1 upgrade does not work for 5.4-1A since it 
 does an explicit version check.  We did NOT put up 5.4-1 because it may not 
 boot a 6440.  5.4-1A is a complete replacement for 5.4-1.  The workaround 
 is to edit the file and take out the version check.
 
 The most important problem (for us) was the bug apparently introduced in 
 5.3-2 with Sysgen (we never ran 5.3-2 so we never saw it before).  On one 
 of our 8650s, we have 168 TX ports.  Under 5.2, we had a combination of 
 auto- and manually-configured TX and TY devices.  Under 5.4-1A, the TY 
 terminals came up as TX, and our manually connected TX devices failed to 
 connect.  Because of the large number of asynch ports, we had to compress 
 the vector addressing.  With a bug in SYSGEN, command parsing lost all 
 semblance of sanity, and commands longer than 80 characters are parsed 
 sporadically and incorrectly.  Some qualifiers may be ignored, and not just 
 those at the end of the line, either.  The only known workaround is to 
 shorten all your connect statements to less than 80 characters.  Although 
 DEC identified this in 5.3-2, they did not fix it in 5.4-1A nor put it into 
 the release notes.  Software support did correctly and quickly identify our 
 problem, though, but our upgrade was slowed by 2 hours.
 
 The upgrade was time-consuming but fairly straight-forward.  All-in-all, a 
 fairly successful upgrade with no major problems.
 
 Anyone requesting further info can contact me via e-mail or phone.
        .../Ed     Preferrred:  Ed.Wilts@BSC.Galaxy.BCSystems.Gov.BC.CA
Ed Wilts            Alternate:  EdWilts@BCSC02.BITNET    (604) 389-3430
B.C. Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8