Conference koolit::vms_curriculum

I'm posting a draft of Chapter 2: Building a VAXcluster for the new two day 
VAXc course. I'd appreciate your review comments within a few weeks.

    SUPER::ES$REVIEW:[CLUSTER_TWODAY]CLUSTER_CHAP2.PS

While not perfect, I did have a chance to update the section on setting up
queues (and files to move off the system disk). I left it so examples show both
V5.5 and prior. I can always update the other, or move them to an appendix. It
just seems like there are a lot of customers running older versions of VMS.

Updated also was starting the LAT. I removed reference to LTLOAD.COM since
it's only one filename change. I can always put it in an Appendix, but I figured
it would be simple to cref LTLOAD.COM to LAT$SYSTARTUP.COM.

There's an index, TOC, headings fixed, introductory paragraphs and little
tidbits (TMSCP, typos...) throughout. Two pieces that were separated, Layered
Products and Licenses, were brought together in: "the steps needed to build a
VAXclusters."

I still need to update the lock managment piece, spell check, and look for nits.
I have not seen the final copy, so there may be some pagination problems.
However, I was told to post it.

				    Regards,

				    Paul M.

Paul,

I don't have the time right now to go after nits, but I am concerned about
the leap from Chap 1 to Chap 2.  Page 1-8 is offered as a "review" list of the 
information needed to build a VAXcluster.  "Review" from where?  Chap 1 simply
gives us an overview of the hardware and software without going into any 
of the specifics needed for a CLUSTER_CONFIG.COM session (ie ALLOCLASS, DECnet
Nodename and Address, Hardware Address, System Root, System Disk, etc.).

The next few pages discuss VMS installations, Upgrades, Licenses, LP installs 
and then NETCONFIG.COM in the same detail (or lack of detail) as in the old
VAXcluster class.  We then dive into the examples of CLUSTER_CONFIG.COM from
the old class.  This new course completely ignores the PLANNING module, and I
cannot emphasize strongly enough that the disasters WILL occur without it.

Our students come to us to learn how to avoid the pitfalls in VAXcluster 
Management.  We're not doing that here....

				Susan

I lied; I do have the time for one quick nit.  Would you consider cleaning
up the MODPARAMS.DAT file starting on p.1-61?  I had something in mind 
along the order of:

!TITLE:		MODPARAMS.DAT (for node BARNUM -- [SYS0]
!AUTHOR:	
!DATE:		15-MAY-1992 16:36
!
!General Comments
!
!VAXcluster support
SCSNODE = "BARNUM"	!DECnet nodename
SCSSYSTEMID = 		!DECnet address (area * 1024 + nodenumber)



And so on.....

I'd also like to see an example of a COMMON MODPARAMS.DAT file.  Systems may 
very well be sloppy out in the real world, but I firmly believe that we should
be setting good examples in our material.

Yes, as a matter of fact, I do want it all.....

			Susan

The "review" slipped by...

About what is needed to build a VAXcluster:

	We discussed some of that before. We do have the constraint 
	of teaching what SYSNET covers in the two day version for the
	SYSMAN I and SYSMAN II folks - building. Later comes the planning 
	and hardware during the 3 day version for all (SYSMAN and SYSNET).

	The roots and disk should be covered in the INTRO module of the 
	2 day version -  INTRO. As far as the rest (ALLOCLASS, addresses...),
	it is backwards. Can we include what they need during the build?
	It seems the module is large enough. Besides, then the SYSNET folks 
	lose out. More thought is required on the design, I agree. Quick fixes
	always sound good, until you try their implementation. 

About the detail or lack thereof:

	Be more specific when you get a chance. For example, you don't want to
	define the steps to do a VMS installation do you? No, and some of the
	incomplete steps were eliminated. But I would think that we might want 
	to expand on the disk and boot servers allocation.

I'll clean up MODPARAMS.DAT. Regarding the common one:

	I would think that you would want to keep them autonomous. Do you have
	a sample of one?

							Regards,
								
							Paul
	

Paul,

>About what is needed to build a VAXcluster:
>
>	We discussed some of that before. We do have the constraint 
>	of teaching what SYSNET covers in the two day version for the
>	SYSMAN I and SYSMAN II folks - building. Later comes the planning 
>	and hardware during the 3 day version for all (SYSMAN and SYSNET).
>
>	The roots and disk should be covered in the INTRO module of the 
>	2 day version -  INTRO. As far as the rest (ALLOCLASS, addresses...),
>	it is backwards. Can we include what they need during the build?
>	It seems the module is large enough. Besides, then the SYSNET folks 
>	lose out. More thought is required on the design, I agree. Quick fixes
>	always sound good, until you try their implementation. 

I thought the SYSNET Curriculum was going to be fixed first so we wouldn't 
break this one too.  Doesn't anyone up the food chain agree that building 
before planning is crazy?

>About the detail or lack thereof:
>
>	Be more specific when you get a chance. For example, you don't want to
>	define the steps to do a VMS installation do you? No, and some of the
>	incomplete steps were eliminated. But I would think that we might want 
>	to expand on the disk and boot servers allocation.

No, please don't start with installing VMS.  However, I'd like to see more
than just a list of the steps.  In other words, we need explanations along
with those bullets.  Before running CLUSTER_CONFIG.COM, I want my students 
to understand the questions and the affect their answers will have.  If
the procedure asks them for a DECnet name, why?  If it asks for the DECnet 
address, why?  What will happen if the SCSNODE and SCSSYSTEMID parameters 
don't match the DECnet info?  What does the procedure do if I serve disks, 
allow conversational bootstraps on satellites, specify a local disk for 
page and swap files, etc.  Cookbooks don't work!

>I'll clean up MODPARAMS.DAT. Regarding the common one:
>
>	I would think that you would want to keep them autonomous. Do you have
>	a sample of one?

These examples may be a little extreme; they are from our Easynet node which 
is a boot server for a hidden area and are commented to the hilt (and to my
liking).  The first one is for the boot server, the second is for one satellite
(all the other satellites are similar, with the obvious changes in name and id)
and the third is the common file called from all the satellites.  References
to node DUNE are for a boot server in a 14 node NI cluster (3600 boot server; 
3100 satellites running MOTIF) that has been tuned within an inch of its
life.  Date fields are updated upon revision.....  I'm a stickler for precision
and consistency only because it makes my life easier as a system manager.  
I currently manage about 20 nodes here.  Big VAXclusters are a pain to upgrade
if you have to edit a lot of MODPARAMS.DAT files.  This makes my job more
manageable.

_________________________________________________________________________
!Title:		MODPARAMS.DAT (node = MELKOR, root = SYS0)
!Author:	TONY SWIERKOWSKI
!Date:		13-JUN-1991 11:15 
!
!
!This is the MODPARAMS.DAT file for the boot server and does NOT use the
!common MODPARAMS.DAT file like all the satellites.
!
! This ident stuff is specific to the boot server...
!
SCSSYSTEMID=31304		!DECNET address 30.584 - (area * 1024 + member#)
SCSNODE="MELKOR"		!Master node of the EASYNET cluster in area 30
!
! This is the cluster stuff...
!
NISCS_CONV_BOOT=0	!Conversational boot over the network is irrelevant
NISCS_LOAD_PEA0=1	!Load PEDRIVER, (NI-SCS) port driver
NISCS_PORT_SERV=0	!Flag bits for PEDRIVER clear, so no checking...
INTERCONNECT="NI"	!Showed up after CLUSTER_CONFIG "CHANGE"...
BOOTNODE="YES"		!Showed up after CLUSTER_CONFIG "CHANGE"...
VAXCLUSTER=2		!Always load cluster code (and also SCSLOA)
EXPECTED_VOTES=1	!Since only one system contributes a vote...
VOTES=1			!The boot server is the only voting member...
RECNXINTERVAL=20	!Polling interval to a remote system
DISK_QUORUM=""		!This cluster has no quorum disk
QDSKVOTES=1		!Due to DISK_QUORUM being null, this is irrelevant
QDSKINTERVAL=10		!Due to DISK_QUORUM being null, this is irrelevant
ALLOCLASS=1		!Host uses $alloclass$ddcu device names...
LOCKDIRWT=0		!I think this is the default...
MSCP_LOAD=1		!So all disks can be seen by other nodes
MSCP_SERVE_ALL=1	!So all disks can be seen by other nodes
MSCP_BUFFER=200		!Number of pages for MSCP server's local buffer
!
! So system files aren't recalculated...
!
PAGEFILE=80000		!Plagerized from DUNE...
SWAPFILE=25000		!Plagerized from DUNE...
DUMPFILE=0		!Not using one for now until I get a bigger disk...
!
! Dynamic memory areas fairly high to assist performance...
!
MIN_NPAGEDYN=1100000	!NOTE: NETACP crashes if less than 1000000...
MIN_PAGEDYN=1000448	!Plagerized from DUNE...
MIN_SRPCOUNT=1800	!Plagerized from DUNE...
MIN_IRPCOUNT=1400	!Plagerized from DUNE...
MIN_LRPCOUNT=150	!Plagerized from DUNE...
MIN_LRPCOUNTV=500	!Plagerized from DUNE...
!
! Global memory resources fairly high to accomodate installs, etc.
!
MIN_GBLPAGFIL=12200	!Minimum for CDD-Plus, (I forget which version...)
MIN_GBLPAGES=60000	!Plagerized from DUNE...
MIN_GBLSECTIONS=512	!Increased after V5.4
!
! Lock Manager Stuff...
!
MIN_LOCKIDTBL=1200	!Plagerized from DUNE...
MIN_RESHASHTBL=2048	!Can't remember what needed this...
!
! Miscellaneous stuff...
!
MIN_LNMSHASHTBL=512	!Plagerized from DUNE...
MIN_MAXBUF=5000		!Max size of buffered I/O buffer...
VIRTUALPAGECNT=75000	!So I can shoot big dumpfiles from any machine...
!
! Terminal stuff...
!
TTY_SPEED=15		!Low byte is xmit (9600), high byte is rcv (xmit)
TTY_DEFCHAR2=%X21003100	!(NOAUTOBAUD,NOSETSPEED,LINE,INSERT,ANSICRT,DECCRT)
TTY_TYPAHDSZ=1500	!Terminal type ahead buffer
!
! Process stuff...
!
MIN_PROCSECTCNT=45	!Number of section descriptors in the PHD
PIOPAGES=350		!For ALL-IN-1 V2.4
PQL_DENQLM=150		!ENQLM for $CREPRC/RUN processes
PQL_MENQLM=150		!Min number of locks queued for $CREPRC/RUN processes
RMS_DFMBFIDX=2		!Multibuffer count on indexed files
RMS_DFNBC=16		!Block count for network access to remote RMS files
MIN_WSMAX=16384		!No working sets beyond 8MB...


_________________________________________________________________________
!Title:		MODPARAMS.DAT (node = RING01, root = SYS10)
!Author:	TONY SWIERKOWSKI
!Date:		13-JUN-1991 17:41 
!
!
SCSNODE="RING01"
SCSSYSTEMID=64580
!
!Include the values from the common MODPARAMS.DAT file.  Any changes that 
!affect all satellites should be added to the common file.
!
AGEN$INCLUDE_PARAMS SYS$COMMON:[SYSEXE]COMMON_MODPARAMS.DAT


______________________________________________________________________
!Title:		COMMON_MODPARAMS.DAT (node = All satellite nodes)
!Author:	TONY SWIERKOWSKI
!Date:		13-JUN-1991 18:13 
!
!
!This is the common MODPARAMS.DAT file called from each satellite's specific
!MODPARAMS.DAT file.  Add values to the end of this file that affect all the
!satellites.
!
! This is the cluster stuff...
!
NISCS_CONV_BOOT=1	!Satellites can do conversational boots
NISCS_LOAD_PEA0=1	!Load PEDRIVER, (NI-SCS) port driver
NISCS_PORT_SERV=0	!Flag bits for PEDRIVER clear, so no checking...
INTERCONNECT="NI"	!Showed up in RING01's MODPARAMS...
BOOTNODE="NO"		!Showed up in RING01's MODPARAMS...
VAXCLUSTER=2		!Always load cluster code (and also SCSLOA)
EXPECTED_VOTES=1	!Satellites hang upon boot server's death...
VOTES=0			!Satellites don't contribute anything...
RECNXINTERVAL=20	!Polling interval to a remote system
DISK_QUORUM=""		!This cluster has no quorum disk
QDSKVOTES=1		!Due to DISK_QUORUM being null, this is irrelevant
QDSKINTERVAL=10		!Due to DISK_QUORUM being null, this is irrelevant
ALLOCLASS=0		!Satellites use nodename$ddcu device names...
LOCKDIRWT=0		!I think this is the default...
MSCP_LOAD=1		!So all disks can be seen by other nodes
MSCP_SERVE_ALL=2	!Serve only locally-attached, (non-HSC) disks
!
! So system files aren't recalculated...
!
PAGEFILE=0		!I hard-wire the size during P5 "backups"
SWAPFILE=0		!I hard-wire the size during P5 "backups"
DUMPFILE=0		!I hard-wire the size during P5 "backups"
!
! Dynamic memory areas fairly high to assist performance...
!
MIN_NPAGEDYN=900000	!Plagerized from DUNE...
MIN_PAGEDYN=1000448	!Plagerized from DUNE...
MIN_SRPCOUNT=2000	!Plagerized from DUNE...
MIN_IRPCOUNT=1000	!Plagerized from DUNE...
MIN_LRPCOUNT=90		!Plagerized from DUNE...
!
! Global memory resources fairly high to accomodate installs, etc.
!
MIN_GBLPAGFIL=12200	!Minimum for CDD-Plus, (I forget which version...)
MIN_GBLPAGES=54000	!Plagerized from DUNE...
MIN_GBLSECTIONS=512	!Increased after V5.4
!
! Lock Manager Stuff...
!
MIN_LOCKIDTBL=4096	!Increase from DUNE, this is just a guess...
MIN_RESHASHTBL=2048	!Increase from DUNE, this is just a guess...
!
! Miscellaneous stuff...
!
MIN_LNMSHASHTBL=1100	!Plagerized from DUNE...
MIN_MAXPROCESSCNT=40	!So staff don't get carried away with pull-downs
ACP_REBLDSYSD=0		!No point, since boot server "rebuilds" anyway first
VIRTUALPAGECNT=75000	!So I can shoot big dumpfiles from any machine...
WINDOW_SYSTEM=1		!Satellites are wired for DECwindows, (vs VWS or NONE)

  I use the common Modparams stuff as well.  Mine is a little smaller than
  Susan's, but it covers some of the same items, the "mins" of the various
  items that all my machines need...
  
!!!   This is sys$common:[sysexe]Cluster_Modparams.dat via agen$include_params 
    DUMPFILE=0
    DUMPSTYLE=1
MIN_GBLPAGES=10000
MIN_GBLPAGFIL=10000
MIN_GBLSECTIONS=300
MIN_IRPCOUNT=300
MIN_LOCKIDTBL=256
MIN_NPAGEDYN=750000 
MIN_PAGEDYN=400000 
    PAGEFILE=0
MIN_RESHASHTBL=256
MIN_SRPCOUNT=500
MIN_VIRTUALPAGECNT=40000 
LGI_HID_TIM=60*60*24 
LGI_BRK_TMO=720 
if f$trnlnm("AGEN$P2") .eqs. "TESTFILES" then dele/symb/loc pagefile
if f$edit(f$getsyi("version"),"collapse") .eqs. "V5.4-2" then min_lrpsize==1568
  
  Sorry, no comments, but you should get the idea!
  
  $

Thanks for the files. I'll work them into the examples, probably keeping it
relatively short. Commented indeed!

We have a small NI VAXcluster here: 1 uVAX Boot/Disk Server and approx. 10
satellites (VAXstations) using a common/specific combination. I was thinking
more along the lines of a MIVC, or CI VAXcluster. How you would set that up, 
being that each CI system is probably unique. There would be some similarities, 
but the NI is probably the best example.

Have you worked on or have access to a MIVC using a FDDI ring(s) (or lobes is 
it)? Just curious. A VAX 6000 or VAX9000 would sure be nice. I'm seeking 
variation, tricks, or other techniques that might exsist.


						Thanks again,

						Paul M.

>We have a small NI VAXcluster here: 1 uVAX Boot/Disk Server and approx. 10
>satellites (VAXstations) using a common/specific combination. I was thinking
>more along the lines of a MIVC, or CI VAXcluster. How you would set that up, 
>being that each CI system is probably unique. There would be some similarities, 
>but the NI is probably the best example.

I don't have anything yet on a CI or MI, but with luck we could have a small
CI VAXcluster with 6000's in the near future (of course, probably not in time 
for you).  Our instructor for 6000 hardware maintenance wants me to build him
a VAXcluster, but he hasn't been able to score the CI hardware yet.  I would 
probably set up something similar to the NI common files since the 6000's 
will basically be the same (memory, votes, etc.); however, if I were building
a cluster with varied hardware/software, my options would be more limited. 
Perhaps I would need to create several different common files (ie 8xxx_common
_modparams.dat or 6xxx_common_modparams.dat).  My typing skills are so bad I'll
take any reduction in the number of files I have to update during an install/
upgrade.

>Have you worked on or have access to a MIVC using a FDDI ring(s) (or lobes is 
>it)? Just curious. A VAX 6000 or VAX9000 would sure be nice. I'm seeking 
>variation, tricks, or other techniques that might exsist.

Not yet, but I don't put anything past my hardware geniuses out here.  Stay
tuned.

				Susan

  I have a small MI cluster and the common info I gave earlier works fine. 
  I actually have a few items in the large machine that override the
  common file, but that is what the common file is best suited for, a 
  bunch of MINs that get us a nice BASE that the specific MODPARAMS
  override if necessary.
  
  $