| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 90.1 | Looking good... | UKEDU::HARMER | Geoff Harmer U.K. Edu (830) 6229 | Wed Sep 18 1991 10:52 | 34 |
| This chapter seems to adequately introduce NCP concepts for someone who
is System managing an existing DECnet node. That was the objective I
believe ?
My only concern is that it overlaps with Network management I ...which
you want to blow away... I'll give my views on that idea when i see
SYSnet IV. (Luddite Network manager talking ;-) who believes that
a course on network management is still needed despite all the good
work in the SYSNET curriculum )
Some small points:
p 1-11 copy known nodes from cookie USING PERMANENT
copy known nodes from cookie USING PERMANENT TO BOTH
Neither of these will work normally. You need to put
cookie"SYSTEM SECRET" so that you have SYSPRV and can access
the permanent database on COOKIE. Alternatively you might have a
proxy on COOKIE to an account with SYSPRV...but this is a security
risk.
Better to just suggest using
NCP> copy known nodes from cookie USING VOLATILE TO BOTH
which has most practical use and will work for the person logged in
as SYSTEM on his local node.
Labs:
Students need to be doing these as group exercises unless
they have a node each; else they will be interfering with each other.
Geoff
|
| 90.2 | I don't think this is what we need... | NWGEDU::RODENBURG | Ed. Services, The Netherlands | Wed Sep 18 1991 12:20 | 101 |
|
When I review this module, my first question is: what are the
objectives of this module?
When we discuss a task-oriented curriculum, than we must NOT speak
in terms of:
"At the end of this module the student will be able to create, modify
and monitor network entries using NCP"
Than you still talk in terms of commands and utilities, and NOT in terms
of tasks or jobs.
Maybe it seems a bit nit-picking, but it is very important how we
approach the contents of the modules.
In my opinion our objectives must be:
At the end of this module the student will be able to:
- monitor whether a networknode is reachable or not
- monitor and control the connection of this system to the DECnet
network
- keep the local network database up-to-date
Second item I want to point to:
The different parts of this module are almost completely taken from the
DECnet management course. That will not necessarily be a problem, but
to address the problems, occuring when you try to replay the examples,
you are going down several ratholes. In my opinion several subjects must
be excluded, and are not important for the student IN THIS STAGE (later
they are...).
Two difficult points as examples:
When you do a NCP COPY KNOWN NODES FROM ... USING PERMANENT, how are
you explaning what is going wrong (it IS going wrong on a default
system), without having discussed in SYSNET I and SYSNET II what is a
NETWORK process, and how/when it is created?
When you change the address of the local node, how do you explain the
error messages occurring when you do @STARTNET? (again it IS going
wrong when you demonstrate it on your terminal...)
Will the instructor be able to explain what the error message Illegal
Physical Address Value, or what kind of other value means and will the
student be able to understand and use this info?
What must be in the module:
* Identifying a Node
* How to display the network status using SHOW NETWORK
- on an endnode
- on a full function node
* Databases
- permanent database
- volatile database
* Maintaining the Network Configuration Database
* Using NCP commands
* Monitoring the executor status
Example: NCP> SHOW EXECUTOR (STATUS)
(discuss the ON-status!!, don't discuss the Ethernet address)
* Monitoring the network connection
Example: NCP> SHOW KNOWN LINE
NCP> SHOW KNOWN CIRCUITS
* Keeping the node database up-to-date
- Manually: Adding a node to the local database
Example: NCP> SET/DEFINE NODE 4.23 NAME JRNET
- Copying the complete database from a remote node
Example: NCP> COPY KNOWN NODES FROM 4.25 TO VOLATILE
NCP> COPY KNOWN NODES FROM 4.25 TO PERMANENT
NCP> COPY KNOWN NODES FROM 4.25 TO BOTH
- Removing a node from the local database:
Example: NCP> PURGE NODE ZODIAC ALL
NCP> CLEAR NODE ZODIAC ALL
NOTE: Do NOT (!!!) discuss changing local nodename or address. That has
consequences in a cluster environment (we were discussing the
SYSTEM/NETWORK/CLUSTER management, huh?) and has consequences when
other Ethernet networkproducts are running, for instance LAT.
* displaying info from remote databases
Question: why talking about the TELL-command? Is it a task the
student will get? Maybe it can be important for him, but at
this stage only page 1-15 is important, because it can be
important for him to read some entries in a remote node. But
definitely NOT how to change a network entry in a remote node.
I never heard a customer did it in this way...
So, what will be in this module about this item:
- Tell command ( page 1-15)
- Example (page 1-16)
* Stopping the network
- NCP> SET EXECUTOR STATE OFF
* Starting the network
- Using STARTNET to start the network
explain that 3 processes will be created, and don't
go into details
- Example1: @SYS$MANAGER:STARTNET
Example2: SHOW SYSTEM
Sofar my concerns and remarks. I hope to see replies.
Joop
|
| 90.3 | Agree with .2 | UKEDU::HARMER | Geoff Harmer U.K. Edu (830) 6229 | Fri Oct 04 1991 13:18 | 2 |
| yes
Joop, you've hit the nail on the head with the Objectives.
|
| 90.4 | Review of Networking chapter in SYSNET II | NWGEDU::RODENBURG | Ed. Services, The Netherlands | Thu Nov 07 1991 05:05 | 42 |
| Well, I copied the new modules of SYSNET II, and looked at the
networking modules.
Looking at the global setup of the chapter, and looking at the
objectives of the chapter I can see the changes, in relation to the
previous proposal.
Main positive changes:
- objectives formulated in terms of tasks:
" To monitor and control the network, a system and network
manager should be able to:
- maintain the local node database
- obtain node information from other nodes "
- the examples with unplanned errormessages are disappeared
- contents of the chapter is adopted to the 'new' objectives
Great!
Some minor details, that need to be changed:
page 10-5:
this page is rather full of information, better to split it into
two pages : Starting/Stopping the network
The SHOW NETWORK command
page 10-5:
NCP> SET EXECUTOR STATE SHUT
Better to change into SET EXECUTOR STATE OFF
There are a lot of networking products, available at this moment,
that keep a logical link up and running for a very looooong time.
In this situation the SYSNET II-student will wait forever to
have the DECnet software stopped.
In a later state you can discuss, that it is more friendly, and in
some cases better, to use STATE SHUT, but don't give this example
in this stage.
I am really glad to see this material. Thanks to the developers, to use
the feed-back to re-arrange this chapter.
Now up to the networking parts in SYSNET III!
Joop
|
| 90.5 | Include previous NCP-items ito this chapter | NWGEDU::RODENBURG | Ed. Services, The Netherlands | Fri Nov 08 1991 05:08 | 74 |
|
Oops, I looked at the chapter again, and saw one minor detail on page
10-7:
nnnn is the node number within the area (from 1 to 1023)
=======
Futhermore, in the previous chapter some networking items have been
included.
Here I enter my comments about these items (see also the notesentry
87.*):
9-22/27:
It is correct to include some NCP information into this course, but
be carefull to include not too much, because all the network items,
known at this moment are from SYSNET I:
- how to use SET HOST
- how to use a terminal server
- how to startup DECnet and LAT
What is the objective of this paragraphs:
(my idea) to give the student the tools to monitor the connection
with the network, to see whether all is up and running.
Second remark:
In the next chapter the item to be discussed is Managing a Network
Node. There is completely discussed what is the use of the
permanent and volatile database. there is discussed what is NCP,
and how it must be used.
Third remark:
Talk only about lines and circuits, not about links.
Leave the table with all the NCP commands away.
My proposal about what is left about NCP:
Leave these items in chapter 10, and move this MOnitoring
part to chapter 10 in a slightly different form. I will enter
that remarks to the notesentry about chapter 10.
Chapter 10: Managing a Network Node:
Include the monitoring items into this chapter.
An additional objective will be:
- Control the connection of the node to the network
The sequence of items in this chapter will be:
* pages 10-1/9 as they are in the presented material
* here after include the items:
(quote)
VERIFYING THE CONNECTION TO THE DECNET NETWORK
There are two DECnet components that will be used to connect
your node to the network:
- line
- circuit
Lines are the physical data communication paths between nodes.
......
(etc, see page 9-24)
Circuits are virtual connections between nodes.....
(etc., see page 9-25)
(unquote)
Do not talk about links. That is too much at this moment, and not
useful.
Skip the table on page 9-31, not relevant for the tasks mentioned.
* include the pages 10-10/19.
|
| 90.6 | First teach post mortem | MELKOR::SWIERKOWSKIS | | Mon Jan 20 1992 11:38 | 20 |
| This reply is limited to technical errors only. I'll refrain from making
comments one way or the other about content, style, etc....
Module 9 (Managing a Network Node) in SYSNET II
p. 9-6 Under Identifying a node, the maximum address (nnnn) in
area is 1023 not 1024 !!!
p. 9-15 This is not an error, but for those of you who are teaching
this type of network material for the first time watch out
for the NCP> CLEAR EXECUTOR NODE command. Make sure your
students understand the importance of typing this command as
is. If they simply type CLEAR EXEC, the system will prompt
them for all parameters. If they say YES to that prompt, they
will DELETE all the local node information in the volatile
DECnet database.
Susan
|