Yes, by using MultiNet's paired network interface support and pseudo devices.
If the system is to be accessed via the IP address 192.41.228.71:
MULTINET:LOCAL_INITIALIZATION.COM
an MU SET/INTERFACE/COMMON_LINK
command instructing MultiNet that the interfaces are on a common network: MU SET/INTERFACE/COMMON_LINK=SE1 SE0
Here is an example configuration that demonstrates the above:
$ MULTINET CONFIG MultiNet Network Configuration Utility [Reading in MAXIMUM configuration from MULTINET:MULTINET.EXE] [Reading in configuration from MULTINET:NETWORK_DEVICES.CONFIGURATION] NET-CONFIG> show Interface Adapter CSR Flags/ Address Vector --------- ------- ------- ------ se0 (Shared VMS Ethernet/FDDI) -NONE- -NONE- -NONE- [TCP/IP: 192.168.1.1,IP-SubNet: 255.255.255.0] [VMS Device: EWA0, Link Level: Ethernet] se1 (Shared VMS Ethernet/FDDI) -NONE- -NONE- -NONE- [TCP/IP: 192.168.1.2,IP-SubNet: 255.255.255.0] [VMS Device: EWB0, Link Level: Ethernet] pd0 (Secondary Ethernet Address) -NONE- -NONE- -NONE- [TCP/IP:192.41.228.71,IP-SubNet:255.255.255.0] [Hardware-Device: se0] $ TYPE MULTINET:LOCAL_INITIALIZATION.COM $ MULTINET SET/INTERFACE/COMMON_LINK=(SE1) SE0
With this configuration if either SE0 or SE1 is brought down with the command MU SET/INTERFACE/DOWN or if a fatal error is detected on either interface, the pseudo device and any routing table entries using that device will failover to the other. Also, when sending a packet if one of the interfaces is busy, the packet will be sent out via the other interface, resulting in better throughput.
The configuration file that is being referred to is the SNMP_AGENT.CONFIGURATION
file and the error indicates that the format of the file is invalid. The file should be edited and corrected. If you are not using SNMP you can disable it. SNMP is enabled by default. If SNMP is not being used on the system, it can be disabled by issuing the following:
$ MULTINET CONFIGURE/SERVER SERVER-CONFIG> SELECT SNMP [The Selected SERVER entry is now SNMP] SERVER-CONFIG> DISABLE SNMP SERVER-CONFIG> EXIT $ @MULTINET:START_SERVER RESTART
Yes, a kernel variable needs to be set by the following command:
$ MULTINET SET/KERNEL NETWORK_PTY_IS_REMOTE 1
This command has to be executed each time MultiNet is started. If it exists, MultiNet executes the file MULTINET:LOCAL_INITIALIZATION.COM
after starting. You can add the SET/KERNEL
command to the file if it already exists, or create the file and add the SET/KERNEL
command if the file does not already exist.
To be successfully sent, attachments to email messages cannot be larger than the page file quota set in the user's account. If this has been a problem, just increase the user's PGFLQUOTA
appropriately.
.rhost
and my host.equiv
files seem correct?There are a number of things that effect a valid connection for the R-services:
SYSTEM
account on the server, the server will not use the HOST.EQUIV
file in the MULTINET
directory. The entry MUST be in the .rhost
file in the SYS$LOGIN
directory of the system account.
.rhost
file and HOST.EQUIV
file cannot be ip addresses and must be the fully qualified domain name.
MOUNT RMTalloc device
?Be sure that SYLOGIN.COM and LOGIN.COM have the following two lines:
VERIFY = 'F$VERIFY'
and
IF F$MODE() .eqs. "OTHER" THEN EXIT.
If problems still occur, verify in UAF that the account they are logging into on the remote server is not executing some other command procedure at startup. Check LGICMD
in UAF. If they are, add the 2 lines to that file also.
Process Software will need the following information in order to do a speedy crash analysis.
All information on the crash MUST include:
$ ANALYZE/CRASH_DUMP SDA> read/exec (don't need this output) SDA> show crash SDA> format @r3 (optional) SDA> format @r5 (optional) - if this shows up as UCB$... structure, then do SDA> show device/address=@r5 SDA> show stack
This information should be sent to Process Software’s Technical Support Department to expedite the crash analysis. In most cases a valid system dump from the crash will also have to be provided.
Using TFTP TFTP.FILENAME-TRANSLATIONS
does not work. The correct translation is in the file but the directories are not being translated.
Make sure the directories in the file are listed from deepest or most specific to least deep or less specific.
For example:
[MULTINET.AXP_COMMON.MULTINET] [MULTINET.AXP_COMMON] [MULTINET]
MultiNet must be installed once for each version of OpenVMS. Each of the installs must be done into a new MultiNet root.