Message-Id:  <8904181343.AA27555@crdgw1.ge.com>
Date: Tue, 18 Apr 89 07:09 EST
From: "Claude Barbie - SDR - (203) 431 5524" <BARBIE%sdr.slb.com@RELAY.CS.NET>
Subject: Vaxstation 3100 and VMS 5 experiments
To: INFO-VAX@KL.SRI.COM

After having some fun putting 2 Vaxstations 3100 in operation, maybe some of
these experiments can be useful to others, so here it is.

1) Run under VMS 5.1B.  Actually a model 30 runs plain VMS 5.0 provided 
   that the following additions are made (from 5.1B):

	SYS$COMMON:[SYS$LDR]SYSLOA42D.EXE (and other LOA42?) (most important!!!)
	SYS$COMMON:[SYS$LDR]PKNDRIVER.EXE, DKDRIVER.EXE, VFDRIVER.EXE (color)
	 or VEDRIVER.EXE (B&W) (VF or VE are only needed for VWS 4.0, not for
	 DECW and they are not in VMS 5.0, 5.1 or 5.1B)
	SYS$COMMON:[SYSUPD]VMSLICENSE.COM (which knows about HW_MODEL 58, 59)
	SYS$COMMON:[SYSEXE]LMF$LURT.DAT (same but mostly important)

	This can be useful in an existing 5.0 LAVC before it can be upgraded
	to 5.1B, just add the missing pieces above and type >>>B ESA0

2) Can make a running system on the RZ22 disk (52MB) assuming you have
   VMS050 (and 051) save sets on line (ie on a large cluster disk thru DECnet)
   but not VMSU1051 (ie VMS 5.1B).

	Boot diskless in an NI cluster and then:
	BACKUP /IMAGE decnet::vms050.b/save DKA300:/init
	MOUNT DKA300/over=id
	Copy from_somewhere:SYSLOA42%.EXE, PKNDRIVER, DKDRIVER, VFDRIVER, -
	VMSLICENSE.COM, LMF$LURT.DAT to_where_they_belong:*
	Backup from:VMS051.%/Select=(SYSINIT.EXE,SYSGEN.EXE,VMB.EXE,SYSBOOT.EXE
				     ,STACONFIG.EXE, STANDCONF.EXE, STASYSGEN
				     ,CONFIGURE, CPULOA, EXCEPTION
				     ,PAGE_MANAGEMENT, SYSDEVICE)
		and replace the 5.0 images with the 5.1 ones otherwise VMS
		does not come up
	Place vms050.a, .c, .d, VMSMUP050.A on DKA300:[000000]
	Boot the 3100 from its disk.  It continues the VMS050 installation
	Then you may do the mandatory update, the special fix to update from
	BI50 to A5.0, 5.0-1, 5.0-2 (make sure to have a spare copy of the
	5.1B LMF$LURT.DAT since 5.1 replaces it and without a 5.1B one you
	cannot load ANY license because CPU type 59 is unknown in pre 5.1B
	LMF$LURT.DATs)

3) General remark about software installation across DECnet

	$ @ Sys$Update:VmsInstal vms051 node::disk:[dir]

	works great provided that [dir] and vms051.% are unprotected
	since "username passwords" strings confuse DCL no matter how many
	times the quotes are "doubled", logical names don't help either.

4) SYS$COMMON:[SYSUPD]VMSLICENSE.COM contains the VMS Service Update PAKs
   that get applied through a call to VMSINSTAL.  Interesting reading indeed!
   $ LICE MODIFY VMS/UNIT=2000 /DATA=SYS$SPECIFIC:[SYSEXE]LMF$SYSTEM.LDB works
   fine including to load DECWINDOWS.  Not lousy at all.

5) Don't omit to register the VAX-VMS license delivered with the 3100 or you
   might lose any opportunity to have unlimited login access to VMS.
   And I guess no one wants unlimited access to a machine after purchasing a
   license that was precisely designed to limit access to a single user.

6) Read thru CLUSTERCONFIG.COM and find some diagnostics insisting on "not 
   a DSSI-connected node".  I knew about CI, NI, MI clusters.  DSSI around the
   corner?

7) LMF can be patched to avoid confusion as follows:

IMAGE FILE BEING PATCHED:	"SYS$COMMON:[SYS$LDR]SYSLICENSE.EXE;1"
JOURNAL FILE:			"DUA0:[DISM]SYSLICENSE.JNL;1"

%PATCH-I-NOLCL, image does not contain local symbols
PATCH>SET MODE INS
PATCH>DEP 34
NEW>  'MOVL #1,R0'
NEW>  'RET'
NEW>  EXIT
old:	00000034:  MOVAL   @#7FFEFFB8,R0
new:	00000034:  MOVL    #01,R0
new:	00000037:  RET     
PATCH>UPDATE
%PATCH-I-WRTFIL, updating image file DUA0:[DISM]SYSLICENSE.EXE;1

Overall I found VMS 5.x an impressive software packaging. The VMS reorganization
lets you mix and match various related versions of VMS subassemblies and
still run!

On the down side, purchasing a model 40 but not the full server configuration
deprives you from the DECNET full routing and DESKtop VMS licenses.
Fortunately, end node is enough even for an NI cluster boot node if you have a
real router somewhere else on Ethernet.  


Hope all this does not add to the confusion.

Claude Barbe - Schlumberger-Doll Research - (CSNET: barbe@sdr.slb.com)