|
|
Troubleshooting SNA View on the Workstation
This chapter contains the following sections:
SNA View processes relay operating and error messages to several locations.
All SNA View errors are of the form SV
XXXnnn
message,
where,
XXX
is a 2- or 3-letter message category, and
nnn
is a 3-digit numeric identifier, such as:
SVSOK050 Socket connect failed, will retry momentarily .
This message is from the Socket Communications Messages (SOK) component and has a message identifier of 050. This information can be used to locate the message in this chapter. This chapter provides a detailed description of each message and, if appropriate, a recommended user response.
SNA View contains a debug facility that can be enabled to generate data about SNA View processes. SNA View is shipped with a default debug parameter file in which debug mode is turned OFF for all SNA View processes. There may be times when this debug information is necessary, such as when providing Cisco TAC personnel with problem reports of SNA View errors. It is possible to generate detailed debug data for any reproducible problem.
The SNA View debug parameter file resides in the $SVHOME/parm directory under the filename svdebug.parm. Each line in this file contains a process identifier and a hexadecimal number representing a debug level set for that process. A debug level of 0 indicates no debug data is generated.
Table 6-1 describes the value and description of each debug setting.
Table 6-1 Available Debug Settings
| Debug Value | Description |
|---|---|
| 0 | No debug data is produced. |
| 1 | Function tracing statements are produced. |
| 1f | Function tracing statements and function details are produced. |
| ffff | Function traces, details, and hexadecimal dumps of all interprocess message flows are produced. |
To activate debugging for a particular SNA View process, locate the process identifier in the svdebug.parm file and set the debug level accordingly.
Table 6-2 lists the process identifiers found in the svdebug.parm file and the SNA View processes affected by each:
Table 6-2 Debug Process Identifiers
| Process ID | Affected SNA View Processes |
|---|---|
| SVHCI | Host Connection Interface |
| SVALERTP | Alert Server, Alarm Manager, and X Alert Client |
| SVVTAMP | VTAM Server, VTAM Message Log, and X VTAM Client |
| SVMVS | MVS Server, MVS Message Log, and X MVS Client |
| SVCMDP | Command Server, X Command Client |
| SVSTATUS | Status Manager |
| SVMENU | Task Manager |
| SVLOGON | N/A |
| SVDISCOVER | Map Builder/Discovery process |
| SVHOSTCMD | Command line command client |
This section highlights problems that are not particular to any single component of SNA View. This section discusses the following problems:
The SVHOME environment variable must be set before SNA View will function properly. This variable must be set to the SNA View's home directory; for example, /usr/cw-blue/snaview. It is used by many SNA View processes to find the correct path to the SNA View parm, help, and log directories.
For example, if the SVHOME environment variable is not set and you attempt to launch the Alert Server, the following error message will be returned:
SVINI030 Alert Server needs the SVHOME environment variable set properly.
If the environment variable is set, but set incorrectly (to /var/sv, for example), you would receive a message similar to the following:
SVEXE010 CP_Table_Init() failed to open file /var/sv/parm/svcodepts/svcpt01.txt Reason: No such file or directory.
In this example, the Alert Server is unable to locate the necessary code point tables in the directory /var/sv/parm because they do not exist. In general, if SNA View is unable to locate specific files that it requires, the SVHOME environment variable should be checked first.
SNA View configuration file errors are common sources of SNA View failures. While not all possible configuration errors can be covered, those that are encountered most frequently are described in this section.
Each managed SNA View domain has a configuration file prefixed by sv_config_ which resides in the /etc directory. These configuration files contain parameters which affect almost every aspect of SNA View functionality. Several configuration file parameters, if not set correctly, can keep SNA View processes from executing properly.
The following sections describe each of these parameters, and the problems that can arise if they are not set correctly.
SNA View home directory (such as /usr/sv).
If this parameter is not properly set to SNA View's home directory, as defined during installation, workstation processes will not be able to locate necessary help, log, and parameter files. Most SNA View workstation processes will not initialize without a valid SVPATH parameter value.
For example, if the SVPATH parameter is not changed from its default value of none and the Status Manager is started, the following error messages will be written to stderr:
SVEXE010 Set_Debug_Flag2() failed to open file none/parm/svdebug.parm, reason: No such file or directory. SVINI040 Error setting debug value, unable to find module SVSTATUS in Status Manager. SVEXE102 Status Manager process of domain [DOMAIN1] has exited.
Machine name of workstation running the VTAM Server.
If this parameter is not properly set to the machine name of the workstation where the VTAM Server will be running, the VTAM Message Log and X VTAM Window clients will not be able to register to receive unsolicited VTAM messages.
Two symptoms indicate the SVVTAM_AGENT_ADDR parameter is not set correctly.
For example, if the value of this parameter is mickey, but mickey is not a valid machine in the network, the following error messages will be written to stderr:
SVEXE002 client_bind_udp_socket() failed calling gethostbyname(), reason: Error 0. SVEXE031 Unable to obtain host TCP/IP address from host name: mickey SVEXE100 client_bind_udp_socket() process has exited.
If, however, mickey is a valid machine name but the VTAM Server is not currently running on that machine, the following error message will be generated either on stderr if running the VTAM Message Log, or in a Motif pop-up if starting the X VTAM Window:
SVSRV050 Timed out waiting for server registration response.
Machine name of workstation running the MVS Server.
If this parameter is not properly set to the machine name of the workstation where the MVS Server will be running, the MVS Message Log and X MVS Window clients will not be able to register to receive unsolicited MVS messages.
Two symptoms indicate the SVMVS_AGENT_ADDR parameter is not set correctly.
For example, if the value of this parameter is mickey, but mickey is not a valid machine in the network, the following error messages will be written to stderr:
SVEXE002 client_bind_udp_socket() failed calling gethostbyname(), reason: Error 0. SVEXE031 Unable to obtain host TCP/IP address from host name: mickey SVEXE100 client_bind_udp_socket() process has exited.
If, however, mickey is a valid machine name but the MVS Server is not currently running on that machine, the following error message will be generated either on stderr if running the MVS Message Log, or in a Motif pop-up if starting the X MVS Window:
SVSRV050 Timed out waiting for server registration response.
Machine name of workstation running the Alert Server.
If this parameter is not properly set to the machine name of the workstation where the Alert Server will be running, the X Alert Window clients will not be able to register to receive unsolicited Alert messages.
Two symptoms indicate the SVALERT_AGENT_ADDR parameter is not set correctly.
For example, if the value of this parameter is mickey, but mickey is not a valid machine in the network, the following error messages will be written to stderr:
SVEXE002 client_bind_udp_socket() failed calling gethostbyname(), reason: Error 0. SVEXE031 Unable to obtain host TCP/IP address from host name: mickey SVEXE100 client_bind_udp_socket() process has exited.
If, however, mickey is a valid machine name but the Alert Server is not currently running on that machine, the following error message will be generated:
SVSRV050 Timed out waiting for server registration response.
Machine name of workstation running the Command Server.
If this parameter is not properly set to the machine name of the workstation where the Command Server will be running, the X Command Window client and Host Command client processes will not be able to register to receive mainframe command support. Host Command Client processes are generated by SNA View pull-down-generated mainframe commands and by other SNA View processes (such as the Discovery and Status Manager processes).
Two symptoms indicate the SVCMDS_AGENT_ADDR parameter is not set correctly.
For example, if the value of this parameter is mickey, but mickey is not a valid machine in the network, the following error messages will be written to stderr:
SVEXE002 client_bind_udp_socket() failed calling gethostbyname(), reason: Error 0. SVEXE031 Unable to obtain host TCP/IP address from host name: mickey SVEXE100 client_bind_udp_socket() process has exited.
If, however, mickey is a valid machine name but the Command Server is not currently running on that machine, the following error message will be generated either on stderr if running the Host Command client, or in a Motif pop-up window if starting an X Command Window client:
SVSRV050 Timed out waiting for server registration response.
Machine name of workstation running the HCI.
If this parameter is not properly set to the machine name of the workstation where the Host Connection Interface is running, the Command, VTAM, MVS, and Alert Servers as well as the Status Manager will be unable to establish socket communications with the Host Connection Interface.
Two symptoms indicate the SVHCI_AGENT_ADDR parameter is not set correctly.
For example, if the value of this parameter is mickey, but mickey is not a valid machine on the network, the following error messages will be written to stderr when you attempt to start any of the processes named above:
SVEXE002 client_bind_udp_socket() failed calling gethostbyname(), reason: Error 0. SVEXE031 Unable to obtain host TCP/IP address from host name: mickey SVEXE100 client_bind_udp_socket() process has exited.
If, however, mickey is a valid machine name but the HCI is not currently running on that machine, the following error messages are written to stderr:
SVSOK001 server_connect_tcp_socket() failed calling connect(), reason: Connection refused SVSOK051 Socket connect failed, no retry will be attempted. SVEXE100 server_connect_tcp_socket() process has exited.
Machine name of the IBM mainframe running SNA View.
If this parameter is not properly set to the machine name of the IBM mainframe running SNA View, then the Host Connection Interface and the Command Server will not initialize successfully (when using TCP/IP for communications between the mainframe and the workstation).
Two symptoms indicate the SVMF_AGENT_ADDR parameter is not set correctly.
For example, if the value of this parameter is mickey, but mickey is not a valid machine on the network, you will get the following error messages written to stderr when you attempt to start the HCI or Command Server:
SVEXE002 client_bind_udp_socket() failed calling gethostbyname(), reason: Error 0. SVEXE031 Unable to obtain host TCP/IP address from host name: mickey SVEXE100 client_bind_udp_socket() process has exited.
If, however, mickey is a valid machine name but the TCP subtask of the mainframe component is not currently running, you will receive the following error messages on stderr:
SVSOK001 server_connect_tcp_socket() failed calling connect(), reason: Connection refused SVSOK051 Socket connect failed, no retry will be attempted. SVEXE100 server_connect_tcp_socket() process has exited.
Similar error messages will also be generated if the SVMF_HCI_AGENT_PORT and SVMF_CMDS_AGENT_PORT values are not set properly. These configuration parameters must match the mainframe component TCP subtask's input parameter card. Please refer to the CiscoWorks Blue SNA View Mainframe Installation Guide for more details.
Timeout period, in seconds, for mainframe commands.
If this parameter is set too low, then mainframe commands issued from the workstation can timeout. This can affect other SNA View processes that must issue mainframe commands to obtain configuration and status information about SNA resources, such as the Discovery and Status Manager processes. This can also affect user-generated commands that are issued via the SNA View pull-down menus.
The default value of this parameter is 30 seconds. In most cases this value is sufficient. However, in extremely large SNA environments or when the workstation to mainframe connection is very slow, this value may need to be increased. If this parameter is set too low, the following error messages will be issued to stderr by the Status Manager, Discovery process, and SNA View menu-generated commands:
SVSRV055 Timed out waiting for command response from Command Server. SVSRV070 Verify that the HCI and Command Servers are active.
In the case of menu-generated commands, you will also receive the following error messages in the Command Response Display window where the result of the command is normally written:
SVSRV055 Timed out waiting for command response from Command Server. SVSRV071 Command not processed. Verify that the HCI and Command Servers are active.
After increasing the value of this parameter, the Status Manager or Discovery processes must be recycled. Please note that the Command Server does not need to be recycled.
If increasing this parameter does not prevent commands from timing out, it may be due to SNA View's performance group of the mainframe task not being set to a high enough priority. See your mainframe system administrator or refer to the CiscoWorks Blue SNA View Mainframe Installation Guide for assistance.
Valid NetView operator ID.
If this parameter is not set to a valid NetView operator ID, NetView commands issued from the X Command Client window will fail.
SVWORK_AREA
Valid system directory where SNA View will store work files.
If this parameter is not set to a valid system directory, various SNA View processes will be unable to initialize successfully or run properly. SNA View processes utilize this temporary directory to store various files necessary during normal operation. These files and the processes that create them are described in greater detail in "Authority and Access Problems (Permissions)."
The SNA View server and client processes utilize these port values for socket communications. In a distributed environment (or when running SNA View workstation processes on more than one machine), it is important to match the port values between the machine running the SNA View server and the machine running the corresponding client or clients. Each of the SNA View servers (VTAM, MVS, Alert and Command) have a corresponding port value specified by the above parameters. If these parameters do not match on both workstations, the SNA View client in question will receive the following error message on stderr (or in a Motif pop-up window in the case of an X-window client):
SVSRV050 Timed out waiting for server registration response.
The Host Connection Interface communicates with the VTAM, MVS and Alert Servers as well as the Status Manager over these defined ports. In a distributed environment (or when running SNA View workstation processes on more than one machine) it is important to match the port values between the machine running the Host Connection Interface and the machine running the corresponding server process. If these parameters do not match on both workstations, the SNA View server in question will receive the following error messages on stderr during initialization:
SVSOK001 server_connect_tcp_socket() failed calling connect(), reason: Connection refused. SVSOK051 Socket connect failed, no retry will be attempted. SVEXE100 server_connect_tcp_socket() process has exited.
These configuration parameters define the port values used for TCP/IP communications between the workstation and mainframe components of SNA View. The HCI and Command Servers 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 statement in the mainframe component's SYSIN parameter card file. Please refer to the CiscoWorks Blue SNA View Mainframe Installation Guide for more information on the TCP subtask and SYSIN parameter card file.
If these parameters do not match those defined on the mainframe, SNA View will generate the following error messages on stderr when starting the HCI and Command Server tasks:
SVSOK001 server_connect_tcp_socket() failed calling connect(), reason: Connection refused. SVSOK051 Socket connect failed, no retry will be attempted. SVEXE100 server_connect_tcp_socket() process has exited.
File permission problems sometimes arise during the operation of SNA View. One such problem occurs when SNA View is initially run under the superuser shell authority. SNA View processes open files with write permission for various reasons. Log files and temporary work files are two of the most common. An example is the Status Manager, which opens a file in SNA View's temporary work directory, specified by the configuration file parameter WORK_AREA (the default value of WORK_AREA is /tmp). The Status Manager uses this file to store its own process identifier and to determine whether there is already a Status Manager running for a specific domain.
If the Status Manager is originally run under the Root user ID, and later run under a particular user's ID, the following error messages are generated by SNA View:
SVSM020 Cannot store the Status Manager's Process ID: exiting. SVEXE102 Status Manager process of domain [domain name] has exited.
In this example, the Status Manager process was unable to obtain write authority for the necessary file, so the process exited. Changing the file permissions or ownership of the SV_s_m_pid.[domain] file in /tmp would correct the problem (where DOMAIN is equal to the appropriate SNA View domain name).
Files placed in WORK_AREA by SNA View are prefixed by SV*. The Status Manager, Discovery, Domain Layout and Refresh processes all place files in the directory specified by the WORK_AREA configuration parameter.
Table 6-3 lists the files created by each process.
Table 6-3 Work Files Created by SNA View Processes
| Process | Files Created |
|---|---|
| Status Manager | SV_s_m_grep SV_s_m_pid SV_act_stat |
| Discovery and Refresh | SV_clstrs SV_terms |
As mentioned previously, many SNA View processes also open log files in the $SVHOME/log directory.
Table 6-4 lists those processes and the names of the log files they open.
Table 6-4 Log Files Utilized by SNA View Processes
| Process | Associated Log File |
|---|---|
| Status Manager | svstatman.log |
| VTAM Server | svvtam.log |
| MVS Server | svmvs.log |
| VTAM Message Log | svmessage_log |
| MVS Message Log | svmvs_message_log |
In order for an SNA View process to function as expected, all of the parameters it references must be available and set correctly.
Table 6-5 lists the parameter files referenced by each of the SNA View processes.
Table 6-5 Parameter Files Referenced by SNA View Processes
| Process | Parameter Files Referenced |
|---|---|
| Host Connection Interface | svdebug.parm |
| Command Server | svdebug.parm |
| VTAM Server | svdebug.parm svvtamsysfilter.tbl |
| MVS Server | svdebug.parm svmvssysfilter.tbl |
| Alert Server | svdebug.parm svcodepts/svcpt01.txt svcodepts/svcpt10.txt svcodepts/svcpt81.txt svcodepts/svcpt82.txt svcodepts/svcpt92.txt svcodepts/svcpt93.txt svcodepts/svcpt94.txt svcodepts/svcpt95.txt svcodepts/svcpt96.txt |
| Status Manager | svdebug.parm |
| SNA View Discovery Process | svdebug.parm |
| Refresh Maps Process | svdebug.parm |
| Check Status Process | svdebug.parm |
| VTAM Message Log | svdebug.parm |
| MVS Message Log | svdebug.parm |
| Mainframe Commands Window | svdebug.parm |
| VTAM Messages Window | svdebug.parm |
| MVS Messages Window | svdebug.parm |
| Alert Window | svdebug.parm svcodepts/svcpt01.txt svcodepts/svcpt10.txt svcodepts/svcpt81.txt svcodepts/svcpt82.txt svcodepts/svcpt92.txt svcodepts/svcpt93.txt svcodepts/svcpt94.txt svcodepts/svcpt95.txt svcodepts/svcpt96.txt |
| Alert Summary Window | svdebug.parm svcodepts/svcpt01.txt svcodepts/svcpt10.txt svcodepts/svcpt81.txt svcodepts/svcpt82.txt svcodepts/svcpt92.txt svcodepts/svcpt93.txt svcodepts/svcpt94.txt svcodepts/svcpt95.txt svcodepts/svcpt96.txt |
| Command Client Process | svdebug.parm |
This section describes problems that can arise during typical operation of SNA View. The scenarios covered in this chapter are categorized according to the SNA View component or task that can experience a failure. Problems are sorted into the following categories:
SNA View's Task Manager process allows the user to control SNA View processes for all managed SNA domains. Occasionally, problems with starting and stopping SNA View processes may arise. This section documents some of the more common problems and describes the appropriate actions to take to resolve them.
If you attempt to connect to a domain you believe to be active but the Task Manager indicates that the domain is inaccessible, either the HCI and Command Server for that domain are not running properly, or there are problems with the domain's configuration file. In order to gain access to a particular domain, the Task Manager attempts to register to the Command Server for that domain. If this registration is unsuccessful, the domain is considered inaccessible.
First, verify that the SVCMDS_AGENT_ADDR parameter in the desired domain's configuration file in /etc is set to the appropriate workstation---that which is running the Command Server. If this workstation is not the same workstation running the Task Manager, verify that the SVCMDS_AGENT_PORT value is also set correctly. If either of these parameters is set incorrectly, correct them and reattempt to connect to the domain.
Next, issue one of the following commands, depending upon your operating system, to determine what SNA View processes are currently running.
On HP-UX, AIX, OSF/1, and Solaris systems:
ps -ef|grep sv
On SunOS systems:
ps -ax|grep sv
The response to this command will indicate whether or not the HCI and Command Server are actually running for the desired domain.
If the HCI and Command Server are running for domain DOMAIN1, for example, messages similar to the following will be displayed:
root 14154 1 8 05:13:47 ? 0:00 /usr/sv/bin/svcommand_tcp_server DOMAIN1 root 14152 1 8 05:13:42 ? 0:00 /usr/sv/bin/svhci_tcp_server DOMAIN1 root 14187 14138 0 05:24:37 ttyp5 0:00 grep sv
If the HCI and Command Server are shown by the ps command to be active, either they did not initialize successfully, or the Command Server is no longer accepting registration requests. In either case, check the console where they were started for SNA View error messages. If you are unable to locate any error messages, stop the HCI and Command Server processes using the UNIX kill command.
Re-starting the HCI and Command Server in LU6.2 environments
If the domain uses LU6.2 communication between the mainframe and workstation, the SERVER subtask of the mainframe component must be recycled. This will automatically start the HCI and Command Server on the workstation. After the SERVER subtask has been restarted, verify that the HCI and Command Server have started successfully. If they have not, refer to "Problems Starting the Host Connection Interface and Command Server Tasks" for more information.
Restarting the HCI and Command Server in TCP/IP environments
If the domain uses TCP/IP communications between the mainframe and workstation, simply restart the HCI and Command Server tasks, noting the SNA View initialization-complete messages as follows:
SVINI001 Host Connection Interface initialized successfully for domain
[DOMAIN].
SVINI001 Command Server initialized successfully for domain [DOMAIN].
If the above SVINI001 messages are not produced, or if the HCI and Command Server exit for any reason, refer to "Problems Starting the Host Connection Interface and Command Server Tasks" for the appropriate action to take.
The HCI and Command Server are responsible for all communications with the SNA View mainframe component and are therefore critical to all SNA View workstation processes. This section provides solutions to several problem scenarios that could prevent the HCI and Command Server from starting successfully.
If the HCI or Command Server are having socket-related communication problems, refer to "Configuration File Problems" for details on parameters required to establish socket communications.
If the HCI and Command Server are having problems establishing TCP/IP or LU6.2 communications with the mainframe component, refer to "Workstation-to-Mainframe Connectivity Problems" for details on specific problems and solutions.
Problems Starting the VTAM Server Task
The VTAM Server is responsible for providing unsolicited VTAM messages to all registered VTAM clients. If the VTAM Server will not initialize successfully, then review the error messages generated and "General Problems" for details on possible solutions. In the "Configuration File Problems" subsection of "General Problems," pay special attention to the SVHCI_AGENT_ADDR and SVHCI_VTAM_PORT configuration parameters. Verify that they are set correctly and that the Host Connection Interface is active.
The MVS Server is responsible for providing unsolicited MVS messages to all registered MVS clients. If the MVS Server will not initialize successfully, then review the error messages generated and "General Problems" for details on possible solutions. In the "Configuration File Problems" subsection of "General Problems," pay special attention to the SVHCI_AGENT_ADDR and SVHCI_MVS_PORT configuration parameters. Verify that they are set correctly and that the Host Connection Interface is active.
The Alert Server is responsible for providing SNA Alerts to all registered Alert clients. If the Alert Server will not initialize successfully, review the error messages generated and "General Problems" for details on possible solutions. In the "Configuration File Problems" subsection of "General Problems," pay special attention to the SVHCI_AGENT_ADDR and SVHCI_ALERT_PORT configuration parameters. Verify that they are set correctly and that the Host Connection Interface is active.
The Alert Server stores SNA Alerts on a per resource basis in a Sybase database. If there is a problem with the Sybase database that prevents the Alert Server from logging in to or writing to the database, the Alert Server may not initialize successfully or run properly.
Environment Variables. The Alert server requires that the SYBASE and DSQUERY environment variables be set properly in order to establish a session with the Sybase database. If DSQUERY is not set, the default value of SNA will be utilized. Verify that these environment variables are set properly before starting the Alert Server.
Database login failure. The Alert Server will generate the following messages if it encounters problems logging in to the Sybase database:
SVSYB000 Sybase database login failure, rc: [rc] SVEXE000 Alert Server failed calling DbLogin(). SVEXE102 Alert Server process of domain [DOMAIN] has exited.
Verify that any and all Sybase servers are up and running properly or contact your Sybase database administrator for assistance. Once these issues are resolved restart the Alert Server.
Database write failure. The Alert Server will generate the following messages if it encounters problems adding or updating database records:
SVSYB010 Unexpected error during attempt to add database record, rc: [rc] SVEXE000 Alert Server failed calling db_filter(). SVEXE102 Alert Server process of domain [DOMAIN] has exited.
or
SVSYB010 Unexpected error during attempt to update database record, rc: [rc] SVEXE000 Alert Server failed calling db_filter(). SVEXE102 Alert Server process of domain [DOMAIN] has exited.
Verify that any and all Sybase servers are up and running properly or contact your Sybase database administrator for assistance. Once these issues are resolved, restart the Alert Server.
The VTAM Message Log process registers as a client of the VTAM Server during initialization. If the VTAM Message Log encounters a problem prior to registration to the VTAM Server, or if it is unable to register to the VTAM Server, the process will fail to initialize. Review the error messages generated and "General Problems" pay for details on possible solutions. In the "Configuration File Problems" subsection of "General Problems," pay special attention to the SVVTAM_AGENT_ADDR and SVVTAM_AGENT_PORT configuration parameters. Verify that they are set correctly and that the VTAM Server is active.
The MVS Message Log process registers as a client of the MVS Server during initialization. If the MVS Message Log encounters a problem prior to registration to the MVS Server or if it is unable to register to the MVS Server the process will fail to initialize. Review the error messages generated and refer to "General Problems" for details on possible solutions. In the "Configuration File Problems" subsection of "General Problems," pay special attention to the SVMVS_AGENT_ADDR and SVMVS_AGENT_PORT configuration parameters. Verify that they are set correctly and that the MVS Server is active.
If the Status Manager will not initialize successfully, note the error messages generated and refer to "General Problems" for details on possible solutions. In the "Configuration File Problems" subsection of "General Problems," pay special attention to the SVHCI_AGENT_ADDR and SVHCI_STATUS_PORT configuration parameters. Verify that they are set correctly and that the Host Connection Interface is active.
Problem relating to discovery and status management include:
Discovery is a process that gathers the information on Physical Units (PUs) for a specific domain and inputs that information into the Sybase database.
To gather information for the discovery process, a connection to the domain must be established. Problems can occur with this connection. Refer to "Workstation-to-Mainframe Connectivity Problems" for more detail.
Discovery gathers the domain information by issuing VTAM displays. These commands may fail in some cases. For details, refer to "Problems Issuing Mainframe Commands."
The Pu_discover process must be given domain name on the command line as its first command argument. If it is not given, the following error will appear:
SVINI011 Domain name must be passed to SNAView Pu_discover.
If a user attempts to run the Pu_discover process after another user or after Root, the mainframe commands will not be able to write the data to the necessary file. This occurs because the permissions set on that file prevent other users from writing to it.
The System Administrator can fix this problem by changing the permissions on the files prefixed by SV_XXX, which reside in the SVWORK_AREA directory.
The Pu_discover process attempts to initiate a session with the Sybase API. If this attempt fails, the program will exit with the following errors:
The Sybase login failed: exiting. SVEXE102 PU_Discover process of domain [domain] has exited.
The Pu_discover process gathers configuration variables from the configuration file for the specified domain. For details regarding errors that may occur during the collection of configuration variables, refer to "Configuration File Problems." The following error messages will be generated if an error should occur:
SVEXE000 PU_Discover failed calling Get_config_vars SVEXE102 PU_Discover process of domain [domain] has exited.
The Pu_discover process logs information about how it populated the database in a file. If Pu_discover cannot open this log file, it will exit with the following error messages:
PU_DISCOVER - Could not open log file: exiting. SVEXE102 PU_Discover process of domain [domain] has exited.
The Pu_discover process gathers some of the data about SNA resources by issuing a VTAM command (d net,clstrs) to the mainframe that it is monitoring. If the response from that command is in error, the Pu_discover process will exit with the following error messages:
PU_DISCOVER - the clstrs command failed: exiting. SVEXE102 PU_Discover process of domain [domain] has exited.
The Pu_discover process gathers resource-specific information by issuing a VTAM command (D net,id=PU_NAME,e) to the mainframe, and piping the response into a file (SVWORKAREA/SV_pu_data.[DOMAIN]). If it cannot open the data file, it will stop collecting data for that resource and output the following error message:
PU_DISCOVER - data_collection - cannot open pu data file: return.
If Pu_discover finds an error in the above mentioned file it, will stop gathering data for that resource and output the following error message:
PU_DISCOVER - the clstrs command failed: return.
Pu_discover gathers the RIF data by issuing a command to NetView or Netmaster (getrif PU_NAME PU_NAME) and piping the response into a file (SVWORKAREA/SV_mac_rif.[DOMAIN]) If an error occurs in attempting to open the file, the following error message will be displayed:
PU_discover - Unable to open RIF-MAC data file.
The Pu_discover process must convert VTAM data into data types that Sybase will be able to store. If an error occurs in type conversion, one of the following sets of error messages will be generated:
PU_DISCOVER - PU type not converted: return = PU_TYPE_NUMBER logfile PU NAME = PU_NAME was not added: type conversion failed. PU_DISCOVER - PU status not converted: return = STATUS_NUMBER logfile PU NAME = PU_NAME was not added: status conversion failed. PU_DISCOVER - LU status not converted: return = STATUS_NUMBER logfile LU NAME = %s was not added: status conversion failed.
The Pu_discover process uses the debug file $SVHOME/parm/svdebug.parm to determine what level of debug to use. If the file does not exist, if it has incorrect permissions assigned, or if SVDISCOVER is not a valid debug process name, the PU_discover process will exit with the following errors:
SVINI040 Error setting debug value, unable to find module PU_Discover in PU_Discover. SVEXE102 PU_Discover process of domain [domain] has exited.
If Discovery encounters a resource that it does not know how to handle, it will issue the following messages:
SVDIS500 An unknown ISTXXXI message was found: exiting. SVEXE102 Evoicon_up process of domain [domain] has exited.
Please contact the Cisco TAC if this problem occurs.
This is a configuration issue. In "Configuration File Problems," review the information provided for the configuration variable, INCLUDE_LUS. This parameter must be set to "YES" (or "yes") in order to enable discovery of Logical Units.
The Status Manager updates the workstation database with the current statuses of VTAM-known resources. The Status Manager can also keep the workstation management database updated with the appearance of new resources. There is a Status Manager for each managed domain.
To receive information on status changes, a connection to the monitored domain must be established. Problems can occur with this connection. Refer to "Workstation-to-Mainframe Connectivity Problems" for more detail.
If connectivity does not exist when Status Manager is activated, the following messages will be displayed:
SVINI000 Status Manager initialized successfully. SVSOK001 server_connect_tcp_socket() failed calling connect(), reason: Connection refused SVSOK051 Socket connect failed, no retry will be attempted. SVEXE100 server_connect_tcp_socket() process has exited.
The Status Manager gathers information on new resources by issuing VTAM displays. These commands may fail in some cases. For details, refer to "Problems Issuing Mainframe Commands."
The Pu_status_manager process must be given domain name on the command line as its first command argument. If it is not given, the following error will appear:
SVINI011 Domain name must be passed to SNAView Pu_status_manager.
The Pu_status_manager process attempts to initiate a session with the Sybase API. If this attempt fails, the program will exit with the following errors:
The Sybase login failed: exiting. SVEXE102 PU_status_manager process of domain [domain] has exited.
The Pu_status_manager process gathers configuration variables from the configuration file for the specified domain. For details regarding errors that may occur during the collection of configuration variables, refer to "Configuration File Problems." The following error messages will be generated if an error should occur:
SVEXE000 Pu_status_manager failed calling Get_config_vars SVEXE102 Pu_status_manager process of domain [domain] has exited.
The Pu_status_manager process uses the configuration variable SVSOCKET_MODE to determine whether it should connect to the HCI with a TCP or UNIX Domain socket. If this variable is not set correctly, Pu_status_manager will exit with the following error messages:
SVINI020 Pu_status_manager encountered invalid value for configuration parameter SVSOCKET_MODE. SVEXE102 Pu_status_manager process of domain [domain] has exited.
Since Pu_status_manager is a standard client, the socket errors (SVSOKxxx) described in "SNA View Workstation Messages" should be referred to for details.
The Pu_status_manager process gathers resource-specific information by issuing a VTAM command (d net,id=PU_NAME,e) to the mainframe and piping the response into a file (SVWORKAREA/SV_sm_pu_data.[DOMAIN]). If it cannot open the data file, it will stop collecting data for that resource and output the following error message:
PU_STATUS_MANAGER - data_collection - cannot open pu data file: return.
If Pu_status_manager finds an error in the above mentioned file it will stop gathering data for that resource and output the following error message:
PU_STATUS_MANAGER - the clstrs command failed: return.
The Pu_status_manager process gathers the RIF data by issuing a command to NetView or Netmaster (getrif PU_NAME PU_NAME) and piping the response into a file (SVWORKAREA/SV_mac_rif.[DOMAIN]). If an error occurs in attempting to open the file, the following error message will be displayed:
Pu_status_manager - Unable to open RIF-MAC data file.
The Pu_status_manager process must convert the VTAM data into the data types that Sybase will be able to store. If an error occurs in type conversion, one of the following sets of error messages will be output:
PU_STATUS_MANAGER - PU type not converted: return = PU_TYPE_NUMBER logfile PU NAME = PU_NAME was not added: type conversion failed. PU_STATUS_MANAGER - PU status not converted: return = STATUS_NUMBER logfile PU NAME = PU_NAME was not added: status conversion failed. PU_STATUS_MANAGER - LU status not converted: return = STATUS_NUMBER logfile LU NAME = %s was not added: status conversion failed.
The Pu_status_manager process uses the debug file $SVHOME/parm/svdebug.parm to determine what level of debug to use. If the file does not exist, if it has incorrect permissions assigned, or if SVSTATUS is not a valid debug process name, the PU_status_manager process will exit with the following errors:
SVINI040 Error setting debug value, unable to find module Pu_status_manager in Pu_status_manager. SVEXE102 Pu_status_manager process of domain [domain] has exited.
Check Status is a process that issues a display to the SNA domain in which the resource to be updated resides, then uses the display to update the resource's status. Check Status can also add new nodes under a resource if they are not already in the workstation management database.
Connectivity to the domain in which the resource resides must be established in order to receive the display information. Refer to "Workstation-to-Mainframe Connectivity Problems" for more detail.
If connectivity does not exist when Check Status is activated, the following messages will be displayed:
SVEXE120 Evo_identify can not reach domain [DOMAIN]: exiting. SVEXE100 Evo_identify process has exited.
Check Status gathers information on new resources by issuing VTAM displays. These commands may fail in some cases. For details refer to "Problems Issuing Mainframe Commands."
The Pu_identify process must be given a domain name and at least one resource Physical Unit name that exists in the specified domain on the command line. If it is not given, the following error will be generated:
PU_IDENTIFY - Usage pu_identify < [resource name]... [resource name]>.
The Pu_identify process attempts to initiate a session with the Sybase API. If this attempt fails, the program will exit with the following errors:
The Sybase login failed: exiting. SVEXE102 PU_identify process of domain [domain] has exited.
The Pu_identify process gathers configuration variables from the configuration file for the specified domain. For details regarding errors that may occur during the collection of configuration variables, refer to "Configuration File Problems." The following error messages will be generated if an error should occur:
SVEXE000 Pu_identify failed calling Get_config_vars SVEXE102 Pu_identify process of domain [domain] has exited.
The Pu_identify process gathers resource specific information by issuing a VTAM command (d net,id=PU_NAME,e) to the mainframe and piping the response into a file (SVWORKAREA/SV_cs_pu_data.[DOMAIN]). If it cannot open the data file, it will stop collecting data for that resource and output the following error message:
PU_IDENTIFY - data_collection - cannot open pu data file: return.
If Pu_identify finds an error in the above-mentioned file it will stop gathering data for that resource and output the following error message:
PU_IDENTIFY - the clstrs command failed: return.
The Pu_identify process gathers the RIF data by issuing a command to NetView or NetMaster (getrif PU_NAME PU_NAME) and piping the response into a file (SVWORKAREA/SV_mac_rif.[DOMAIN]) If an error occurs in attempting to open the file, the following error message will be displayed.
Pu_identify - Unable to open RIF-MAC data file.
The Pu_identify process must convert the VTAM data into data types that Sybase will be able to store. If an error occurs in type conversion, one of the following sets of error messages will be output:
PU_IDENTIFY - PU type not converted: return = PU_TYPE_NUMBER logfile PU NAME = PU_NAME was not added: type conversion failed. PU_IDENTIFY - PU status not converted: return = STATUS_NUMBER logfile PU NAME = PU_NAME was not added: status conversion failed. PU_IDENTIFY - LU status not converted: return = STATUS_NUMBER logfile LU NAME = LU_NAME was not added: status conversion failed.
The Pu_identify process uses the debug file $SVHOME/parm/svdebug.parm to determine what level of debug to use. If the file does not exist, if it has incorrect permissions assigned, or if SVSTATUS is not a valid debug process name, the PU_identify process will exit with the following errors:
SVINI040 Error setting debug value, unable to find module Pu_identify in Pu_identify. SVEXE102 Pu_identify process of domain [domain] has exited.
Users may issue mainframe commands via the Mainframe Commands window and via the SNA View pull-down menus integrated into CiscoWorks Blue Maps. This section discusses solutions to the following potential problems:
If a command client is unable to register to the Command Server, the following error message will be written to a Motif pop-up window (in the case of the Mainframe Commands window):
SVSRV050 Timed out waiting for registration response.
In the instance where the user was issuing an SNA View pull-down menu command, error messages would be written to stderr (on the console where the management platform was launched) and to the Command Response Display window. These messages are shown below:
Console Example:
SVSRV050 Timed out waiting for server registration response. SVSRV070 Verify that the HCI and Command Servers are active. SVEXE102 svhost_cmd process of domain [domain name] has exited.
Command Response Display Example:
SVSRV055 Timed out waiting for command response from Command Server. SVSRV071 Command not processed. Verify that the HCI and Command Servers are active.
There are three possible causes for this problem.
To correct the problem:
If, after entering your user ID and password, and selecting the OK button the Mainframe Logon window, you receive an Invalid User ID or an Invalid Password message, then verify your user ID and password and try them again. If you are still unable to log in, check with your mainframe system administrator. There will corresponding ICH408I and IRR013I-prefixed messages on the mainframe console which should aid in diagnosing the problem with the ID and password.
If, after entering your user ID and password, and selecting the OK button the Mainframe Logon window, the response is a Verifying...please wait message which is displayed for an unusually long wait period, verify that the SEC subtask has been started on the mainframe. If the SEC task is not running, you will be unable to log in to issue mainframe commands. Resolve this problem and restart the Mainframe Commands window.
Commands issued through SNA View's integrated pull-down menus rely on the SVCMD_TIMEOUT configuration parameter to specify the length of time (in seconds) that they will wait for a response from the mainframe. If this time is exceeded, error messages will be written to stderr (console where the management platform was launched) and to the Command Response Display Window.
These error messages are shown below:
Console Example:
SVSRV055 Timed out waiting for command response from Command Server. SVSRV070 Verify that the HCI and Command Servers are active. SVEXE102 svhost_cmd process of domain [domain name] has exited.
Command Response Display Example:
SVSRV055 Timed out waiting for command response from Command Server. SVSRV071 Command not processed. Verify that the HCI and Command Servers are active.
Refer to the information on the SVCMD_TIMEOUT information in "Configuration File Problems" for details on this parameter.
The Mainframe Command window will wait indefinitely on command responses from the host. There is no time-out period, but if command responses are very slow or if only partial command responses are returned, there may be a problem with the performance group setting for the mainframe task. Refer to the information on the SVCMD_TIMEOUT parameter in "Configuration File Problems" for details on the performance group setting.
The following situations can arise while issuing VTAM commands.
If the following message is received, VTAM on the mainframe did not recognize the command issued:
IST010I XXX COMMAND INVALID
Verify the syntax of the command you are attempting to issue and try again. Refer to IBM's VTAM Operations Guide for the syntax for specific commands.
If no command responses are returned for VTAM commands issued, verify that at least one SPO subtask is active on the mainframe. At least one SPO subtask must be active in order to process VTAM mainframe commands from the workstation. Refer to the CiscoWorks Blue SNA View Mainframe Installation Guide or your system administrator for details on how to determine if a SPO subtask is active.
If no command responses are returned for MVS commands issued, verify that the CMD subtask is active on the mainframe. The CMD subtask is responsible for processing MVS commands issued through SNA View. Refer to the CiscoWorks Blue SNA View Mainframe Installation Guide or your system administrator for details on determining if the CMD subtask is active.
The following situations can arise while issuing NetView commands.
If no command responses are returned for NetView commands issued, verify that the PPI subtask is active on the mainframe. The PPI subtask is responsible for processing NetView commands issued through SNA View. Refer to the CiscoWorks Blue SNA View Mainframe Installation Guide or your system administrator for details on determining if the PPI subtask is active.
The mainframe component will return an SV315 message when the command operator specified by the SVCMD_OPERATOR configuration parameter is invalid.
For example, if SVCMD_OPERATOR was set to OPERATOR1 and OPERATOR1 was neither a valid NetView operator nor currently logged on, then the SV315 message would be structured as follows:
SV315 OPERATOR1 COMMAND EXECUTION FAILED
Refer to "Configuration File Problems" for details on the SVCMD_OPERATOR configuration parameter.
Potential problems with unsolicited mainframe messages are categorized as follows:
The following situations can arise with receiving unsolicited VTAM messages.
If the VTAM Messages client window does not come up successfully, review the error messages issued by the process to standard error. Also, refer to "General Problems" for details on possible solutions.
If the VTAM Messages window appears, but times out while attempting to register to the VTAM Server, the following error message will appear in a Timeout Notification popup window:
SVSRV050 Timed out waiting for server registration response
Two things could cause the registration to time out: either the VTAM Server is not up and running properly, or the SVVTAM_AGENT_ADDR and/or SVVTAM_AGENT_PORT configuration parameters are not set correctly. Verify that the VTAM Server is running on the proper machine and, if so, refer to "Configuration File Problems" for details on the SVVTAM_AGENT_ADDR and SVVTAM_AGENT_PORT parameters.
There are several reasons why the VTAM Message client may not be receiving VTAM messages from the VTAM Server. We will assume at this point that the VTAM messages are currently being generated by VTAM on the mainframe.
When SNA View is running in conjunction with NetView, the PPI subtask must be active in order for SNA View to receive unsolicited VTAM messages. If running in a VTAM-only environment, the PPO subtask must be active in order to receive VTAM messages. Verify that the proper SNA View subtask is currently active on the mainframe by contacting your mainframe system administrator.
Another possibility is system or client filters may be set which are filtering out VTAM messages before they reach the VTAM Message client. The VTAM Server will only forward to clients the VTAM messages that are not eliminated by the filters specified in the $SVHOME/parm/svvtamsysfilter.tbl file. Verify that the contents of this file have not been set in such a way as to filter out the VTAM messages you are expecting. Similarly, client filters set up on the VTAM Window itself may be filtering out the messages you are expecting.
The following situations can arise with receiving unsolicited MVS messages.
If the MVS Messages client window does not come up successfully, review the error messages issued by the process to standard error. Also, refer to "General Problems" for details on possible solutions.
If the MVS Messages window appears but then times out while attempting to register to the MVS Server, the following error message will appear in a Timeout Notification popup window:
SVSRV050 Timed out waiting for server registration response
Two things could cause the registration to time out. Either the MVS Server is not up and running properly, or the SVMVS_AGENT_ADDR and/or SVMVS_AGENT_PORT configuration parameters are not set correctly.
Verify that the MVS Server is running on the proper machine and, if so, refer to "Configuration File Problems" for details on the SVMVS_AGENT_ADDR and SVMVS_AGENT_PORT parameters.
There are several possible explanations why the MVS Message client is not receiving any MVS messages from the MVS Server. We will assume at this point that the MVS messages are currently being generated by MVS on the mainframe.
The MVS subtask of the SNA View Mainframe Component must be active in order to receive unsolicited MVS messages. Verify that this subtask is active by contacting your mainframe system administrator.
System or client filters may be set that filter out MVS messages before they reach the MVS Message client. The MVS Server will only forward MVS messages to clients that are not filtered out by the filters specified in the $SVHOME/parm/svmvssysfilter.tbl file. Verify that the contents of this file has not been set in such a way as to filter out the MVS messages you are expecting. Similarly, client filters set up on the MVS Window itself may be filtering out the messages you are expecting.
The following situations can arise with receiving SNA alerts.
If the Alert client window does not come up successfully, then review the error messages issued by the process to standard error. Also, refer to "General Problems" for details on possible solutions.
If the Alert window appears but then times out while attempting to register to the Alert Server, the following error message will appear in a Timeout Notification popup window:
SVSRV050 Timed out waiting for server registration response.
Two things could cause the registration to time out: either the Alert Server is not up and running properly, or the SVALERT_AGENT_ADDR and/or SVALERT_AGENT_PORT configuration parameters are not set correctly.
Verify that the Alert Server is running on the proper machine and, if so, refer to "Configuration File Problems" for details on the SVALERT_AGENT_ADDR and SVALERT_AGENT_PORT parameters.
When SNA View is running in conjunction with NetView, the PPI subtask must be active in order for SNA View to receive unsolicited alert data. If running in a VTAM-only environment, the CNM subtask must be active in order to receive SNA alerts. Verify that the proper SNA View subtask is currently active on the mainframe by contacting your mainframe system administrator.
The following situations can arise with retrieving alarm summary information for an SNA resource.
If the Alarm Summary window does not come up successfully, review the error messages issued by the process to standard error. Also, refer to "General Problems" for details on possible solutions.
The Alarm Summary process will issue the following error message to a Motif pop-up window in the event that the selected resource has no alerts stored in the alert database:
SVSYB050 Alert database contains no record for resource [resource]
Please select another SNA resource or verify that the Alert Server is active and wait until an SNA alert is received against this resource.
This section details problems related to communications between the mainframe and the workstation in TCP/IP and LU6.2-connected environments.
If the Host Connection Interface or the Command Server will not initialize successfully and you believe this to be due to communications problems between the workstation and mainframe, perform the following steps:
If any of these steps do not verify correctly, resolve the problem and recycle SNA View.
LU6.2 connectivity issues can be rather complex to debug. The vast majority of LU6.2 connectivity issues are resolved during the installation phase of SNA View when communications are initially configured.
The best source of information for debugging LU6.2 problems is the job log of the SNA View mainframe component. This log will contain any error messages written by the failed SERVER subtask. Please refer to the CiscoWorks Blue SNA View Mainframe Installation Guide for more details on problems and solutions with the SERVER subtask and LU6.2 communications. This section discusses issues specific to the SNA stacks that SNA View will run under.
If HP's SNAplus software is in use, there are two sources of information that are helpful when troubleshooting LU6.2 connectivity problems: logs (audit and error messages) and link traces.
SNAplus generates audit and error messages during operation and writes them to files specified during configuration of SNAplus. The default SNAplus configuration file (com.cfg) shipped with SNA View specifies the default sna.aud and sna.err files as the destinations for audit and error logging, respectively. These files may need to be modified using the snapconfig program. Please refer to the HP-UX SNAplusLink Administrator's Guide for more details on specifying log files and message severity levels.
Starting a link with tracing means that in addition to the diagnostic messages written to the audit and error logs, tracing information is written to the trace files snafile1.trc and snafile2.trc. You must use the snapmanage program to start a link with tracing. Please refer to the HP-UX SNAplusLink Administrator's Guide for more details.
The following situations can arise with using IBM's SNA Services or SNA Server software for host connectivity.
When the SNA View mainframe component is started with a SERVER subtask, the SNA Services/Server application running on the RISC/6000 receives an FMH5 transmission from the host and launches the transaction programs specified in the LU6.2 Transaction Program Profiles configured during SNA View installation. These transaction programs are named as follows:
svhci_server_DOMAIN1 svcommand_server_DOMAIN1
where DOMAIN1 in this example is the SNA View SNA domain to be managed. These executables reside in the $SVHOME/bin directory and should have been created by the SNA View workstation installation program. If these two files are not present for each domain to be managed via LU6.2 communications, they can be created by issuing the following commands, replacing DOMAIN1 with your domain name:
cp $SVHOME/bin/svhci_server $SVHOME/bin/svhci_server_DOMAIN1 cp $SVHOME/bin/svcommand_server $SVHOME/bin/svcommand_server_DOMAIN1
The SNA Services and SNA Server applications maintain error logs which detail SNA (and therefore LU6.2) failures that occur. Follow these steps or refer to the appropriate SNA Server/Services documentation to generate error reports:
Use this detailed information along with any job log error data from the SNA View mainframe component to determine the cause of the communication failure.
This document explains the messages generated by the SNA View workstation component.
The following categories of messages are described in this appendix:
file is the SNA View install file.
file is the SNA View install file.
process is the SNA View process or routine.
protocol is the socket protocol.
socket is the specific socket option.
socket is the specific socket option.
process is the SNA View server process.
process is the SNA View client process name.
process is the SNA View server process.
process is the SNA View server process.
process is the SNA View client process.
process is the SNA View client process.
explanation is the text error explanation.
process is the SNA View server process.
process is the SNA View server process.
process is the SNA View command client process.
process is the SNA View process or routine.
direction is inbound or outbound.
direction is inbound or outbound.
direction is inbound or outbound.
conversation is the inbound or outbound conversation.
conversation is the inbound or outbound conversation.
conversation is the inbound or outbound conversation.
process is the SNA View process.
process is the SNA View process.
process is the SNA View process.
process is the SNA View process.
process is the SNA View process.
text is the error message text.
process is the SNA View process.
process is the SNA View process.
process is the SNA View process.
process is the SNA View process.
was started without the domain name passed in as an argument. The SNA View process requires the domain name argument to determine the proper configuration file to utilize. The SNA View process will terminate.
SVINS000
Install Program was unable to locate a domain menu entry.
SVINS010
Install Program was unable to copy file to directory.
directory
is the destination directory.
SVINS011
Install Program was unable to append file to path.
path
is the destination file path.
Socket Communication Messages --- SVSOKxxx
SVSOK001
process failed calling function, reason: explanation
function
is the system socket function.
explanation
is the text error explanation.
SVSOK010
Unable to open protocol method socket.
method
is either the stream or datagram method.
SVSOK020
Unable to bind socket.
SVSOK030
Unable to set socket to non-blocking mode.
SVSOK031
Unable to set socket to blocking mode.
SVSOK040
Error on listen for socket connection.
SVSOK050
Socket connect failed, will retry momentarily.
SVSOK051
Socket connect failed, no retry will be attempted.
SVSOK070
Unable to get socket option: socket
SVSOK071
Unable to set socket option: socket
SVSOK080
process failed reading HCI socket, reason: explanation
explanation
is the text error explanation.
SVSOK081
Failure reading process client UDP socket.
SVSOK082
Failure reading process server UDP socket, number bytes returned is zero.
SVSOK083
Failure reading process server UDP socket, entire message not received.
SVSOK090
Failure writing to process client UDP socket.
SVSOK092
Failure writing to process client UDP socket, entire message not sent.
SVSOK199
Failure reading SNAview mainframe Message Server, reason: explanation .
SVSOK200
Lost connection with SNAView Mainframe Message Server.
SVSOK201
process has exited due to read failure on HCI connection.
SVSOK202
process has exited due to loss of connection with the HCI.
SVSOK203
process has exited due to loss of connection with the Command Server.
LU6.2 Communication Messages --- SVLUXxxx
SVLUX000
process failed calling name with errno: renumber
name
is the LU 6.2 system routine name.
renumber
is the error return.
SVLUX010
Failure opening direction LU6.2 conversation.
SVLUX020
Failure allocating direction LU6.2 conversation.
SVLUX030
Failure reading over direction LU6.2 conversation.
SVLUX035
Control received value from mainframe signals termination.
SVLUX040
Failure confirming conversation LU6.2 conversation read.
SVLUX050
Failure sending over conversation LU6.2 conversation.
SVLUX060
Failure closing conversation LU6.2 conversation.
Management Platform API Messages --- SVAPIxxx
SVAPI001
process can not make initial connection with management API.
SVAPI002
process was not able fill symbol map.
SVAPI003
process was not able fill status map.
SVAPI004
process was not able to lock data base.
SVAPI005
process failed trying to add a node to the management platform: code.
code
is the integer error code.
SVAPI100
API error message: text .
Process Initialization Messages --- SVINIxxx
SVINI000
process initialized successfully.
SVINI001
process initialized successfully for domain name.
name
is the SNA View defined domain name.
SVINI010
process started with invalid argument count.
SVINI011
Domain name must be passed in to the SNAView process .