March 12,1990 M20-4, Part II

Change 1

CONTENTS\
CHAPTER 13. NETWORK TROUBLESHOOTING

PARAGRAPH PAGE\
13.01
Purpose\...\...\...\...\...\...\...\...\...\...\...\...\...\...\...\...\...\...
13-1\
13.02 Reference
Materials\...\...\...\...\...\...\...\...\...\...\...\...\...\... 13-1\
13.03 TYMNET Transport
Troubleshooting\...\...\...\...\...\...\...\...\..... 13-1\
13.04 WANGBAND Transport
Troubleshooting\...\...\...\...\...\...\...\...\... 13-4\
13.05 File Transfer
Troubleshooting\...\...\...\...\...\...\...\...\...\..... 13-6\
13.06 Remote Logon
Troubleshooting\...\...\...\...\...\...\...\...\...\...\... 13-9\
13.07 Networked Wang OFFICE
Troubleshooting\...\...\...\...\...\...\...\... 13-9\
13.08 Network Recovery Components and
Procedures\...\...\...\...\...\.... 13-10\
13.09 Disaster
Recovery\...\...\...\...\...\...\...\...\...\...\...\...\...\.....
13-11\
13.10 Software
Installation\...\...\...\...\...\...\...\...\...\...\...\...\.... 13-11\
13.11 Node Administrator Reporting
Requirements\...\...\...\...\...\..... 13-11

13-i

March 12,1990 M20-4, Part II

Change 1

**CHAPTER 13. NETWORK TROUBLESHOOTING**

13.01 PURPOSE

a\. This chapter provides guidelines that should be followed by Node
Administrators during the identification and isolation of network
problems. In addition, procedures for evaluating network problems to the
VBA (Veterans Benefit Administration) Network Coordinators are included.
(See ch. I for additional information.)

b\. Network troubleshooting involves technical knowledge of both Wang
hardware and software, TYMNET hardware and software, and the VADATS
network. Due to the complexity of network troubleshooting, not all
problems can be isolated and easily resolved by following step-by-step
guidelines. For this reason, it is imperative that VBA Node
Administrators work closely with the VBA Network Coordinators during the
reporting, identification, isolation and troubleshooting process. The
troubleshooting guidelines presented below should be used by Node
Administrators to identify problems on the local system related to the
TYMNET and WANGBAND transports and various network applications (File
Transfer, Remote Logon, and Wang OFFICE). If there are any questions or
problems using these guidelines, the Network Coordinator should be
contacted immediately.

13.02 REFERENCE MATERIALS

The following Wang publications should be maintained for reference
purposes. Refer to Wang\'s Literature Catalog for a list of the most
recent versions.

VA OASIS (n) Network Manual

Software Bulletin for Operating System

VS NetCore (Standard Components) Software Bulletin

VS Network Control and Monitoring Guide

WSN (Wang Systems Networking) VS Network Configuration Guide

13.03 TYMNET TRANSPORT TROUBLESHOOTING

The TYMNET transport is used to establish communication sessions between
local system(s) and remote sites on the OASIS network. The
troubleshooting guidelines presented below should be used by VBA Node
Administrators when identifying and isolating problems on the local
system. If there are any questions with the guidelines or problems that
cannot be resolved at a local node, the VBA Network Coordinator should
be contacted immediately for assistance and problem resolution.

a\. Normal Operations Following IPL (Initial Program Load). The TCB3
lights on the front panel of the 6554 cabinet provide an excellent
indicator of network connectivity between the Wang VS and the TYMNET
mini-engine. Following an IPL of the VS, the following LED (Light
Emitting Diode) lights should be displayed on the front panel of the
6554 cabinet:

LED STATUS AND INTERPRETATION

1 Blinking rapidly (several) times a second indicating that the
microcode has been successfully downloaded to the TCB3

2 Blinking slower than LED 1 (approximately once every 305 seconds)

indicating that the TCB3 is receiving a polling signal form the TYMNET
engine.

8 Lit continuously indicating that the TCB3 hardware is operating
properly.

13-1

M20-4, Part II March 12, 1990

Change 1

b\. Normal Operations During Active Communication Sessions. TCB3 LED
lights 1, 2, and 8 should not change during active communication
sessions. During an active session, LED 5 will be ON indicating that the
system has established at least one active session on the TYMNET
transport (e.g., File Transfer, Remote Logon). During an active session
LED lights 3, 4, and 6 will be activated at various intervals as data
are transmitted between the local and remote systems. If LED 7 is
activated at any time, this indicates that the TCB3 is temporarily
overloaded and is refusing to accept new traffic.

c\. Possible Error Conditions and Troubleshooting Guidelines

\(1\) LED 8 [Blinking]{.underline}. If LED 8 is blinking at any time
following an IPL, this indicates that either the TCB3 diagnostics are
running or that a TCB3 hardware error has been detected by the
diagnostic program. In addition, if LED I is not flashing the microcode
is not loaded to the TCB3 and a hardware problem is suspected. Before
placing a call to Wang Customer Engineering, the Node Administrator
should verity the following:

\(a\) Network Connecivity Cannot Be Established. Logon to system
101DVB01 or 101DVB02 using the \@ATTACH@ program with the \"DVB\" User
ID and \"FIELD\" password. A \"DLP Transport Error\" should be
immediately displayed by the \@ATTACH@ program.

\(b\) Physical Connectivity Is Correct. Check that the connectors are
solidly attached at both ends of the coaxial cables that connect the VS
to the 6554. In addition, verify that the cross-over cable is correctly
attached to the TYMNET mini-engine. Check that the coaxial cables that
run from the CPU (Central Processing Unit) are connected to the correct
port (as specified in the GENEDIT file @ CONFIG @).

\(c\) Once Wang has been notified, follow the procedures for reporting
the problem to the VBA Network Coordinator (par. 13.11).

\(2\) LED 8 ON, LEDS 1-7 OFF. If LED 8 is ON, this indicates that the
TCB3 has successfully passed the diagnostic tests following an IPL.
However, since LED 1 is OFF, microcode has not downloaded to the TCB3
successfully. When this occurs, the Operator\'s Console should also
display the message \"UNABLE TO LOAD MICROCODE TO TC DEVICE I.\"

\(a\) Before attempting to determine the cause of these problems, you
should force a microcode download to the TCB3 by completing the
following steps:

[1]{.underline}. From the Operator\'s Console, press PF12
(Telecommunications) and then PF3 (Communications Access).

[2]{.underline}. Press PF4 (Inhibit Communications Immediately) and then
press Enter.

[3]{.underline}. Press the CLEAR Button of the LED display to force the
microcode to download.

[4]{.underline}. Press PF1 (Menu) to return to the Telecommunications
Menu.

[5]{.underline}. Press PF3 (Communications Access) and press PF2 (Allow
Communications). Press Enter to allow communications to all systems.

\(b\) If the steps above do not force the microcode to download
successfully to the TCB3 (LED 1 will be blinking, LED 2 will be blinking
slowly, and LED 8 will be ON continuously when the microcode download is
successful), verify the following possible causes:

[1.]{.underline} Physical Connectivity Is Correct. Check that the
connectors are solidly attached at both ends of the coaxial cables that
connect the VS to the 6554. Check that the coaxial cables that run from
the CPU are connected to the correct port (as specified in the GENEDIT
file @ CONFIG @).

13-2

March 12,1990 M20-4, Part II

Change 1

[2.]{.underline} GENEDIT. The TCB3 must be configured on the second
physical (port 1) as device address I in the active configuration file.
If the TCB3 has been changed to another physical port, the microcode
will not download successfully. Under no circumstances should the TCB3
be reconfigured at VBA sites since the communications software file
(@CNSCOM@) also uses these device address standards.

[3.]{.underline} Incorrect Switch Settings on the TCB3

[a]{.underline}. If the TCB3 board has been recently replaced or
modified by a Wang representative, it is possible that the switch
settings have not been correctly set for the OASIS network. The
following switch settings for the TCB3 are required for successful
operations using the TYMNET transport on the OASIS Network:

8 SWITCH SET 5 SWITCH SET\
\
1 =OFF 1 =ON\
2 = OFF 2 = ON\
3 = OFF 3 = ON\
4=OFF 4 = 0FF\
5 = ON 5 = ON\
6 = ON\
7 =OFF\
8 = OFF

[b]{.underline}. Please note that when a new TCB3 board is shipped by
Wang, the switch settings do not usually match those specified above.
For this reason, it is recommended that a copy of the switch settings be
posted on the top of the 6554 cabinet for easy reference by both the
Node Administrator and Wang Representatives.

[c]{.underline}. If none of the above problems can be identified by the
Node Administrator, it is possible that internal connections within the
6554 need to be checked by the Wang Customer Engineer. Follow the
procedures outlined in paragraph 13.11 for placing the service call and
reporting the problem to the Network Coordinator.

\(3\) LED 1 BLINKING, 8 ON and 2 OFF or LED 1 BLINKING, 2 BLINKING, 3
ON, and 8 ON. In most instances, these LED light sequences indicate that
the TCB3 is not receiving a correct polling signal from the TYMNET mini
engine and that the Node Administrator must contact the VADATS Control
Center in Romney, West Virginia at (FTS)

8-651-3001. Before calling, verify the following:

\(a\) Network Connectivity Cannot Be Established. Logon to system
101VB01 or 101DVB02 using the \@ATTACH@ program with the \"DVB\" User ID
and \"FIELD\" password. A \"DLP Transport Error\" should be immediately
displayed by the \@ATTACH@ program.

\(b\) Crossover cable to TYMNET mini-engine is connected correctly.
Verify that the cross-over cable that connects the 6554 to the TYMNET
mini-engine is correctly installed or has not been disconnected from
either end.

\(c\) Sites with 2 Systems. Check that TYMNET network connectivity can
be established on the other system by remotely logging on to system
101DVB01 or 101DVB02 using the RLOGON program. This information will be
needed when placing the call to Romney, West Virginia.

\(d\) After the above items have been verified, place the call to
Romney, West Virginia. Identify the VBA field station and request that
the operational status of your node be checked. In sites with two
systems, advise whether both systems are affected by the problem. The
VADATS Control Center will verify the status of the node and will
correct any identifiable problem. If the problem is reported by VADATS
to TYMNET personnel, the user will be advised. Once Romney, West
Virginia has been notified, follow the procedures for reporting the
problem to the VBA Network Coordinator (see par. 13.1 lb).

M20-4, Part II March 12,1990 Change 1

\(4\) LED 1 BLINKING, 2 BLINKING, 5 ON and 8 ON. If this TCB3 LED light
sequence is displayed and Network connectivity cannot be established
(@ATTACH@ returns a \"DLP TRANSPORT ERROR\" message and CNSMGR CONECTST
fails to remote systems), the TCB3 most likely froze during an active
session and needs to be cleared.

\(a\) Before attempting to determine the cause of these problems, the
user should force a microcode download to the TCB3 by completing the
following steps:

[1]{.underline} \_ From the Operator\'s Console, press PF12
(Telecommunications) and then PF3 (Communications Access).

[2]{.underline}. Press PF4 (Inhibit Communications Immediately) and then
press Enter.

[3]{.underline}. Press the CLEAR Button of the LED display to force the
microcode to download.

[4]{.underline} -Press PF1 (Menu) to return to the Telecommunications
Menu.

[5]{.underline} Press PF3 (Communications Access) and press PF2 (Allow
Communications). Press Enter to allow communications to all systems.

\(b\) The above procedures will force the microcode to be downloaded to
the TCB3. Following successful microcode downloading, the LED I light
should be blinking rapidly, the LED 2 light will be solid. At this
point, verify that network connectivity can be established to other
systems (via RLOGON or CNSMGR CONECTST functions). If communications
cannot be established, report the problem to the Network Coordinator
immediately.

\(5\) LEDs 1-8 OFF. If no LED lights are displayed on the 6554, this
generally indicates that the unit is not receiving power. Verify that
the power cord to the 6554 is plugged in and that the unit is powered
ON. If the problem persists, a service call should be placed to Wang
Customer Engineering so that the power supply to the 6554 can be
checked. Follow the reporting procedures outline in paragraph 13.1 1.

\(6\) Other LED Sequences. If the Node Administrator has lost network
connectivity to remote systems and the TCB3 is displaying a sequence of
lights other than those described in subparagraphs (1) through (5)
above, the Network Coordinator should be contacted immediately.

13.04 WANGBAND TRANSPORT TROUBLESHOOTING

a\. The information presented in this section applies only to the sites
in which multiple (2 or more) systems have been installed. The WANGBAND
transport is used in these sites to establish communication sessions
between VS systems connected to a local area network (FASTLAN) by CIU
(Cable Interface Unit) devices. The Wang CNS (Communications Networking
Services) has been configured to take advantage of the high-speed
WANGBAND transport when communication sessions are established between
systems with CIUs. If a failure occurs on the WANGBAND transport (e.g.,
a CIU device malfunction), the CNS configuration will use alternate
routing tables to establish CNS communication sessions (e.g., File
Transfer and the Store and Forward OFFICE mail delivery program) using
the alternate TYMNET transport.

b\. The troubleshooting associated with the WANGBAND transport will, in
most cases, be the responsibility of the VBA Node Administrator since
this transport is restricted to use at the local site. However, when a
problem with the WANGBAND transport is identified (e.g., RLOGON between
the local systems is unsuccessful or CIU device malfunctions messages
are noted on the Operator\'s Console), the Network Coordinator will be
able to assist with problem identification and isolation by remotely
logging on to the system via the TYMNET transport.

c\. Hardware problems associated with the WANGBAND transport will
usually require the assistance of a Wang Customer Engineer for
resolution. When a suspected hardware problem is identified and a
service call has been made, the Node Administrator should follow the
reporting procedures in paragraph 13.1 1.

13-4

March 12, 1990 M20-4, Part II

Change 1

d\. The WANGBAND troubleshooting information presented below should be
used as a reference by VBA Node Administrators. When reviewing this
information, please note that, unlike LED light 8 on the TCB3, when the
CIU side panel light 8 remains ON, a hardware error has been detected on
the CIU. The CIU side panel light 8 should always be checked on each
system when problems are suspected with the WANGBAND transport.

e\. General Troubleshooting

\(1\) Cable Connectors. Check cable connectors, especially if anything
has been moved or changed. Try another FASTLAN outlet on the same tap if
one is known to be good; or try an outlet on a different tap. Check the
RF (radio frequency) connections from the CIU to the FASTLAN outlet. The
gold-colored connectors are left-hand threaded; the silver-colored are
right-hand threaded.

\(2\) CIU Power-up Diagnostics. Check the power light on the front. If
it continues to blink after 30 seconds, check the lights on the side.
These checks test the CIU CPU status, memory, timing and interrupt
circuitry, bit communications controller, and modem.

\(3\) CIU Front Panel Lights. The CIU front panel lights have the
following LEDs and RESET features:

\(a\) POWER. This indicates that the CIU has power. The light flashes
for 30 seconds on power up while diagnostics are running (the number of
the test running is displayed through the side panel). If a test fails,
its light pattern remains displayed. After the diagnostics are complete,
the POWER light stays on.

\(b\) SESSION ACTIVE. This light indicates that there is at least one
active user session. This would include a virtual connection between the
file transfer program and any other system, a remote logon from a user
on the local system to another system, or a remote logon from a user on
another system to the local system.

\(c\) LINK TIMEOUT. This light indicates a failure of the CIU
transmitter to stop transmitting within the allowed maximum time. The
CIU shuts down at that time, in order to avoid monopolizing the WANGBAND
channel and preventing any other system from being able to transmit.

\(d\) LINK ERROR RESET. This switch resets the link timeout light
mentioned above.

4\. CIU Side Panel Lights During Normal Operations. The side panel
lights provide both diagnostic and normal activity information. The
light marked \"F\" is a memory parity error indicator. Interpretation of
the other lights depends on light 8 as follows:

LED Name Interpretation\
\
8 Error If ON, refer to subparagraph (5) for interpretation.\
If off, use the description below for network activity\
indicators.\
\
7 Host Transmit This light is illuminated every time a message is sent\
to the local VS.\
\
6 Host Receive This light is toggled every time it message is received\
from the local VS.\
\
5 Host Enable When lit, the CIU has completed initialization (include-\
ing cable address verification), and requests from the\
local VS are enabled.\
\
4 Network Enable When lit, the CIU has enabled transmission and\
reception from the network (Data Terminal Ready).

13-5

M20-4, Part II March 12, 1990

Change 1

LED Name Interpretation\
\
3 Network Receive This light is toggled every time a message is
received\
from the network.\
\
2 Network Transmit This light is toggled each time a message is
transmitted\
to the network.\
\
1 Activity At each internal interrupt, this LED is turned on if the\
CIU is in the \'active\' state, and turned off, or flashing\
slowly, the CIU is relatively idle. If it appears to be\
almost constantly on, the CIU is heavily loaded.

\(5\) CIU Side Panel Lights- Error Indicators. If light 8 is ON, a
hardware problem with the CIU has been detected. The other side panel
lights can be used in conjunction with the \"ON\" light 8 to identify
specific problems as follows:

Lights Interpretation

8 ON: indicating a \'hard\' error. Other ON lights are interpreted as
follows:

Network transmit status error. The most likely cause is a missing or
broken drop cable, or failure in the main cable. Another port on the tap
(or another tap) can be tested by connecting the CIU to it.

1 Unrecognizable interrupt. Normally, this indicates a hardware problem.

1 and 2 Data Terminal Ready dropped. Possible hardware problem.

3 Data Set Ready dropped. Possible hardware problem, the \"Link
Timeout\"

LED on the front panel may also be on.

I and 3 Duplicate cable address. Another CIU with the same cable is
active on the network at the time the local CIU is IPL\'d. Check the
configuration file for network addresses matching the address assigned
to the local system.

Light 8 only Generally indicates that microcode did not load and is
probably a configuration

problem; check cable connections and the \@CONFIG@ file with GENEDIT.

The CIU device must be configured as the third physical port (port 2) in

GENEDIT; the communications software file (@CNSCOM@) also uses this

address.

If one of these errors occurs, the CIU will disable the serial data link
hardware, causing the \"ASSISTANCE REQUIRED\" message to appear on the
VS operator\'s console. All active circuits will be cleared by the local
VS.

13.05 FILE TRANSFER TROUBLESHOOTING

The following checklist is provided to assist System Administrators
during the isolation of FT (File Transfer) program problems.

13-6

March 12,1990 M204, Part II

Change 1

a\. FT Session Establishment Problems

\(1\) Check that the background task \$CNSTSK\$ and the dedicated system
tasks FTMTSK and SESMGR are running. Press PF7 (NON-INTERACTIVE tasks)
from the Operator Console to verify that these tasks are running.

\(2\) Check that physical connectivity can be established to the remote
system by logging on (running the program RLOGON) or performing a
CONECTST using the CNSMGR program. (See par. 3.05 for instructions on
performing CONECTST.)

\(3\) Run the program CNSMGR to verify that the FTM (File Transfer
Manager) Program is attached to CNS by performing the following steps:

\(a\) Run CNSMGR.

\(b\) Press PF7 (Apps/Sessions).

No Alerts Wang Laboratories, Inc. 15 Aug

[Distributed Management Facility 12:12]{.underline}

\- CNS Manager Detailed Status -

Select Application or Session to Monitor

Manager Status: ACTIVE CNS Status: ACTIVE

Manager Rev: 01.00.01 CNS Rev: 04.01.04

System: 105DVB01

Place a non-blank character beside the desired application(s) to select:

[Local Application Name]{.underline} [Application Status]{.underline}
[\# Active Sessions]{.underline}

S&F Attached 0

FTM Attached 0

\@REMOTE Attached 0

105DVB01SNAMCPAR137CUA Attached 0

Press (ENTER) to update status or (17) for Event Inquiry

\(7\) Applications (16) Return

\(8\) Sessions (11) Update 060 secs (32) Menu

**Figure 13-1. Applications Currently Attached to CNS**

\(c\) The name and status of all applications currently attached to CNS
will be displayed. FTM is attached to CNS if it is listed as
\"Attached\" in the \"App Status\" column (fig. 13-1).

\(d\) If FTM is not attached, it can be forced to attach to CNS by
\"inhibiting\" FT service and then \"allowing\" it from the Operator
Console.

\(4\) Verify that the WSN Transport Status for Tymnet and WANGBAND (for
Sites with multiple CPU\'S) is \"enabled.\"

13-7

M20-4, Part II March 12,1990 Change 1

\(a\) RUN CNSMGR

\(b\) Press PF5 (Transports).

No Alerts Wang Laboratories, Inc. 15 Aug

[Distributed Management Facility 12:14]{.underline}

\- CNS Manager Detailed Status -

Select CNS Transport for Management

Manager Status: ACTIVE CNS Status: ACTIVE

Manager Rev: 01.00.01 CNS Rev: 04.01.04

System: 105DVB01

Place a non-blank character beside the desired application(s) to select:

[Transport]{.underline} [Status]{.underline} [Transport
Name]{.underline} [Status]{.underline}

TYMNET Enabled

WANGBAND Enabled

Press (ENTER) to update status or (17) for Event Inquiry

\(7\) Enable (10) Manage transport(s) (15) Return

\(8\) Disable (11) Update 060 secs (32) Menu

**Figure 13-2. CNS Control/Monitor Transports**

\(c\) The name (Tymnet, WANGBAND) of the WSN transports will be
displayed (fig. 13-2).

\(d\) If the Transport Status \"Disabled,\" the Transport should be
manually Enabled as follows: Position the cursor next to the Transport
name. Press PF7 (Enable) to mark the transport for an \"ENABLE.\" Press
Enter to enable the transport. The status field will change to \"PEND
ENABLE\" when Enter is pressed, then to \"ENABLED\" when the transport
has actually been enabled by the CNS software.

\(5\) Check with the System Administrator on the remote system to verify
that FT Service has been allowed to the system.

b\. General FT Problems

\(1\) Print and review the FT Log to provide detailed information about
the specific transfer requests.

\(2\) Check that the DEFAULTXFGROUP is accurately named and defined by
reviewing it through the TRANSFER program auxiliary functions.

\(3\) For Transfer retrieval problems, check that the system has read
access to the File Protection Class of the file or document that the
system is trying to retrieve. This must be checked by a Security
Administrator on the remote system by running SECURITY and pressing PF12
(Inter-System Security) for the system\'s Wangnet ID. NOTE.- As defined
in chapter 11, retrieval requests will be processed only for files and
documents that have a File Protection Class of \"X\" on the remote
system.

13-8

March 12,1990 M20-4, Part II

Change 1

c\. Problems Associated With Locating a Transferred File or Document

\(1\) Print and check the FT Log to determine where the transferred file
or document has been placed on the system. Since the USEROVERRIDE option
has been set to \"YES\" in the DEFAULTXFGROUP, remote users transferring
files to the system can specify where (filename, library, and volume)
the file will be stored on your system. Similarly, remote users
transferring word processing documents to your system are allowed to
specify a Document ID when the document is transferred.

\(2\) Review the parameters in the DEFAULTXFGROUP to determine the
location of transferred files and documents for which the remote user
has not specified a file name or Document ID.

d\. Transferred Files Remain on the Transmit Queue

\(1\) Check that the \$CNSTSK\$ is running as a background task and that
the FTM is attached to CNS. (See par. 13.05a(3).)

\(2\) If a document or file is released from a HOLD status on the
transmit queue and briefly shows an XFERING status before returning to
HOLD, check the name of the volume for the remote system by pressing
PF13 (Remote Info) from the Transmit Queue screen. An unmounted volume
or wrong volume name for the remote system will often cause this to
occur.

13.06 REMOTE LOGON TROUBLESHOOTING

The following checklist is provided to assist System Administrators
during the isolation of problems related to the remote logon (RLOGON)
program.

a\. Unable to Log on the Remote System

\(1\) Check that the dedicated system tasks SESMGR and the initiators
\@RATTSK@ and \@RMTIPC@ are running. The task \$RATGTE\$ is for inbound
\@ATTACH@ sessions only. Press PF7 (Non Interactive Tasks) from the
Operator Console to verify.

\(2\) Check the validity of the User ID and password being used. The
RLOGON program will notify the user when an invalid User ID and/or
password are used.

\(3\) Check to see whether other users are able to log on to the remote
system.

\(4\) Have logons been inhibited by the remote system?

\(5\) Have enough Wangnet Workstations been configured in the GENEDIT
file on the remote VS? (see ch. 2).

13.07 NETWORKED WANG OFFICE TROUBLESHOOTING

The following checklist is provided to assist System Administrators
during the isolation of problems related to Wang OFFICE.

a\. Mail Is Not Being Sent to a Remote System. Check for physical
connectivity to the remote system by trying a RLOGON or CONECTST with
the CNSMGR program. Verify that the TRANSPORT Status is enabled by
running the program CNSMGR. (See par. 13.05 for complete instructions on
enabling transports.) Are \$CNSTSK\$, \$LOGTSK\$, and \$SFMGR\$ running
in background (Procedure Queue)? If \$SFMGR\$ is not running it can be
submitted through the Wang Office Administrative Functions Menu. If
\$CNSTSK\$ and \$LOGTSK\$ are not running, run WSNHALT and, after 5
minutes, run WSNSTART.

13-9

M20-4, Part II March 12,1990 Change 1

b\. Local Mail Is Not Being Delivered. Is \$WOAMGR\$ running in the
background (Procedure Queue)? If not, it can be submitted through the
Wang Office Administrative Functions Menu.

c\. User Access to Wang Office Is Denied. Is the Wang Office volume
mounted as secure? If your system is inadvertently opened to users
without the Wang Office volume mounted as secure, users will not be
allowed access to OFFICE. To correct the problem, change the volume to
\"SECURE=YES\" (PF 10 (Disks) from the Operators Console) and have all
users log off the system. Once all users have left Wang Office, when
they re-execute the program, the security privileges will be correctly
acknowledged by the operating system. A damaged directory can also
result in problems which prevent users from accessing Wang OFFICE. (See
par. 13.08c.)

13.08 NETWORK RECOVERY COMPONENTS AND PROCEDURES

a\. Transports DLP (Data Link Processor) Crash. A transport crash is
referenced as a DLP crash by the Wang Communications Network Software.
In the event of a DLP crash on a TCB3 or CIU device that has not been
recovered by the system, the Node Administrator should:

\(1\) Inhibit all communications on that particular LINK/TRANSPORT. This
may include all (non-adjacent) systems that might use that transport.

\(2\) Place on hold all file transfer or retrieve requests.

\(3\) Run the CNSMGR program and select TRANSPORTS and disable the
transport, then wait for the disable message.

\(4\) Check the DLP from the Control Communications Devices Screen and
make sure that there are no DLP VS device numbers RESERVED AND IN USE.
If this is the case then some task (CNS, RATTSK, LWNMON) may have a VS
device number in use and that task will have to be canceled. The lowest
VS device number should be RESERVED for WSN.

\(5\) Verify that none of the background tasks have any of the DLP VS
device numbers in use by looking in the Non-Interactive Task Queue.

\(6\) Press the Clear Button on the TCB, or power off and on the CIU and
wait for their diagnostics to complete.

\(7\) Run CNSMGR and re-enable the transport and wait for the ENABLED
MESSAGE.

\(8\) Start any jobs you might have terminated.

\(9\) Allow Communications.

\(10\) Release any files in the transmit or retrieve queues.

b\. System Failure. If the system malfunctions, and an IPL is performed
with the communications file (@CNSCOM@), there is a possibility the
FTMTSK will malfunction following IPL. To alleviate this problem, it is
recommended that after a system failure, perform an IPL without
communications-perform the Directory recovery and the Wang Office
recovery procedures defined in the following sections. After these
recovery procedures have been completed, perform an IPL again with the
communications file.

c\. Directory Recovery. WSNREORG should always be run after a SYSTEM
failure. (ch. 10 of this manual provides an explanation of the functions
completed by the WSNREORG procedure.) If WSNREORG fails or completes
with a Return Code other than zero, the VBA Network Coordinator should
be contacted immediately for recovery assistance and instructions. Under
no circumstances should the Node Administrator proceed to recover a
damaged directory file without reporting the problem to the VBA Network
Coordinator.

13-10

March 12,1990 M204, Part II

Change 1

d\. Wang OFFICE Recovery. Following a SYSTEM failure, the Node
Administrator should complete the OFFICE recovery procedures outlined in
paragraph 10.25.

13.09 DISASTER RECOVERY

If a disaster occurs that requires the Node Administrator to restore
Wang OFFICE files from backup, the Network Coordinator should be
immediately contacted for assistance. If the correct procedures are not
followed for a disaster recovery, problems may be created and compounded
throughout the OASIS Network.

13.10 SOFTWARE INSTALLATION

All software installations (including Operating System upgrades) must be
coordinated through the VBA Network Coordinator to ensure that VBA
Network Coordinator to ensure that VBA standards are strictly followed
during all installations. Reinstallations of Wang OFFICE or WSN software
(located in the libraries @ SYSCOM @ and @ SYSDIR@) should not be
performed by Wang or VBA personnel without first consulting with the VBA
Network Coordinator. If the Directory file (@DIRECT@) is not correctly
backed up and recreated during an installation or reinstallation of
software, the functioning of the VBA network could be adversely
impacted.

13.11 NODE ADMINISTRATOR REPORTING REQUIREMENTS

a\. Wang. After the service call has been placed to Wang, notify the
Network Coordinator immediately and provide the following information:

\(1\) Tracking Number of the Service Call.

\(2\) Date and Time of the Service Call.

\(3\) Expected Resolution. The Network Coordinator will require a
timeframe for resolution so the Network Administrator can plan for the
expected downtime.

\(4\) Local Wangnet ID(s), e.g., 348DVBO1.

b\. VADATS. After the service call has been placed to Romney, West
Virginia, notify the Network Coordinator immediately and provide the
following information:

\(1\) Date and Time of the Service Call.

\(2\) Expected Resolution. The Network Coordinator will require a
timeframe for resolution so the Network Administrator can plan for the
expected downtime.

\(3\) Local Wangnet ID(s), e.g., 348DVB01.

\(4\) Name of point of contact at Romney, West Virginia.

c\. Reporting Problem Resolutions. Once a Wang and/or VADATS problem has
been resolved it should be reported to the VBA Network Coordinator.

13-11