| Hello!
Here is the document for all to know...
========================================================================
From: KEIKI::WHITE 11-MAR-1997 14:26:15.59
To: MANM01::NOELGESMUNDO
CC:
Subj: I'd rather fight than switch (old cigarette commercial in U.S.A.)
The various things that might need to be done in order to get things
switched over to using FDDI. The only thing not mentioned is the PATHWORKS
for MAC, aka Appletalk, software. This was not added due to Guy having the
needed information and skills to switch it over. The only thing that I did
not get a chance to check into was the SNA gateway software. Since it has
no direct linkages to the actual network controllers, it should not be an
issue. The only thing that might need to be checked into is any
information that might pertain to the MOP downline loading of the gateway
box itself. I will send another mail message off to Bill to let him know
what the current status of things is.
Steps For Switching Over To FDDI From CSMACD:
The DECnet Phase IV protocol:
The overall goal is to move the DECnet protocol from the CSMACD
controller to the FDDI controller. It DOES NOT mean to simply add in
the FDDI controller. This is especially true when both the CSMACD and
FDDI controllers are on the same logical/physical LAN.
The following steps can be done in order to get the DECnet database
configured:
o NCP> PURGE CIRCUIT MNA-0 ALL
o NCP> PURGE LINE MNA-0 ALL
- The reason for doing this is to remove all references
DECnet has to the old CSMACD controller.
- If this is not done and the CSMACD controller is still
connected to the same logical/physical LAN, the
physical address will appear to have more than one
source thus creating havoc for the bridges that build
their forwarding tables based upon which interface a
particular source address is seen.
- It is not enought to have the CSMACD DECnet line and
circuit in an off state because the protocol type and
physical address will still be initialized on the
controller.
- The equivilant NCP> SET CIRCUIT/LINE MNA-0 STATE OFF
and NCP> CLEAR CIRCUIT/LINE MNA-0 ALL commands can be
used if one is trying to change the configuration on
the fly, but a loopback connector will need to be
put into place so as to keep the still existant
AA-00-04-00-XX-XX physical address from showing up
from this source.
o NCP> DEFINE LINE MFA-0 STATE ON
o NCP> DEFINE CIRCUIT MFA-0 STATE ON
- The equivilant NCP> SET LINE/CIRCUIT commandscan be
used if one is trying to change the configuration on
the fly.
o Side Notice:
- DECnet is not supported over the CIXCD controller and
has been known to cause system crashes in the past.
The LAT Protocol:
The following commands can be used within LATCP and its associated
system startup command procedures:
o LATCP> CREATE LINK LAT$LINK /DEVICE=FXA0 /DECNET /STATE=ON
- This command should be placed in the system specific
command procedure, SYS$MANAGER:LAT$SYSTARTUP.COM,
prior to the LATCP> SET NODE /STATE=ON command being
executed.
- This will keep LAT from using whatever LAN controller
the LAN executive code returns to LAT when it is asked
for a LAN device.
- When the LATCP> SET NODE /STATE=ON command is
executed, a check is made to see if there is a LAT
LINK present or not thus making it vital that the LAT
LINK be there before the command is executed.
- The name of the LAT LINK can be pretty much anything
with LAT$LINK being the default name used.
- The LATCP> CREATE LINK command can be executed on the
fly from within the LATCP utility after the previous
LAT LINK has been deleted via the LATCP> DELETE LINK
command where the name of the actual LINK is that
which is displayed via the LATCP> SHOW LINK command.
- The /DECNET qualifier is used by default and can be
left off if so desired, but it being present does make
clear that the AA-00-04-00-XX-XX form of the physical
address should be used with the LAT protocol so that
PC clients that make use of static tables that tend to
assume that the AA-00-04-00-XX-XX form of the
physical address is being used.
+ PATHWORKS DOS/MAC LAT clients are examples of
such things.
Digital TCP/IP Services for OpenVMS VAX:
The FDDI controller can be added into the UCX configuration via the
command procedure SYS$MANAGER:UCX$CONFIG.COM using the following steps:
o In the case of UCX, it probably would not be a bad idea to
have it shut down while changes are being made.
- Make sure that other applications that make use of the
UCX software are shut down too such as PATHWORKS,
which can be stopped by executing the command
procedures:
+ SYS$STARTUP:PWRK$SHUTDOWN.COM
+ SYS$STARTUP:UCX$PWIP_SHUTDOWN.COM
o When the SYS$MANAGER:UCX$CONFIG.COM command procedure is
executed, a list of configuration options should be displayed
with one of them being the core environment, which is the
option to take.
o The next list of options should display one that references
the interfaces, which is the option to take.
o It is at this point that the command procedure will go out and
ask if you want to configure TCP/IP to run over a specific LAN
controller with the FDDI controller being one of them and
being referred to as FF0.
o To keep UCX from using the CSMACD controller, the following
commands can be used:
UCX> SHOW CONFIGURATION INTERFACE
+ This will show the interface name which is
probably XE0.
+ The system's TCP/IP host address should be
displayed.
UCX> SHOW CONFIGURATION COMMUNICATION
+ The systems' TCP/IP host name should be
displayed at or near the top.
UCX> SET CONFIGURATION NOINTERFACE xe0
UCX> SET NOHOST xe0_host_name /ADDRESS=xe0_host_address
+ The "xe0_host_name" would be whatever the
systems TCP/IP name is set to.
+ The "xe0_host_address" would be whatever the
systems TCP/IP address is set to.
o The UCX software will need to be stopped, if it has not
already been so, and then started again via the following
command procedures:
- SYS$STARTUP:UCX$STARTUP.COM
- SYS$STARTUP:UCX$PWIP_STARTUP.COM
o Any other layered products that depend upon UCX can now be
started up.
The PATHWORKS Server Software:
On the whole, there really is not much that needs to be changed since
the PATHWORKS server tends to go wherever the DECnet and/or TCP/IP
protocols are configured to go. There are some things to be aware of in
regards to some of the other protocols that might be in use.
Fortunately, there are some simple logical names that can be defined to
help direct things in the correct direction and they can be set up as
follows:
o DEFINE /SYSTEM /EXECUTIVE NETBIOS$DEVICE FXA0
- This get NETbios, which is used with the DECnet
protocol to use the correct controller.
o DEFINE /SYSTEM /EXECUTIVE PWRK$KNBDAEMON_DEVICE FXA0
- This the NETbios portion that is used with the TCP/IP
protocol stack.
o DEFINE /SYSTEM /EXECUTIVE PWRK$NETBEUI_DEVICE FXA0
- This used with the generic NETbeui protocol which is
used with LAN Manager Remote Booting.
o The PATHWORKS server will need to be stop and started in order
for these changes to take place.
All three of these logical names can be set up either in the
SYS$MANAGER:SYLOGICALS.COM or SYS$STARTUP:PWRK$LOGICALS.COM command
procedures. The preference would be to make use of the
SYS$MANAGER:SYLOGICALS.COM command procedure so as to not have to worry
about any changes being made to the SYS$STARTUP:PWRK$LOGICALS.COM
command procedure as a result of a PATHWORKS software upgrade.
One final note in regards to the PATHWORKS server software and that is
to make sure that the current V5.0C ECO 2 software is being used as
there were some issues with working with FDDI in the past.
The LASTport Disk/Tape Protocol:
By default, the LASTport protocol will make use of all available LAN
controllers configured on the system. This is not a problem except for
in the area of general performance. When there are multiple LAN
controllers available, they are all used in a round robin fashion. If
the CSMACD controller is still connected to the LAN, this works fine.
If the CSMACD controller is not connected to the LAN, it will appear as
if there is a PDU getting lost due to there not being any kind of an
acknowledgement being received. There is a way to control what LAN
controller(s) the LASTport protocol may make use of and the following
steps will illustrate how this is done:
o EDIT SYS$STARTUP:ESS$LAST_STARTUP.DAT
- At the end of this text file is usually an uncommented
line as follows:
"ALL_CONTROLLERS = ON"
- Change this line so that "ON" is now "OFF".
- After the above mentioned command line, add a line
that like the following:
"DEVICE = (FXA)"
o These changes can also be done on the fly via the following
commands:
LASTCP> STOP TRANSPORT
LASTCP> START TRANSPORT /DEVICE=(FXA)
The SYS$STARTUP:ESS$LAST_STARTUP.DAT file is used as a way to pass in
parameters to the SYS$SYSTEM:ESS$LASTCP.EXE control program when the
LASTport protocol is being started. In specific, the entries in the
file are used as qualifiers to the LASTCP> START TRANSPORT command.
The SCA Protocol:
Having the SCA protocol running over all available LAN controllers will
not really cause any problem. There are some Macro-32 example programs
as follows that can be used to control the SCA protocol:
o SYS$EXAMPLES:LAVC$START_BUS.MAR
- This program will start the SCA protocol on whatever
LAN controller is passed into it on the command line.
- The following is an easy way to start the SCA protocol
on the FDDI controller:
+ MCR SYS$EXAMPLES:LAVC$START_BUS FXA
o SYS$EXAMPLES:LAVC$STOP_BUS.MAR
- This program will start the SCA protocol on whatever
LAN controller is passed into it on the command line.
- The following is an easy way to stop the SCA protocol
on the CSMACD controller:
+ MCR SYS$EXAMPLES:LAVC$STOP_BUS EXA
o Only the first three letters of the LAN controller are needed
or accepted.
o The Macro-32 source code may be all that is present, thus
requiring the code to be assembled and linked as follows:
$ SET DEFAULT SYS$EXAMPLES
$ MACRO LAVC$START_BUS
$ LINK LAVC$START_BUS
$ MACRO LAVC$STOP_BUS
$ LINK LAVC$STOP_BUS
The Terminal Server Manager:
The DECnet database can be modified/updated in regards to the service
circuit being used via TSM. The following TSM commands may be used to
do this task:
o TSM> SET SERVER ALL CIRCUIT MFA-0
- This update the circuit definitions for all of the
terminal servers configured in the TSM database.
o TSM> RESTORE SERVER ALL
- This command will attempt to update the DECnet
database for all of the terminal servers configured in
the TSM database with a non-zero DECnet address.
- The most common problem that would keep this from
working would be the lack of a DECnet proxy to an
account with the correct privileges.
- The logical name TSM$NO_PROXY defined as follows can
be used to have TSM prompt for an appropriate username
and password to make use of to establish a NML
connection to DECnet to update the database:
DEFINE TSM$NO_PROXY "TRUE"
- The use of the TSM$NO_PROXY logical can save time in
worrying about making sure proxy access works.
Final Notes:
The use of the SDA> SHOW LAN /FULL command is the best method to check
to see what protocols are running over what LAN controller and with what
physical address. This leads into a bit of FDDI controller trivia that
some may not be aware of and that is that a FDDI controller is able to
function with more than one physical address. That is why one should
check via the SDA> SHOW LAN /FDDI /FULL command to see what physical
address is being used by the different protocols configured for the FDDI
controller. This is not an issue with the CSMACD controllers as they
can only be configured to use one physical address.
This information has hopefully covered how to configure the various
protocols that might be in use.
Good Luck,
Bill
|
|
.3 is a great guide. The reference to v5.0C ECO2 dates the article
(you key word in that sentence is "current", which would be v5.0E at
this point). And even v5.0E has a DECnet NETBIOS/FDDI problem in a
cluster if you have a DECnet cluster alias define and the PATHWORKS
NetBIOS cluster alias name is the same name (patch is available).
Also, I'd not recommend running UCX$PWIP_STARTUP (not sure about
UCX$PWIP_SHUTDOWN) especially after running UCX$STARTUP. In UCX 3.1
that was necessary, but in 3.2 and later you enable the PWIP driver in
UCX$CONFIG (Select 4/1/1) and then UCX$STARTUP starts the UCX$PWIP_ACP
process. I've seen folks have problem when UCX$STARTUP starts PWIP and
then they execute UCX$PWIP_STARTUP.COM.
Paul
|