[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference koolit::vms_curriculum

Title:VMS Curriculum
Moderator:SUPER::MARSH
Created:Thu Nov 01 1990
Last Modified:Sun Aug 25 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:185
Total number of notes:2026

169.0. "Cluster Course Chapter Review" by SUPER::SUPER::TARRY () Wed Aug 25 1993 16:59

    This note is for formal review comments relating to chapters that have
    been posted.
T.RTitleUserPersonal
Name
DateLines
169.1Reviewer InstructionsSUPER::SUPER::TARRYWed Dec 08 1993 10:5686
    I am now starting to post files for review for the Complex Cluster
    Course. (CCC)   Subsequent notes will announce file postings.
    
    There are some new rules.  Please read the following description before
    you plunge in and get upset by the format.  This course will look very
    much like the new sysnet.  Please give me a call at DTN 381-1162 if you
    would like to discuss the materials.
    
    Any of this may change.
    
    Each file posted  represents a part of a chapter called a section
    (collection).  The instructor version is posted. The sections will be 
    assembled into chapters.


	There is some lead information at the start and end of each section.
	This material will migrate as follows:

		Terms will to a glossary at the end of the book
		Resources, objectives to  the chapter introduction
		Test questions to a separate chapter called test
		Written exercises to the end of each chapter
    		Laboratory exercises to a separate book


	There will be an OVERHEAD for almost every block.  In some cases I am
	consolidating overheads for several blocks into one overhead to
	eliminate instructor having to change the overheads. Overheads are
        in outline form much like our old ll materials.

	Instructor notes will give:

		Version information
		Further references
		Teaching hints
		More detailed information
		Cautions

	The file name tells you which chapter the material will be in.
	It does not indicate the order within the chapter.


The naming standards for section files:

	vms_cc_#_short-name_instructor.ps


		where:  #=chapter number
                        short-name describes the content
		      
	VMS_cc_4_quorum.sdml      
        
The sections are posted in the review directory:

	SUPER::$1$DUA6:[IDC$REVIEW.VMS_CLUSTER_V6]


The chapters planned are as follows

1. Introduction - Background chapter What is a cluster, advantages   

2. VMScluster System Communications-  SCA communications, interconnects

3. VMScluster System Hardware - Satellite nodes, non sat nodes, boot
                nodes, storage options, system disk options	

4. VMScluster System Software- conenction manager, distributed lock
                manager, quorum, state transition

5. Configuring VMScluster Systems- given the business requirements
           complete a configuration table for various cluster systems.

6. Building a VMScluster System - given a configuration table, build the
                                 cluster

7. Managing a VMScluster System - Use OpenVMS and layered products to
	manage the cluster focusing on special problems of cluster
	management,

8. Test


9. Laboratory Exercises (separate book)

    
169.2Two sections postedSUPER::SUPER::TARRYWed Dec 08 1993 11:0219
    Two sections are now ready for review.  Please review the section on 
    quorum first as I have included some comments about material migration
    in the text.  These comments will of course not appear in the final
    version.
    

	SUPER::$1$DUA6:[IDC$REVIEW.VMS_CLUSTER_V6]

    			VMS_CC_4_QUORUM_INSTRUCTOR.PS
    
    			VMS_CC_4_DLOCK_MAN_INSTRUCTOR.PS
    

Please post comments in Note # 169

    All comments posted by 15-Jan will receive full consideration. 
    Comments posted after 15-Jan-1994 will receive consideration if time allows.
    All comments will be saved for the next revision of the course.
    
169.3Dlock : dynamic exampleKETJE::KLEINChris Klein DTN 856-7813 - It is I, Le-kleinThu Dec 09 1993 05:2119
    Re. dist lock chapter
    
    In the old (V4) VMS internals course there was a supplement about the
    dist lock mgr. It contained an example of a cluster were you actually 
    requested locks and had to fill in all the relevant data structures.
    There was an overhead with the empty tables, so the instructor could
    fill this in during the class. Even though you don't speak at the data
    structures level in this type of course, in my opinion it doesn't hurt
    when explaining the distr.lock mgr. (no student has ever complained).
    
    I always liked this "dynamic" example, and I think it helped students
    understand what goes on.
    
    Therefore I propose to add something along this line to the current
    chapter. I still have the example in my archives somewhere, should you 
    want a copy of it. (Besides this, NODE_A, NODE_B etc are ok, but I had
    a slight preference for LAND, SEA and AIR ;) ).
    
    Chris.
169.4RE:.-1TANG::RHINEJack, OpenVMS Training Product ManagerThu Dec 09 1993 18:4115
    RE: .-1
    
    Hi Chris,
    
    Thanks for the comments.
    
    I know you aren't too concerned about the node names, but we have
    decided to use neutral node names so that if lessons or collections
    are used with other materials to build a custom course, things will fit
    together better and the custom course will seem more coherent.  We will
    also be avoiding the use of processor models to keep things from
    getting dated because of figures and examples.
    
    Jack
    
169.5Developer RepliesSUPER::SUPER::TARRYMon Dec 13 1993 11:3133
>    I always liked this "dynamic" example, and I think it helped students
>    understand what goes on.

Please do send the example.  I think that this "collection" on the
distributed lock manager is pretty detailed for the target audience
as is, but I can always put the example in the instructor notes or
just make an overhead.

(Besides this, NODE_A, NODE_B etc are ok, but I had a slight
preference for LAND, SEA and AIR ;) ).

I know everybody has their favorite names, BUT  I think the student
has enough to learn as is and that giving equipment standard names
will make it easier to read the diagrams and code examples.  My plans
are to use  NODE_1, NODE_2, NODE_3 in diagrams and tables and switCh
to NODE01,NOD02, NODE03 in the code examples. This is because the "_"
is not a legal character.  When I want to talk about specific types of
nodes this can switch to VAX_01, AXP_01.   We can also use  HSC01,
DISK_1,  FILE_1, HSC_1.

I guess you are now wondering why I used NODE_A.  Well I just screwed
up. I am rather indifferent  between the two choices:   NODE_1  or
NODE_A.  Except that NODEA or NODE0A  looks a little peculiar.


Thanks for reading the posted collections.  I hope you will have time
to post more comments.  Did you read the quorum collection first?  I
wrote in some specific directions to reviewers in that collection to
help people  adjust to the new format.



    
169.6Sent by pigeon.KETJE::KLEINChris Klein DTN 856-7813 - It is I, Le-kleinTue Dec 14 1993 06:149
    > Please do send the example.  I think that this "collection" on the
    
    The example dates from pre-Postscript (subtle pun ;) ) days, so I sent
    a paper copy, which may take a few days.
    
    > I know everybody has their favorite names, BUT  I think the student
    
    Sorry about starting on node names; I usually use VAXA, VAXB, SAT1,
    SAT2 for clusters, and perhaps was hoping for more inspired names...
169.7V5.5 exampleWAGGIS::FREPPELghost clustersTue Dec 21 1993 05:186
    An updated (discusses dynamic remastering � la V5.5) version of the example
    is being mailed to Emmalee right now (three postscript files).
    
    I'll send the .DOC files :-( upon request.
    
    Raymond. 
169.8Selecting the Information SetSUPER::SUPER::TARRYWed Dec 22 1993 11:2186
    
    
    
    
    I very much appreciate Raymond sending me his files.  They are very
    good and I am glad he is willing to make them available to others. I
    have read the documents and decided not to include them in the cluster
    course.  I would like to use this note as a way of introducing the
    procedure for selecting the proper information sets for our courses.
    I feel that the material as it now stands has an appropriate amount of
    detail to cover this topic.
    
We are trying the OpenVMS curriculum more task oriented.  The question
we need to ask for every set of information is what does a member of
the target audience  need to know about the subject in order to perform their
job. Selecting the appropriate information set is just as important as
the presentation of the information.

The task in this collection is to select a value for LOCKDIRWT for all
cluster members.  To perform that task, the system manager needs to
understand the following:

	What is the problem or why does OpenVMS have a dlm?
	
	How is the problem solved by the DLM?
	
	How does dlm work in general terms?
	
	What is the effect of the value in LOCKDIRWT and how should it
	be set on different nodes?


It is certainly true that anyone who wades through the internals of
the dlm has reason to be proud of themselves.  But does it enhance
their ability to do their job?

System management is a tough job and the candidate has much to learn.
Our job as instructors and course developers is to sort through all
the material and select the optimal information sets to present in the
limited time allowed for training.

Now let's look at this from the other side.
    
Does this collection as it is written have too much material?
All a system manager really needs to know is contained in the last
block of the collection that discusses the general rules for selecting
values for LOCKDIRWT.  One could read this in the documentation and not 
    have to take a training course at all.

I believe the system manager who completes this collection and
understands the materials related to the four points knows why they
select a certain value for LOCKDIRWT, when to consider making changes,
is better prepared for troubleshooting, and has a background for
adapting to future enhancements.  

In selecting materials to include in this course, I ask the following
questions?

	Why does VMS have this function?  Remember it is never just to
	make the engineers, course developers and/or instructors look
	smart.

	What is the task(s) the 'target audience' needs to perform in
	regard to this function?

	What background information do they need to understand in
	order to know: what, when, how, and why to perform the task?

	What will they see displayed by various software tools? For
	example, should I explain "send credits" because they are
	displayed by the SHOW CLUSTER utility?  I think that I should
	if I can figure out the value of the display.


I hope that you will continue to review the materials and to help me apply
these criteria to the other collections.  There are many questions
here to be answered for every collection in the course and I can use
all the help I can get.

    Also, please keep in mind that instructors are encouraged and expected
    to add value to the course materials at delivery.  Instructors are not 
    robots with good reading skills.
    
    
    
169.9announcing commentsWAGGIS::FREPPELghost clustersTue Jun 21 1994 05:5512
    In the following replies, I'll comment on the cluster course.
    My overall impression is that this is really a great course.
    
    The following comments may sometimes be considered as "picky", but I
    included some nits as well as some (rare) mistakes.
    
    Although the handout is 'cooking' (Mel, do you hear me?) and my
    comments therefore won't make their way into it, i'll post them here
    for reference and discussion (I always found such inputs useful).
    
    have fun
    Raymond.
169.10chapter 1WAGGIS::FREPPELghost clustersTue Jun 21 1994 06:0029
	The pages are based on the prototype (aka pilot) instructor guide.
    	I included the nearest headline.
    
    	Sorry for including the nits.
    
	Comments on Chapter 1
    	---------------------
      
p 1-6	History
	last sentence: combined --> combine

p 1-9	Configuration Rules
	3rd bullet: Is this really a configuration rule? 

p 1-17	Default Report Fields 
	Table: Item NODE - mention that some controllers ("standalone
	controllers", as they are called in chapter 3) such as the HSC, HSJ, 
	HSD, HSZ and RF controllers are also considered as nodes.
	Maybe worth a footnode containing the pointer to chapter 3.

p 1-37	CONNECTIONS Class Fields
	Point out that REM_PROC_NAME and LOC_PROC_NAME are actually not names
	of VMS processes but SYSAP names.

p 1-39	Example: CIRCUITS and CONNECTIONS  
	What is the VMS$Cluster_Drvr SYSAP? 
	According to Note 4126.1 in the (VAXAXP::)CLUSTER conference, this is 
	not a standard SYSAP, it should therefore be removed (or explained).
    
169.11chapter 2WAGGIS::FREPPELghost clustersTue Jun 21 1994 06:0286
	The pages are based on the prototype (aka pilot) instructor guide.
    	I included the nearest headline.
    
    	Sorry for including the nits.
    
	Comments on Chapter 2
    	---------------------
p 2-3	Objectives
	2nd bullet: inconnect --> interconnect

p 2-8	Layered Protocol
	Last bullet: introduce the term "peer to peer".

p 2-16	System Applications
	1st bullet: Is the Distributed Lock Manager (DLM) really a SYSAP? 
	My understanding is, that the DLM uses the Connection Manager SYSAP to
	communicate, but is strictly not a SYSAP of its own (it does not 
	establish any connection).
	
p 2-19	System Information
	List: Use only one term to refer to a OpenVMS System, therefore
	3rd bullet: OpenVMS CPU node --> OpenVMS System
	4th bullet: CPU node --> OpenVMS System

p 2-24	Notes on Diagram
	#2: Mention that the port adapter and the port driver both are
	    specific to the interconnect.
	    Mention that port drivers reside in SYS$LOADABLE_IMAGES.
	#3: Mention that SYS$SCS is SYS$LOADABLE_IMAGES:SYS$SCS.EXE.
	#4: Mention that SYS$SCS is SYS$LOADABLE_IMAGES:SYS$CLUSTER.EXE.
	    Mention that class drivers reside in SYS$LOADABLE_IMAGES.

p 2-25	Overview
	4th paragraph: The term "direct circuit" is not and never will be 
	defined. Why not use the proper term "virtual circuit" and point to the 
	definition on p 2-18 ?

p 2-28	What is a Bus?
	To avoid confusion mention that a "station" in this context means any
	piece of hardware that is supposed to be connected to the bus. 
	Mention that "station" is a synonym for "node".

	Bus Arbitration
	The term "node" here refers to what was previously called a "station".
	
p 2-56	System Parameters
	Include the following note (from R.Davis, p 3-53): "SYSGEN parameters
	governing CI port polling and virtual circuit formation apply in the 
	same way to DSSI adapters."

p 2-57	Example: CI Port Polling
	PANMAXPORT --> PAMAXPORT

p 2-58	Path Failure
	Last sentence: discovered --> discover	

p 2-64	Supported Adapters and CPU Types
	Table: Include units of transfer rate (Megabytes per second)

p 2-65	Multiple DSSI Adapters
	Table, last row: DEC 1000 --> DEC 10000

p 2-66	Integrated Termination
	2nd bullet: 2600/2800/2900 --> 3600/3800/3900

p 2-78	Tree
	propates --> propagates

p 2-94	Ethernet Port Adapters
	Table: Include VAX 7000	

p 2-102	Instructor Note
	TTH --> TTP (Time Token Protocol, defined on p 2-30)

p 2-132	Exercise 2
	Avoid the term process. (See note for p 1-37)

p 2-133	Solution 2
	Why is the HSC not considered as disk server? If it is not, the
	question should be rephrased to "What OpenVMS System nodes ...".

p 2-137	Exercise 3/ Solution 3

p 2-138	PANMAXPORT --> PAMAXPORT
	Very interesting exercise, thank you.
    
169.12chapter 3WAGGIS::FREPPELghost clustersTue Jun 21 1994 06:03105
	The pages are based on the prototype (aka pilot) instructor guide.
    	I included the nearest headline.
    
    	Sorry for including the nits.
    
	Comments on Chapter 2
    	---------------------
    
p 3-9	Examples (of Standalone Storage Controllers)
	Pointer to Notesfiles as an instructor note:
	HSD --> SSDEVO::HSD05_product, SSDEVO::HSD30_product
	HSJ --> SSDEVO::HSJ40_product
	HSZ --> SSDEVO::HSZ40_product

p 3-17	Managing an ISE
	"privileged terminal" --> "privileged account on a terminal"

p 3-19	Overview
	4th bullet: "TSCP disk server" --> "TMSCP tape server"

p 3-21	Determining Allocation Class
	Last sentence: "same allocation class" --> "same nonzero allocation 
						    class"

p  3-24	Dual-Ported Devices
	Last sentence (bold): This is actually a configuration rule, mark it as
	such.

p 3-29	Server States / Device States
	Very good explanations, thanks.

p 3-33	Serving Devices to Satellites
	2nd bullet: "same allocation class" --> "same nonzero allocation class"

p 3-34	Diagram
	- "NODE6$DUA0" --> "NODE_6$DUA0"
	- Include disk- and tape allocation class in each rectangle.
	- Is there a particular reason to set tape allocation class to 5 on
	  NODE_4 and NODE_5 ?

p 3-35	Enabling MSCP Disk Service
	- 2nd bullet: "the disk will serve" --> "the node will serve"
        - MSCP_SERVE_ALL controls which disks are going to be served
	automatically on the next bootstrap. Mention that there is a way to 
	manually enable disk serving (SET DEVICE/SERVED <device_name>).

pp 3-58	Good presentation!

p 3-61	Controller Cache
	- 2nd paragraph, last sentence: "data is in HSC memory" --> "data is in
	  controller memory"
        3rd paragraph: "The system manager" --> "On a HSC, the system manager"

p 3-69	Using Two DSSI Buses
	2nd line: "improved by located" --> "improved by locating" 

p 3-83	Files That Are Not Shared
	Include Page- Swap- and (with some restrictions) Dumpfiles.

p 3-88	Logical Name Search Lists
	Use [SMITH.A] and [SMITH.B] in order to stay aligned with the previous
	example.

p 3-97	Boot Process
	Step #2 is incomplete and in step #3 it is not clear how the satellite
	gets its way to the system disk. 
	Using th information in VAXcluster Principles (p 8-17 - 8-20), I
	suggest the following rewrite (changes marked with *):
	
	Step #2: A *MOP* server node recognizes as one for which it is a *MOP*
		 server and downline loads to the satellite a more complex
		 program or *secondary bootstrap* image.
		 - For Alpha AXP *satellites*, the image is
		   SYS$SYSTEM:APB.EXE *(Alpha Primary Boot)*
		 - For VAX *satellites*, the image is
		   SYS$SHARE:NISCS_LOAD.EXE

		 *Along with this image*, the *MOP* server provides to the
		 satellite *the following parameters (in the load assist
		 parameter block):

                 - The satellite's root directory name
		 - The values of SCSNODE and SCSSYSTEMID parameters of the MOP
		   server (used for later communication)
		 - The satellite's system disk name
		 - The values of the satellite's SCSNODE, SCSSYSTEMID, and
		   NISCS_CONV_BOOT parameters.
		 - The cluster group number and the encrypted cluster password
		   (from the MOP server's file 
		    SYS$COMMON:[SYSEXE]CLUSTER_AUTHORIZE.DAT)*

	Step #3:  *When the last segment of the secondary bootstrap image has
		  been downline loaded to the satellite, the load assist
		  parameter block is transferred as well. This triggers the
		  satelite to transfer control to the secondary bootstrap
		  program.*

p 3-104	TURBOchannel LAN Adapters
	2nd sentence: "must using" --> "must use"

p 3-111	Making Storage Devices Shareable
	6th bullet: "balances mount requests" --> "dynamically balances the 
						   MSCP server load (including
						   mount requests)"
    
169.13chapter 4WAGGIS::FREPPELghost clustersTue Jun 21 1994 06:0424
	The pages are based on the prototype (aka pilot) instructor guide.
    	I included the nearest headline.
    
    	Sorry for including the nits.
    
	Comments on Chapter 4
    	---------------------
    
p 4-10	Quorum Calculation
	Map the terms used to values displayed in SHOW CLUSTER/CONTINUOUS:
		AVAILABLE_VOTES		-->	CL_VOTES
		EXPECTED_VOTES		-->	CL_EXPECTED_VOTES
		QUORUM			-->	CL_VOTES

p 4-35	Dynamic Remastery
	2nd bullet, first dash:
	replace 
		"A system with greater LOCKDIRWT is likely to become the
		 resource master"
	by
		"Among the systems, the one (if any) with the highest value of
		LOCKDIRWT will be the resource master"	

    
169.14chapter 5WAGGIS::FREPPELghost clustersTue Jun 21 1994 06:0532
	The pages are based on the prototype (aka pilot) instructor guide.
    	I included the nearest headline.
    
    	Sorry for including the nits.
    
	Comments on Chapter 5
    	---------------------
    
p 5-11	Multiple System Disks
	Include the mixed architecture case as a special example of having two
	versions of OpenVMS ([maybe] same version numbers, but completely 
	different executables).

p 5-18	System Disk
	Instructor Note: POLYCENTER HSM is an LP for OSF/1 (which currently
	cannot be clustered with OpenVMS). 
	A pointer to information on The New File System (TNFS or "Dollar") 
	could be included here (Notes Conference MOVIES::DOLLAR_INFO)
p 5-24	Large CI-VMScluster System
	To eliminate the Star Coupler as a single point of (rare) failure for 
	the system disks, shadowing could be done across the SCs.

p 5-45	Limits (of Business Recovery Server)
	The current version of BRS (BRS V1.1, SPD 35.05.02) only suppoerts
	OpenVMS VAX operating system on both sites. This should be pointed out 
	unless a new version (supporting OpenVMS AXP as well) is available.

p 5-49	Planning a VMScluster System Configuration (Summary)
	2nd bullet: A single system disk --> a single system disk per
					     architecture
    
    
169.15chapter 6WAGGIS::FREPPELghost clustersTue Jun 21 1994 06:0673
	The pages are based on the prototype (aka pilot) instructor guide.
    	I included the nearest headline.
    
    	Sorry for including the nits.
    
	Comments on Chapter 6
    	--------------------- 
    
    p 6-13	Example: NETCONFIG.COM
	Label (1) appears twice. Either remove the first or add an appropriate
	note on p 6-16. 

p 6-16	Instructor Note:
	- The example set up a ROUTING node (see p 6-13).
	- 1st bullet: If ONLY the end node key is installed...

p 6-17	Starting the Local DECnet Software
	Mention SYSMANs Startup Database.

p 6-21	Cluster Related Parameters
	Table:  Entry for VAXCLUSTER:

		WHEN you   AND    	  THEN the VAXCLUSTER 
		respond                   parameter is set  to...
            
		N 	   CI *or* DSSI   1 - Node will automatically
			       ^          participate in the VMScluster
                               |          in the presence of DSSI or CI
	 	+--------------+       	  hardware.
                |          hardware is 
                |          present     
                |                      
                replaces "and"

p 6-25	Configuring Satellites
	"boot node server node" --> "boot server node"

p 6-27	Example: Adding a CI Node
	- Mention that for this purpose CLUSTER_CONFIG can be run either on
	  BARNUM or on RNGLNG.
	- System Root Default (SYS1): This assumes, that one of the other nodes
	  (BARNUM or RNGLNG) boots from SYS0, the other from a root different 
	  from SYS0 and SYS1. This may be confusing. 

p 6-30	Example: Adding a Satellite
	- DECnet address: Do not use 1.99. It was used in the previous example
	  for node BAILEY.
	- System Root Default (SYS1F): explain! The following is from 
	  CLUSTER_CONFIG.COM from a resd:

	$ !
	$ ! Get the default system root name.
	$ ! If the root is for a satellite, start the roots at hex 10. Save the
	$ ! first sixteen roots for the CI nodes. Because of the hardware 
	$ ! limitations of only allowing 4 bits to be set in R5 for CI root 
	$ ! numbers, we should save roots 1-16.
	$ !
	
p 6-32	Enabling a Quorum Disk
	- Include a pointer to the definition of "quorum disk watcher" (p 4-17)
	  and the quorum scheme (p 4-6).

p 6-42	Functions of Startup Procedures
	2nd bullet: - remove the colon at the end.
		    - and move the last four entries out of the dashed sublist
		      into the bulleted list.

p 6-46	Cluster Alias
	Last sentence: RINGLING --> RNGLNG

p 6-49 	Adding and Modifying Nodes
	5th bullet: REMOVE option is not restricted to satellite nodes.
    
169.16chapter 7WAGGIS::FREPPELghost clustersTue Jun 21 1994 06:1477
	The pages are based on the prototype (aka pilot) instructor guide.
    	I included the nearest headline.
    
    	Sorry for including the nits.
                                                                   
	Comments on Chapter 7
    	--------------------- 
    
p 7-3	Introduction
	represent --> represents

p 7-13	Initialization File
	Logical name SYSMANIN --> SYSMANINI

p 7-15	Remote Environments
	Name mismatch: Text uses username SMITH, example shows username TARRY.

p 7-24	DECamds Corrective Action
	Instructor Note: OpenVMS service call --> OpenVMS system service call

p 7-32	Queue System Components                 
	Instructor Note: Paragraph starting with:"Prior to version 5.5..."
	- startup.com files --> startup command procedures
    	- queue manaster file --> master file
    
p 7-33	Interprocess Communication Services
	The process IPCACP is not a SYSAP in itself, its a "regular" ACP.
	The SYSAP involved is SCA$TRANSPORT (if my brain serves me right).
    
p 7-35	Multiple Queue Managers
	2nd paragraph: Inconsistent use of the term "queue database":
	"Multiple queue managers share a single queue database."
	Queue Managers only share the file QMAN$MASTER.DAT.
	The term "queue database" is defined on p 7-37 "Files", where it says: 
	"The queue database is made up of the following files:", and then lists
	the master file, queue file and the journal file. 

p 3-37	Queue Master File
	- "QMAN$MASTER.DAT is shared by the job controller and the queue
	   manager." --> "QMAN$MASTER.DAT is shared by all job controllers and 
	   queue manager processes."
	- "The single master file is shared by all processes in the cluster"
	   That's not true. Change this to:  
	  "The single master file is shared by all job controllers and queue 
	   manager processes in the cluster."

p 7-39	Multiple Queue Managers
	- Is the creation of the two extra files really confined to VAX systems?
	  (Haven't heard of such a restriction)

p 7-43	Starting and Creating a New Database
	Replace the location in the example, the disk specification does not
	imply that the disk is shared. I.e. use $1$dua4 instead of just dua4.


p 7-44	Creating an Additional Queue Manager
	Paragraph before the example: "Multiple queue managers use the same
	queue database." This is inconsistent with the definition of the term
	"queue database" on p 7-37. (cf. comment on p 7-35 above)

p 7-45	Stopping the Queue Manager
	Include the /name_of_manager=<queue manager's name> qualifier.


p 7-62	Setting Up the Terminal Server
	After the line
		Local> set priv
	the line
		Password:
        should be included. Add a note about the password not being echoed on
	the terminal and how to set a new one. 

7-65	Create the Application Port                   
	Item #4, 2nd bullet: SYSTARTUP_V5.COM --> SYSTARTUP_VMS.COM
    
7-74	The Queue Manager and Queue Database (Summary)
	2nd bullet: QUEUE_MANAGE --> QUEUE_MANAGER                 
169.17chapter 8 (Lab Exercises)WAGGIS::FREPPELghost clustersTue Jun 21 1994 06:1730
	The pages are based on the prototype (aka pilot) instructor guide.
    	I included the nearest headline.
    
    	Sorry for including the nit.
                                                                   
	Comments on Chapter 8 (Lab Exercises)
    	-------------------------------------
    
p 8-12	Lab Exercise for Configuring System Disks
	Exercise 4:
	Strictly speaking, the analogy with the system disk structure is not
	met in the example:
	- The directory COMMON.DIR should be on the same level as A.DIR and
	  B.DIR, just as VMS$COMMON.DIR is onthe same level as SYSxxx.DIR.
	- The directories A.DIR and B.DIR then should both have an entry
	  COMMON.DIR pointing to the "real" COMMON.DIR.

p 8-19	Lab Exercise for Quorum Scheme
	Solution 6:
	The value of CL_EXPECTED_VOTES *only* drops when the REMOVE_NODE option
	in SHUTDOWN.COM is selected. 
	(In fact, when the REMOVE_NODE option is selected, SHUTDOWN assigns the
	logical name OPC$CLUSTER_REMOVE a value of 1 and invokes OPCCRASH.EXE,
	which, based on OPC$CLUSTER_REMOVE, requests the connection manager to
	adjust quorum)

p 8-24	Lab Exercise for Building and Modifying a VMScluster System
	Exercise 9: Item #3: 
	"startup command procedure SYSTARTUP_V5.COM" --> "startup command 
	 procedure SYSTARTUP_VMS.COM"