cc/td/doc/product/rtrmgmt/bluelist/cwblue31
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Troubleshooting CiscoWorks Blue Applications
Calling Cisco TAC
General Troubleshooting
Troubleshooting the DLSw and RSRB Applications on UNIX workstations
DLSw and RSRB Error Messages on UNIX Workstations
Troubleshooting the SNA Host Component
SNA Host Workstation Messages
Troubleshooting the APPN/SNASw Application
APPN/SNASw Error Messages
Troubleshooting the Web Browser
Troubleshooting the HTML Online Help

Troubleshooting CiscoWorks Blue Applications


This chapter provides information on detecting and correcting problems with a CiscoWorks Blue application on UNIX workstations.

This chapter includes the following main sections:

Calling Cisco TAC

When you have isolated an error to one of the CiscoWorks Blue applications, typically you notify the Cisco TAC of the problem. Before you call the Cisco TAC, use the cwb tac command to collect the appropriate diagnostic data and zip it for transmission to Cisco.

UNIX Workstations

To collect and zip the diagnostic data, enter the following commands:

cd /opt/CSCOcb/bin
./cwb tac

The cwb tac command copies information from key files and from the CiscoWorks Blue database, and packages it in the following file: /usr/tmp/cwbtac_hostname_index.tar.Z

Where:

hostname is the actual hostname. If you set the environment variable CWB_TAC_CLIENT_ID to some value, then the hostname should be the value of this variable.

index is the next available counting number, starting with 1, for the first execution of cwb tac. The index value for the second execution of cwb tac is 2, and so on. This number is generated by looking at the existing file names; therefore, if you delete a file or change the hostname value, the counting restarts at 1. For example:

/usr/tmp/cwbtac_tblm_1.tar.Z

Submit this file, along with any other pertinent information, when you open a case with the Cisco TAC.

Specifying a Directory with the cwb tac Command

The cwb tac command lets you specify a directory for saving the command output.

The cwb tac command runs the CiscoWorks Blue TAC collection program to collect and zip all the information you will need when you call the Cisco TAC. You must be the root user to use the cwb tac command.

Command cwb tac [-o outputdirectory]

Syntax Description

-o outputdirectory

 

Specifies a directory in which the command output is saved.

If you omit this operand, the output is saved as file cwbtac_n.tar.Z in a temporary directory, where the n is increased for each successive use. The cwb tac command searches for a temporary directory in this order: /usr/tmp, /var/tmp, /tmp. You can specify an output directory in which to save the output of the cwb tac command:

  • You can specify an absolute directory by preceding the path with a / character. If the specified directory does not exist, the cwb tac command prompts you to create it. The following command saves the zipped file as /usr/cwblue/cwbtac_1.tar.Z:
cwb tac -o /usr/cwblue
  • You can specify a relative directory. This directory is always relative to /opt/CSCOcb/etc. The following command saves the zipped file as /opt/CSCOcb/etc/tac/cwbtac_1.tar.Z:
cwb tac -o tac

General Troubleshooting

If the application fails to operate correctly, perform the generalized diagnostic tasks as the root user. The diagnostic tasks are described in the following section.

An Exception Occurs when Collecting Data for TAC

If you are collecting data for TAC and osfind displays the following exception error message, you can ignore the message:

CORBA Exception during execution of osfind: EXCEPTION
ObjLocation::Fail
{
reason:
4
}

Customer ISTEXCCS Exit Driven With Unrequested Vector Types

VTAM provides customers with the ability to define additional information about dynamic PUs by using the ISTEXCCS configuration exit. This exit can select which type of information it will receive from VTAM and can elect to receive information on dynamic or static resources. The exit manager provided with the CiscoWorks Blue products may incorrectly drive customer exits with information the exit did not request from VTAM.

For example: A customer exit registers to receive only information on dynamic resources may receive information on static resources once the CiscoWorks Blue products have been installed on the system.

Work around

Customer can modify their exit to ignore unrequested types of resources.

Directory Name is Invalid but the Installer Still Creates It

During installation, you are prompted to select an installation directory. If you do not accept the default directory and choose to create a new directory, use valid naming conventions, such as 8-character names without any spaces. An error can occur in which the installer indicates the directory name is invalid but it still creates the directory.

DLC Information is Missing for Certain Physical Units

Informational messages, NSP040 and NSP041, can appear indicating that physical units (PU) are missing or are displayed incorrectly. These messages are provided by the NSPOPEN application and appear in the mainframe system log. SNA View determines the underlying resources used to connect these PUs to the mainframe.

NSP040 Resource RESOURCE not found in database:VSAM RC=RC errno=ERRNO
NSP041 Unable to obtain DLS information for RESOURCE

For more information on these messages, see Chapter 6 in CiscoWorks Blue Maps and SNA View Mainframe Installation Guide.

Dynamic Logical Units are Missing

In certain cases, CiscoWorks Blue SNA View is unable to collect status changes dynamically on certain types of logical units (LU). Status information on dynamically-defined LUs is collected only when a host discovery is requested or a VTAM message has indicated a state change has occurred on the PU.

Work around

To maintain information on dynamic LUs, you can recycle the host connection by using the stop cwbhcid and start cwbhcid commands. Or you can set up the host connection to periodically activate (v net,act,id=puname) PUs that support dynamic LUs.

Dynamic Physical Unit Construction Rejected After Installing CiscoWorks Blue ISTEXCCS

Customers can create PUs dynamically without using the ISTEXCCS exit to define additional information on these types of PUs. In this case, the CiscoWorks Blue exit may incorrectly act as the primary exit and reject the creation of the PU.

Work around

None. Contact TAC to install the latest version of CiscoWorks Blue exits that support this configuration.

Logical Unit Status is Incorrect

The status of an LU is incorrect in a Session Connectivity page. The CiscoWorks Blue SNA Resource Information page produces session lists that contain the status of LUs at the time the request was issued. If the status of the affected LU changes while either the Session List or Session Connectivity page are displayed, the changed status of the LU is not updated and displayed.

Work around

You can click the Reload button from the Session List or the Session Connectivity page to update the LU status or you can re-issue the entire request from the SNA Resource Information page.

Messages NSP040 and NSP041 Issued to the System Log

In some cases, CiscoWorks Blue SNA View may provide incorrect information on switch PUs. This problem appears as PUs displayed with incorrect or incomplete session path information. In addition, the NSPOPEN mainframe application will generate messages NSP040 and NSP04 to the system log for these resources. These messages are generated when the CiscoWorks Blue ISTEXCCS exit fails to collect the necessary information on the switched resources.

This exit failure can occur when a customer exit is present and is being used to define additional information on dynamic PUs. If the customer exit provides a vector to define in which major node to create the new PU, the CiscoWorks Blue exit may reject the processing for this PU.

Work Around

None. Contact TAC to install the latest version of CiscoWorks Blue exits that support this configuration.

Router Discovery Fails in SNA View because HPOV (Version 6) Changes the SNMP Port to 8161

An early release of HPOV, version 6, might set the SNMP port to 8161 in the services file. This port number change causes other SNMP-based applications, such as CiscoWorks Blue Maps and SNA View to fail.

You can use the following workarounds:


Step 1   Edit the /etc/services file.

Step 2   Change the SNMP port from 8161 to 161. Or apply the latest HPOV consolidated patch.



TCP Failure on the Mainframe Requires you to Restart NSPOPEN

In some cases, TCP/IP failure on the mainframe requires that you restart the NSPOPEN application. This problem can occur only for those using TCP/IP. If you are using LU 6.2, you can ignore this problem.

Work around

You can automate NetView to detect a failure in TCP/IP and issue the command to stop NSPOPEN. You can automate NetView to detect when TCP/IP is restarted and issue the command to start NSPOPEN.

Unable to Launch the Administration Application to Collect Information for TAC

If you want to use the Tools menu in the Administration application to collect diagnostic data for TAC, but are unable to launch the Administration application, use the following workaround:


Step 1   Open a command-line prompt.

Step 2   Change the directory to the installation directory by entering the following:

cd <name of install directory> \CSCOcb\bin

Step 3   Enter the following command:

cwb tac



Unable to Start Database Processes on UNIX Workstations

If you installed CiscoWorks 2000 and then CiscoWorks Blue in the same shell on UNIX systems, you can receive an error in which CiscoWorks Blue points to the CiscoWorks 2000 database. If this error occurs, the SQLAnywhere DB processes will not start and you will receive the following message:

px.log is not a database. 

To recover, exit the shell in which you installed the applications and run the cwb stop all command followed by the cwb start servers command. This action will point CiscoWorks Blue to the appropriate database and start the servers.

Unable to Start Process Manager on UNIX Workstations

If you are unable to start the Process Manager, if you get "out of space" errors trying to start other CiscoWorks Blue processes, or if you get java exceptions with the message "out of memory," you might need more physical memory, or to swap space in the workstation. Alternatively, especially on HP-UX because of low defaults, try increasing the kernel parameters beyond the minimal values required by Maps and SNA View.

Using the Process Manager Client on UNIX Workstations

Use the Process Manager client (cwb start ProcMgrClient) or launch from the Administration application to verify that all required processes are running.

Using the cwb show status Command on UNIX Workstations

Use the cwb show status command as a UNIX command line alternative to using the PM client. On UNIX workstations, use the cwb show status command in the /opt/CSCOcb/bin directory to verify that all the servers and processes are active:

cd /opt/CSCOcb/bin
./cwb show status

You can then use the cwb start command to start any servers or processes that are not running, and you can start the Process Manager client to monitor them, as described in "Monitoring and Controlling CiscoWorks Blue Applications."

Using the Message Log Viewer

Use the Message Log Client (cwb start MsgLogClient) or launch the Message Log Client from the Administration application to view messages as they are logged by CiscoWorks Blue processes.

UNIX Workstations

If you have not already started the Message Log client, you will have to view these messages in the message log files in /opt/CSCOcb/logs on UNIX workstations.

Using the cwb verify Command

UNIX Workstations

Use the cwb verify command in the /opt/CSCOcb/bin directory on UNIX workstations or launch the verification tool from the Administration application to verify that all the installation tasks were completed successfully.

Web Server Startup Errors on Solaris

While starting the web server, an error may occur in which CWBHTTPAdapter or CWBDBAdapter does not start. However, after automatic retries, the CWBHTTPAdapter or CWBDBAdapter process starts.

If the adapters start after some automatic retries, this errors indicate a temporary condition that has been automatically corrected.

Processes Do Not Start

The Process Manager is running, but when you issue the cwb show status command, the output shows all CWBlue processes in the Initial state whereas the CWBMsgLogServer is in the Starting state. The MsgLogServer gets the following message during startup:

Unable to bind to Process Manager Server 

This message is followed by a detailed CORBA System Exception information.

Work around

The problem appears to be a third-party package error. A workaround might be available by changing the localhost entry in the /etc/hosts file. Check the /etc/hosts file. The localhost entry should be the first uncommented entry in the /etc/hosts file as shown in the following examples:

# comment line in hosts file
127.0.0.1       localhost loghost

or

127.0.0.1       localhost

To make the localhost entry the first entry, change the /etc/hosts file as shown below:


Step 1   Become the root user:

su root

Step 2   Edit the /etc/hosts file.

Step 3   Either add this line as the first entry or move this line to the first entry.

127.0.0.1       localhost [loghost]

Note    If this entry exists in the file, there might be additional aliases on this line, before or after the localhost entry, such as the loghost alias. Keep the line intact when you move it to the first entry position.

Step 4   Stop all servers:

/opt/CSCOcb/bin/cwb stop all

Step 5   Start all servers:

/opt/CSCOcb/bin/cwb start servers



Troubleshooting the DLSw and RSRB Applications on UNIX workstations

This section describes some general DLSw and RSRB troubleshooting procedures for initial problem resolution for those using UNIX workstations, and then lists specific symptoms and possible remedies.

SNMP Request Errors

If there is an SNMP error while requesting information from the router, log on to the router and check for the following command in the current configuration:

snmp-server community read_community_string RO

The read_community_string should match the read community string used by Maps. You can check and edit this value by clicking a router icon with the right mouse button, and then selecting Edit > Modify.

The default SNMP server packet size is 1500. If the packet size is too low, then some commands might fail. If commands fail, you can raise the packet size to 8192.

You can use the Maps application menu bar to rediscover, add, or delete the router, as shown below.

SNMP Traps

If a trap occurs, but the status change is not reflected in the map, check the router configuration, as described in the "Configuring Trap Destinations in Cisco IOS Routers" section and use the Process Manager to see the status of the cwbtrapd process.

Diagnosing DLSw and RSRB Symptoms

For those using UNIX workstations, Figure 11-1 lists symptoms that your DLSw or RSRB application might demonstrates and refers you to various chapter sections for diagnostic techniques to resolve the problems.


Figure 11-1   DLSw and RSRB Troubleshooting Symptoms

For this symptom...  See this section... 

Device does not appear on the map

Device Not on Map.

Global view is empty

Blank Map.

Incorrect device information

Device Information Obsolete.

Nodes not synchronized

Nodes Not Synchronized.

Unexpected dialog box prompt appears

DLSw and RSRB Error Messages on UNIX Workstations.

Blank Map

If the RSRB or DLSw map is blank, synchronization with the network management system or seed file might have failed. Ensure that network devices were discovered by the network management system.

If a DLSw key routers view is blank, select Edit > Key Devices from the menu bar to ensure that you have designated routers as key devices in the seed file. If the key routers view is still blank, select View > Global to display a global view.

SunNet Manager maintains a separate device database for each user. In this case, you must use the RSRB or DLSw application from the username whose database you want to synchronize.

Also, you can try logging in to the Sybase server to check whether the devices in the seed file are also in the database. The following procedure describes how to check the database with the isql command.


Step 1   Issue the source command to set the database environment variables:

source /opt/CSCOcwbC/db/CSCOcwb/dbenv

If the source command produces errors, you must manually set the database environment variables as they are set in the /opt/CSCOcwbC/db/CSCOcwb/dbenv script.

Step 2   Then issue the isql command:

$SYBASE/bin/isql -Usnasuper -Psnarsrb
1> select * from snasuper.devices
2> go

You should see all devices that are in your seed file.



Device Not on Map

If a device fails to appear on the map, the discovery daemon might have failed. Perform the following steps:


Step 1   Use the isql command, as shown below, to verify the device's entry in the Sybase Devices table. This example is for a database named SNA.

$SYBASE/bin/isql -Usnasuper -Psnarsrb

1> select * from snasuper.devices where device_name=device_name
2> go
1> quit

Step 2   If the device named device_name is not in the Devices table, check for its existence in the network management system database or the seed file. If the device is in the Devices table, verify that it is running the correct release of Cisco IOS software and that you can ping the device from the network management system. Select Edit > Modify and enter the device name and correct read community string.

Step 3   Use Edit > Add Device to add the device to the map. The RSRB or DLSw application attempts to discover a newly added device automatically.

Step 4   Use the ping command to verify that you can locate the device.

Step 5   Check whether SNMP is configured on the router and verify the read community string. SNMP must be configured on the router for DLSw and RSRB.

Step 6   Check the access list in the router configuration to verify that the IP address can be reached.



Device Information Obsolete

If a device appears on the map but the information about it appears to be out of date, use the following procedure to delete the obsolete information:


Step 1   Select Edit > Rediscover Device(s) to rediscover the device.

Step 2   Use the Process Manager to reset the poller and monitor daemons.



If the problem remains unresolved, ensure that the poller is active. If a network management system is present, ensure that both the network management system trap daemon and the cwbtrapd process are active. For more information, see the "DLSw and RSRB Error Messages on UNIX Workstations" section.

Nodes Not Synchronized

If the nodes in your network are not synchronized with your database, try one of the following procedures.

Procedure 1

Step 1   Select all the devices on the map and rediscover them:

Step 2   Select Layout > See All.

Step 3   Select all the devices on the map.

Step 4   Select Edit > Rediscover Device(s).



Procedure 2

Use the following commands to remove all entries from the database tables:

cd /opt/CSCOCB/bin
./cwb clear db

For information about the cwb clear db command, see "CiscoWorks Blue Commands and Processes." Rerun the discovery processes to repopulate the database tables. In Maps, select Administration > Discover from the menu bar.

DLSw and RSRB Error Messages on UNIX Workstations

For those using UNIX workstations, the following error messages are issued to the message box in the RSRB and DLSw Motif applications and to the message log:

Cannot log into the database.

Current view_name view type conflicts with reserved name prefix of file.
Save map file filename Failed!

Where:

view_name is the name of the view that you are trying to save to a file:

filename is the name of the file in which you are trying to save the view.

Database initialization failure.

device_name already exists.

device_name no such device.
device_name failed to add.

Discovery failed.

Invalid view type

No community string

No response from update server.

Port already in use.

Reading map file filename. Incorrect format or version.
Open file Failed!

Rediscover Device(s) failed.


Step 1   Use the ping command to see whether the router is active.

Step 2   Use the telnet command to log in to the router to check the router configuration. Ensure that the router is configured for the protocol you are using and configured for SNMP, and that the read community string is correct.



Troubleshooting the SNA Host Component

This section contains the following information:

Overview of Workstation Error Handling

The LU and PU processes relay operating and error messages to the Message Log Server in which the management platform was started. You can view these messages, as they are logged, using the Message Log client.

All SNA host LU and PU errors are in the following form:

CWCxxxnnn message_text

Where:

xxx is a 2- or 3-letter message category.

nnn is a 3-digit numeric identifier.

For example:

CWC0006W Socket connect failed, will retry momentarily.

This chapter provides a detailed description of each message and, if appropriate, a recommended user response.

Workstation-to-Mainframe Connectivity Problems

This section describes problems related to communications between the mainframe and workstation components in TCP/IP and LU 6.2 environments.

TCP/IP Connectivity Problems

If the Host Connection Interface or the Host Command Server will not initialize successfully, perhaps due to communications problems between the workstation and mainframe. Perform the following procedures.

On the Workstation

Step 1   Verify that the SVMF_AGENT_ADDR configuration parameter (in the /opt/CSCOcb/etc/svopen_config_domain file) is set to the correct IP address or host name of the mainframe.

Step 2   Verify the network connection from the workstation to the mainframe by issuing a TCP/IP ping command.

Step 3   Verify that the SVMF_HCI_AGENT_PORT and the SVMF_CMDS_AGENT_PORT configuration parameters (in the /opt/CSCOcb/etc/svopen_config_domain file) are set correctly on the workstation. These configuration parameter values must match the parameter card values for the TCP subtask on the mainframe.



On the Mainframe

Step 1   For IBM TCP/IP connections, verify that the TCP subtask for your requested ports is active. Issue the F NSPOPEN,SHOW TASK command and look for the desired ports to confirm that the TCP subtask's state is READY. If the TCP subtask's state is not READY, use the INIT command to activate the TCP subtask.

Step 2   Verify that another workstation is not connected to the TCP subtask. Issue the F NSPOPEN,SHOW CONN command to confirm that there is no connection for the relevant TCP subtask. If another workstation is connected, choose a different pair of port numbers and reconfigure.



LU 6.2 Connectivity Problems

The best source of information for debugging LU 6.2 problems is the job log of the CiscoWorks Blue mainframe component. It will contain error messages written by the SERVER subtask.

For LU 6.2 connections, verify that the associated SERVER subtask is active. Issue the F NSPOPEN,SHOW TASK command to confirm that the SERVER subtask's states are UP. See the CiscoWorks Blue Maps and SNA View Mainframe Installation Guide for more details on problems and solutions with the SERVER subtask and LU 6.2 communications.

Problems with the SNA Communications Software

You can find helpful information for troubleshooting LU 6.2 connectivity problems in audit message logs, error message logs, and link traces.

Configuring Audit and Error Logging

The SNA communications software generates audit and error messages during operation and writes them to files specified during configuration. See the product documentation for more details on specifying log files and message severity levels.

Starting Tracing

When you start tracing, tracing information is written to the trace files (*.tr) in addition to the diagnostic messages written to the audit and error logs. See the product documentation for more details.

Problems Related to Discovery and Status Management


Note   You must have root user authority on the workstation to complete many of the tasks described here.

Problems relating to discovery and status management are described in the following sections:

Problems Discovering Your PUs and LUs

Discovery is a process that gathers the information on PUs and LUs for a specific domain and stores that information in the CiscoWorks Blue database. The following problems can occur:

Data-Gathering Errors

The cwbhmond process receives updated PU information from the mainframe when a status change occurs or when a new PU is discovered. If status updates are not being received at the workstation (that is, when the status of a PU changes but the change is not reflected when the PU information is displayed), messages might not be flowing from VTAM to the mainframe application. Ask your mainframe administrator to use the following commands:

This problem is described in the "Troubleshooting the Mainframe Application" chapter of the CiscoWorks Blue Maps and SNA View Mainframe Installation Guide.

Configuration File Problems

Configuration file errors are common sources of application failures. Each managed SNA domain has a configuration file in the /etc directory. Each domain configuration file name is in the format svopen_config_ domain. These configuration files contain parameters that affect almost every aspect of SNA host functionality. Several configuration file parameters, if not correctly set, can keep workstation processes from executing properly.


Note   Workstation processes retrieve parameters only once (during initialization). Therefore, after you make modifications to a configuration file, stop and restart the processes for the changes to take effect.

The following sections describe the configuration file parameters and the problems that can arise if they are not set correctly.

SVPATH

SVPATH is the path to the home directory on UNIX (/opt/CSCOcb/snahost).

If this variable is not properly set to the home directory, as defined during installation, workstation processes cannot locate necessary help, log, and parameter files. Most workstation processes will not initialize without a valid SVPATH parameter value.

SVMF_AGENT_ADDR

SVMF_AGENT_ADDR is the TCP/IP host name of the IBM mainframe running the mainframe application.

If this configuration parameter is not properly set, the Host Connection Interface and the Host Command Server will fail to initialize when TCP/IP is for communications between mainframe and workstation.

For example, if the value of this configuration parameter is mickey, but mickey is not a valid machine on the network, you will get the following error messages written to the Message Logger when you attempt to start the Host Connection Interface or Host Command Server:

CWC0037E client_bind_udp_socket() failed calling gethostbyname(), reason: Error 0.

CWC0043E Unable to obtain host TCP/IP address from host name: mickey
CWC0048I client_bind_udp_socket() process has exited.

However, if mickey is a valid machine name, but the TCP subtask of the mainframe component is not currently running, these error messages are written to the message log if the IPCTrace message category is enabled:

CWC0001E server_connect_tcp_socket() failed calling connect(), reason: Connection refused.

Similar error messages will be generated if the SVMF_HCI_AGENT_PORT and SVMF_CMDS_AGENT_PORT values are not set properly. These configuration parameters must match the ports defined on the mainframe program's TCP parameter card. See the CiscoWorks Blue Maps and SNA View Mainframe Installation Guide for more details.

SVCMD_TIMEOUT

SVCMD_TIMEOUT is the time out period, in seconds, for mainframe commands.

If this configuration parameter is set too low, then mainframe commands issued from the workstation can time out. Try to increase this parameter value.

The default value of this configuration parameter is 30 seconds. In most cases this value is sufficient. However, when the workstation-to-mainframe connection is very slow, you might need to increase this value. If this configuration parameter is set too low, the following error messages will be issued to standard error:

CWC0061W Timed out waiting for command response from Command Server.
CWC0064W Command not processed. Verify that the HCI and Command Servers are active.

If increasing this configuration parameter does not prevent commands from timing out, ensure that the Host Connection Interface and Host Command Server are active. If they are inactive, activate them. If they are active, check the mainframe performance group, which might be set too low. See your mainframe system administrator or see the CiscoWorks Blue Maps and SNA View Mainframe Installation Guide for assistance.

SVCMDS_AGENT_PORT

The server and client processes use this port for socket communications. Ensure the port is not used twice, and that it is not used by some other process.

SVHCI_STATUS_PORT

The Host Connection Interface communicates with the VTAM and MVS Servers, and the cwbhmond process, over these defined ports. Ensure the port is not used twice and that it is not used by some other process.

SVMF_HCI_AGENT_PORT, SVMF_CMDS_AGENT_PORT

These configuration parameters define the port values used for TCP/IP communications between the workstation and mainframe components. The Host Connection Interface and Host Command Server use these port values to establish socket communications with the TCP subtask on the mainframe. The port values specified in the configuration file on the workstation must match those defined on the TCP subtask parameter card in the mainframe component's SYSIN parameter card file. See the CiscoWorks Blue Maps and SNA View Mainframe Installation Guide for more information on the TCP subtask and SYSIN parameter card file.

If these configuration parameters do not match those defined on the mainframe, the workstation application will generate the following error messages on standard error when starting the Host Connection Interface and Host Command Server:

CWC0001E server_connect_tcp_socket() failed calling connect(), reason: Connection refused.

CWC0007E Socket connect failed, no retry will be attempted.
CWC0048I server_connect_tcp_socket() process has exited.

SNA Host Workstation Messages

This section explains the messages generated by the workstation program. Each message number ends with one of the following error codes:

CWC0001E process failed calling function, reason: explanation

Where:

process is the process or routine.

function is the system socket function.

explanation is the text that explains the error.

CWC0002E Unable to open protocol method socket.

Where:

protocol is the socket protocol.

method is either the stream or datagram method.

CWC0003E Unable to bind socket.

CWC0004E Unable to set socket to non-blocking mode.

CWC0005E Error on listen for socket connection.

CWC0006W Socket connect failed, will retry momentarily.

CWC0007E Socket connect failed, no retry will be attempted.

CWC0008E Unable to get socket option: socket.

Where:

socket is the specific socket option.

CWC0009E Unable to set socket option: socket.

Where:

socket is the specific socket option.

CWC0010E process failed reading HCI socket, reason: explanation.

Where:

process is the server process.

explanation is text that explains the error.

CWC0011E Failure reading process client UDP socket.

Where:

process is the client process name.

CWC0012E Failure reading process server UDP socket, entire message not received.

Where:

process is the server process.

CWC0013E Failure writing to process client UDP socket.

Where:

process is the client process.

CWC0014E Failure writing to process client UDP socket, entire message not sent.

Where:

process is the client process.

CWC0015E Failure reading SView/Open Mainframe Message Server, reason: explanation.

Where:

explanation is text that explains the error.

CWC0016E Lost connection with SView/Open Mainframe Message Server.

CWC0017E process has exited due to read failure on HCI connection.

Where:

process is the server process.

CWC0018E process has exited due to loss of connection with the HCI.

Where:

process is the server process.

CWC0019E HCI failed sending command response to the Command Server.

CWC0020E process failed calling name with errno: error_number

Where:

process is the process or routine.

name is the LU 6.2 system routine name.

error_number is the error return.

CWC0021E Failure opening direction LU 6.2 conversation.

Where:

direction is inbound or outbound.

CWC0022E Failure allocating direction LU 6.2 conversation.

Where:

direction is inbound or outbound.

CWC0023E Failure reading over direction LU 6.2 conversation.

Where:

direction is inbound or outbound.

CWC0024I Control received value from mainframe signals termination.

CWC0025E Failure confirming conversation LU 6.2 conversation read.

Where:

conversation is the inbound or outbound conversation.

CWC0026E Failure sending over conversation LU 6.2 conversation.

Where:

conversation is the inbound or outbound conversation.

CWC0027E Failure closing conversation LU 6.2 conversation.

Where:

conversation is the inbound or outbound conversation.

CWC0028I process initialized successfully for domain name.

Where:

process is the process.

name is the defined domain name.

CWC0029E process started with invalid argument count.

Where:

process is the process.

CWC0030E Domain name must be passed in to the process.

Where:

process is a process.

This message is displayed if the cwbhmond process is not given a domain name on the command line as its first command argument.

Verify that the following UNIX files were not incorrectly modified:

CWC0031E Invalid transaction program name executable used to start HCI.

CWC0032E process encountered invalid value for configuration parameter parameter_name

Where:

process is the process name.

parameter_name is the Maps SNA host configuration parameter.

CWC0033E process needs the variable environment variable set properly.

Where:

process is the process.

variable is the environment variable.

CWC0035E process failed calling function

Where:

process is the process or function.

function is the function.

CWC0036E process failed calling function with rc: rcnumber

Where:

process is the process or function.

function is the function.

rcnumber is the integer return code.

CWC0037E process failed calling function, reason: message

Where:

process is the process or function.

function is the function.

message is the text of the error message.

CWC0038I process for domain domain will terminate after waiting for other processes to end.

Where:

process is the process or function.

domain is the domain name.

CWC0039W An instance of process for domain domain is already running.

Where:

process is the process or function.

domain is the domain name.

CWC0040E process failed to open file path, reason: message

Where:

process is the process or function.

path is the full file path, including the file name.

message is the text of the error message.

CWC0041W Attempt to connect to process failed, retrying.

Where:

process is the process or function.

CWC0042E Memory allocation failure, check available memory.

CWC0043E Unable to obtain host TCP/IP address from host name: host.

Where:

host is the TCP/IP host name.

CWC0044W Waiting for previous instance of process for domain domain to end.

Where:

process is the name of the process.

domain is the name of the domain.

CWC0045E process for domain domain detected an unsupported mainframe version.

Where:

process is the name of the process.

domain is the name of the domain.

CWC0046E process for domain domain failed to receive a response for the version request.

Where:

process is the name of the process.

domain is the name of the domain.

CWC0047E process for domain domain lost mainframe connection; will try to re-establish. Code code.

Where:

process is the name of the process.

domain is the name of the domain.

code is the error code.

CWC0048I process process has exited.

Where:

process is the process that exited.

CWC0049I process process of domain name has exited.

Where:

process is the process that exited.

name is the domain name.

A process of a domain has terminated.

For example, if the cwbhmond process fails to initiate a session with the Sybase application program interface (API), this error message is logged.

CWC0050I process process of domain name has exited with code code.

Where:

process is the process that exited.

name is the defined domain name.

code is the error code.

CWC0051W Status and/or Discover task not active on mainframe.

CWC0052E Invalid buffer size for process message. Domain: domain

Where:

domain is the domain name.

message is the message.

CWC0053E Invalid buffer structure. Domain: domain

Where:

domain is the domain name.

CWC0054W Connection to command server daemon failed for domain.

Where:

domain is the domain name.

CWC0055W Connection to Status Monitor daemon failed for domain domain.

Where:

domain is the domain name.

Other messages might accompany this message. Attempt to resolve the problem based on these messages. Ensure that the product was properly installed and configured. If the error persists, use the cwb tac command and notify the Cisco TAC.

CWC0056E Invalid message type received by process1 from process2: type

Where:

process1 and process2 are processes.

type is the message type.

CWC0057W Client is not currently registered, filter request rejected.

CWC0058W Client is not currently registered, command not submitted to mainframe.

CWC0059W Maximum number of clients already registered, request rejected.

CWC0060W Timed out waiting for server registration response.

CWC0061W Timed out waiting for command response from Command Server.

CWC0062E process error message: message.

Where:

process is the server process that detected the error.

message is the text of the error message.

CWC0063E Verify that the HCI and Command Servers are active.

CWC0064W Command not processed. Verify that the HCI and Command Servers are active.

CWC0065W Sybase database login failure.

Troubleshooting the APPN/SNASw Application

This section describes some general APPN/SNASw troubleshooting procedures for initial problem resolution, and then lists specific symptoms and possible remedies.

General Troubleshooting

If the APPN/SNASw application fails to operate correctly, verify that the environment variables are set in the cwbinit script according to the values in "Installing and Configuring CiscoWorks Blue."

Go to another view, then return to this view. If the problem has not cleared up, exit the application, remove the Map files again, and restart the application.

Diagnosing APPN/SNASw Symptoms

Table 11-1 lists symptoms that your APPN/SNASw application might demonstrate and refers you to some diagnostic techniques to resolve the problems.

Table 11-1   APPN/SNASw Troubleshooting Symptoms

For this symptom...  See this section... 

Cannot find LU

LU Cannot Be Found

Global view is empty

Global Map Is Blank

Good connection displayed as degraded

Good Connection Appears Degraded

Incorrect status

Incorrect Status

Link station is not displayed

Link Station Does Not Appear

Network node status is unknown

Network Node Status Unknown

Global Map Is Blank

If the global map is blank, you might have one of the following problems:

To resolve this problem, perform one or more of the following:

Network Node Status Unknown

If the status of all network nodes is unknown to the application, the network topology agent could have failed, or APPN/SNASw could have been stopped in that device, or the SNMP request might have failed. Use the ping command or select Tools > PathTool from the menu bar to verify that the network topology agent is accessible. If necessary, use the telnet command to log in to the agent to start the APPN/SNASw protocol.

LU Cannot Be Found

If APPN/SNASw cannot find a known LU, use the following procedure:


Step 1   Select each node on the map, one at a time.

Step 2   At each node, click the right mouse button.

Step 3   Select Get Directory from the menu.

Step 4   Repeat Step 1 through Step 3 for the next node.



Link Station Does Not Appear

If a known link station does not appear in the List TGs and Links window, use the following procedure:


Step 1   Close the List TGs and Links window.

Step 2   Select the node on which the missing link is defined.

Step 3   Click the right mouse button.

Step 4   Select Get Local Topology from the menu.

Step 5   Reopen the List TGs and Links window to see if the link is listed. Or, set the autolocaltopo variable in the cwbinit file to ALL or NN_ONLY and restart the application.



Good Connection Appears Degraded

If a known good connection appears degraded (yellow), a defunct TG number might exist in the network topology agent's database. According to an APPN/SNASw algorithm, the network topology agent will delete the defunct number within a few days. When you start the APPN/SNASw application after that deletion occurs, the connection does not appear degraded.

Incorrect Status

If the status of a port, link, or transmission group is reported incorrectly, refresh the information by using the following procedure:


Step 1   On the map, select the owning node.

Step 2   Click the right mouse button.

Step 3   Select Get Local Topology from the menu.



APPN/SNASw Error Messages

The following error messages are unique to the APPN/SNASw application. They are displayed in the APPN/SNASw Motif message box and written to the message log.

Current view_name  view type conflicts with reserved name prefix of file.
Save map file filename Failed!

Where:

view_name  is the name of the view that you are trying to save to a file.

filename is the name of the file in which you are trying to save the view.

Database initialization failure

Device name & read community required

Invalid view type

No devices discovered

Reading map file filename. Incorrect format or version.
Open file Failed!

Where:

filename is the name of a map file.

View could not be retrieved

View may be incomplete

Will retry by polling


Step 1   Select Administration > Discovery to discover a new network topology agent.

Step 2   Ensure that the selected network topology agent is an APPN/SNASw network node with the APPN/SNASw MIB, and that the IP address or device name you specified is correct. If not, stop the APPN/SNASw application and restart it with a new network topology agent.

Step 3   Ensure that the APPN/SNASw protocol is active on the target agent.

Step 4   Use the ping command to see if the agent is alive and accessible.



Troubleshooting the Web Browser

This section presents troubleshooting techniques for the web browser.

Web Browser Fails

If your web browser cannot access the web server, try one of the following:

At the Web Server

If the web browser cannot access the web server, look at the web server's log files. The CiscoWorks Blue web server log files are /opt/CSCOcwbC/apache/var/log/access_log and /opt/CSCOcwbC/apache/var/log/error_log on UNIX. The access_log file lists all accesses to the web server. The error_log file lists individual errors in accessing the web server.

At the Web Browser

If selecting Tools > Web Browser from a Motif application fails, look at the /opt/CSCOcb/etc/runweb file and ensure that the environment variables are set correctly for your directory structure. Verify that Netscape is installed. If you installed Netscape after you installed CiscoWorks Blue, Netscape must be in the PATH.

Also, you can try turning off proxy server use at the web browser. Check with your system administrator before you do this. To turn off proxy use for the Netscape browser, for example, select Options > Network Preferences. Select the Proxies tab, and click No Proxies. Click OK and try to access the web server again.

Cannot Access CiscoWorks Blue Web Pages

If you cannot access the CiscoWorks Blue web pages, use the Process Manager to ensure that the CWBHTTPDAdapter is running.

Unexpected Web Page Displayed

If you accessed the CiscoWorks Blue web server but saw some other page, this means another web server is already using port 80. For example, when you installed CiscoWorks Blue Maps, no other web server was running, so the CiscoWorks Blue web server was configured for port 80. But later, when you started the CiscoWorks Blue web server or tried to display the CiscoWorks Blue web page, some other web server was already using port 80. If you need to use a different port, you must reinstall the CiscoWorks Blue products.

Change the URL at the Browser

To specify port 8080 in the web browser, enter the following URL in the browser:

http:// workstation_name:8080

Where:

workstation_name is the name of the workstation where the Maps web server is installed.

Troubleshooting the HTML Online Help

If the online help for the web browser, the Administration program, the Process Manager, or the Message Logger does not launch successfully, edit the following files to ensure that the path to the Netscape executable is correct:

The installation program asks you for this path. If you enter the wrong path, the online HTML help might not work.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Thu Jul 31 16:06:26 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.