Chapter 4 - Monitoring StreetTalk for Windows NT Software
In addition to StreetTalk for Windows NT management tools, Windows NT provides some built-in system monitoring tools that display useful information about StreetTalk services.
Both Banyan StreetTalk and Windows NT messages appear in pop-up windows. StreetTalk error messages are usually preceded by a number. Run the Z:\VNSERR command from the system prompt with the error number as the argument to get a description of the error. Additional information on these errors is provided in Banyan Return Codes. The Windows NT Resource Kit contains information for Windows NT errors.
The following StreetTalk for Windows NT services automatically generate log files:
![]()
StreetTalk Naming Service ![]()
StreetTalk Security Service ![]()
StreetTalk Directory Assistance Service
Intelligent Messaging, SNM, IMAP, LDAP, Server Service, StreetTalk File, and StreetTalk Print provide log information only to the Event Viewer, which is described in the next section. Managing StreetTalk for Windows NT Services describes file and print logging capabilities.
Services that create log files maintain two log files (for example, ST0.log and ST1.log). The log files are from 10 KB to 50 KB in size and are rotated so that when one log file is filled, the service discards the contents of the other log file and then writes to it.
To specify the volume and kinds of messages that are logged, run a Banyan management tool to set a log level that ranges from No Logging to Debug Log Level. As you increase the log level, you also increase the volume of messages that are logged. StreetTalk Explorer also allows you flush log information held in memory to disk.
You are not required to set a log level because the logs have default levels. However, setting a log level can make your job as an administrator easier because you can isolate specific messages.
Log files are ASCII files and are stored in the \Program Files\Banyan\data\servicename directory. Use an ASCII editor to view the contents of log files.
Note: You cannot remotely generate a log report for StreetTalk for Windows NT services. Log files must be viewed from the StreetTalk for Windows NT server.
The Event Viewer reports all error messages handed to it by the various services and processes running on the StreetTalk for Windows NT server. In some cases, StreetTalk networking components will log messages with the event viewer.
When all StreetTalk for Windows NT services start and initialize, you can double-click an event to display a detailed description of the event in the Event Viewer. For example, when a print service is started, a message similar to the following is displayed:
Successfully started LaserPrinter@IS-NT-14@Servers with the print queue IBM 4019 Laser Printer.
When UDP Client software or Server-to-Server UDP software is disabled, the system log of the Event Viewer displays a message with a red stop symbol and a detailed event similar to the following:
\Device\Vns:UDP server support disabled by config.
The detailed event does not indicate an error. Instead, it reports that the StreetTalk for Windows NT configuration program was used to disable UDP Client or S-to-S UDP software.
Wrapping
It is recommended that you set an option for logging events to ensure that the Event Viewer log does not fill up. If the log fills up, Windows NT overwrites the oldest events - those more than seven days old - and displays a warning message that the logs are full every time a new event is recorded. From the Event Viewer' s log menu, it is recommended that you set Event Log Wrapping to Overwrite Events as Needed.
The \Program Files\Banyan\Support directory contains these diagnostic programs intended for use by Banyan support personnel:
![]()
GETARLS.EXE - StreetTalk File utility to store ARLs ![]()
GETPROCS.EXE - StreetTalk Communication debugging utility ![]()
MANLY.EXE - StreetTalk Mail debugging utility ![]()
PUTARLS.EXE - StreetTalk File utility to restore ARLs ![]()
STDACLI.EXE - STDA test utility ![]()
STANLEY.EXE - StreetTalk database analysis utility ![]()
STCLIENT.EXE - StreetTalk client utility ![]()
SVCLOG.EXE - Flushes logs and sets the log level in a service ![]()
VSANLY.EXE - StreetTalk Security Service test utility ![]()
VSCLIENT.EXE - StreetTalk Security Service client test utility ![]()
XDA.EXE - STDA data files test utility
The Registry is a large, internal database of all the software and hardware options loaded on or configured for the StreetTalk for Windows server. The Registry editor, REGEDT32.EXE or REGEDIT.EXE, should be used with caution. You can use the Registry to:
![]()
Check on the configuration of and dependencies for the various services and processes that are necessary for Windows NT to function ![]()
Spot incorrect or conflicting entries that prevent services from starting ![]()
Give you a view of how Windows NT works and is organized, as well as which services are dependent on others starting in order for them to run.
The StreetTalk for Windows NT Administrator's Guide describes the StreetTalk for Windows NT entries in the Windows NT Registry.
Windows NT programs in the Control Panel provide additional information about StreetTalk for Windows NT.
The Devices applet in the Control Panel lists the StreetTalk for Windows NT device driver installed in the Windows NT kernel after startup. If you install the Enterprise Client for Windows NT, it also lists the client redirector installed in the Windows NT kernel. It shows the current status of each driver as well as any startup parameters. See Table 4-1.
Device | Status | Startup | Description |
StreetTalk Communications | Started | Manual | StreetTalk communications driver. |
VinesIFS | Started | Manual | VINES Installable File System redirector for Enterprise Client for Windows NT. VinesIFS is installed only if the Enterprise Client for Windows NT is installed |
Check that the StreetTalk for Windows NT services that you installed are running.
The StreetTalk for Windows NT services (for example, StreetTalk File) displayed by the Services dialog box are Windows NT service processes - programs that work directly with the Windows NT operating system. A Windows NT service process is stopped or started by the Windows NT Services Control Manager (SCM). These services are automatically created when StreetTalk for Windows NT software is installed.
A StreetTalk for Windows NT service has a StreetTalk name (item@group@org) and performs tasks required by users. StreetTalk services can be created, started, and stopped by StreetTalk Explorer or another StreetTalk for Windows NT management tool. One Windows NT service can support multiple StreetTalk for Windows NT services. For example, you can create more than one StreetTalk print service after the StreetTalk for Windows NT Print service starts.
You must use StreetTalk Explorer to create a StreetTalk File or StreetTalk Print service. After the service is created, its status is displayed by StreetTalk Explorer.
Note: You should always use a Banyan management tool to stop and start StreetTalk for Windows NT services. However, Banyan management tools cannot stop the StreetTalk Naming service, the StreetTalk Server Service, or the StreetTalk Security Service.
The Services applet in the Control Panel lists all the defined StreetTalk for Windows NT services that have either started automatically or need to be started manually. It shows the current status of each service as well as any startup parameters. Even though you can also use this applet to start or stop any StreetTalk for Windows NT service, it is not recommended that you do so.
StreetTalk Server Service Control of Services
StreetTalk Server Service treats any service stopped by the Windows NT Service Control Manager as a service that has crashed. Server Service tries to restart the service. If you use the Service Control Manager to start a StreetTalk for Windows NT service, Server Service is not aware of the service unless its startup value is set to automatic. If a service is running and its startup value is manual, StreetTalk Server Service does not try to restart it if it crashes. For more information, see the section, "Auto-restarting Services."
Note: Always use StreetTalk Explorer to stop and start StreetTalk for Windows NT services; do not use the Windows NT Service Control Manager.
Table 4-2 shows the default status of all StreetTalk for Windows NT services.
Service | Status | Startup | Notes |
StreetTalk | Started | Automatic | If you stop StreetTalk, all other services will not run. |
StreetTalk Security Service | Started | Automatic | If you stop the StreetTalk Security Service, all other services will not run. |
StreetTalk Server Service | Started | Automatic | If you stop the StreetTalk Server Service, all other services will not run. |
StreetTalk Directory Assistance | Stopped | Disabled | When you create and start an STDA service, the StreetTalk Name Collector Service is started. The STDA service and the Name Collector Service should always have the same status. |
StreetTalk Name Collector | Stopped | Disabled | The StreetTalk Name Collector service is the back end STDA database program responsible for rebuilding the STDA database. This service is started when you create and start an STDA service. When you stop an STDA service, this service is also stopped. |
StreetTalk File | Started | Automatic | After you create and start a StreetTalk for Windows NT file service, you can use StreetTalk Explorer to stop an individual file service. Using the Windows NT Services Manager to stop the StreetTalk File service stops all Banyan file services. |
StreetTalk Print | Started | Automatic | After you create and start a StreetTalk for Windows NT print service, you can use StreetTalk Explorer to stop an individual print service. Stopping the Windows NT service stops all Banyan print services. |
StreetTalk Intelligent Messaging | Stopped | Disabled | StreetTalk Intelligent Messaging provides mail service for clients. If you create and start the service, the Status and Startup become Started/Automatic. |
StreetTalk IMAP Service | Stopped | Disabled | Present only if you install IMS IMAP. If you create and start the service, the Status and Startup become Started/Automatic. |
StreetTalk LDAP Service | Stopped | Disabled | Present only if you install LDAP. If you create and start the service, the Status and Startup become Started/Automatic. |
StreetTalk Network Management | Started | Automatic | Present only if you install the SNM option. |
Stopping only Server Service with the Service Control Manager does not stop all the other StreetTalk for Windows NT services. Other services are left running. Each service must then be stopped individually.
The startup values in the Service Control Manager for STDA depend on how they are started:
![]()
If the service is started by StreetTalk Server Service, the startup value is changed to Automatic. ![]()
If the service is stopped by StreetTalk Server Service, the startup value is changed to manual. If the server is rebooted, the service comes up as Stopped. ![]()
If STDA startup values are Automatic, and StreetTalk and the StreetTalk Security Service startup values are Manual, and the server is rebooted, StreetTalk and the StreetTalk Security Service are started because STDA depends on StreetTalk and the Security Service to be running. STDA starts them if these services are not running.
If you stop the StreetTalk Naming service, the Security Service is also stopped. If you start the Security Service, the StreetTalk Naming service is started first.
Dependencies
StreetTalk for Windows NT services and device drivers have dependencies recorded in the Windows NT Registry. For information on StreetTalk for Windows NT Registry entries, see the StreetTalk for Windows NT Administrator's Guide.
StreetTalk for Windows NT Server Service can be configured to automatically attempt to restart StreetTalk for Windows NT services that have stopped. By default, StreetTalk Server Service polls stopped services every 5 minutes and attempts to restart services that have terminated abnormally.
You can run the StreetTalk for Windows NT Server Service polling configuration utility (SSPOLL.EXE) in the appropriate language directory of the BIN directory (for example, PROGRAM FILES\BANYAN\BIN) to change the default value of 5 minutes. The value is stored in the Windows NT Registry.
To run SSPOLL, you must be logged in to StreetTalk and be a member of AdminList@servername@Servers.
When you run SSPOLL, the Server Service Polling Program dialog box is displayed as shown in Figure 4-1.
When the program starts, it displays the current polling value of the Windows NT Registry entry in the text box. Click Get to display the value currently stored in the Registry. If you change a value and want to restore the original value, click Get.
Enter a new value in minutes (for example, 4 minutes, 0 seconds or 4 minutes, 30 seconds) to change the default value (5 minutes). The maximum value is 30 minutes and the minimum value is 0 seconds. To turn off polling set the value to 0.
Click Set to store the new value in the Windows NT Registry. The change takes effect within 30 seconds if polling was turned off. If you are increasing or decreasing a previously configured value, the change takes effect at the end of the previously configured interval. If you reboot your server or restart Server Service, the value takes effect when Server Service starts. However, you do not have to reboot the server or stop and start Server Service to make a change take effect.
If you use StreetTalk Explorer or MSERVICE to stop a StreetTalk for Windows NT service and auto-restart polling is turned on, Server Service does not attempt to restart the service.
StreetTalk Server Service attempts to restart all abnormally stopped (crashed) StreetTalk for Windows NT services. In the case of StreetTalk File and Print services, Server Service attempts to start them if they are stopped and their startup value in the Service Control Manager is Automatic or Manual. If their startup value is set to Disabled, Server Service does not try to start them.
Guidelines
Follow these guidelines for auto-restarting services:
![]()
Always use a Banyan management tool (for example, StreetTalk Explorer or MSERVICE) to manage StreetTalk for Windows NT file, print, mail, and STDA services. ![]()
If you run the Windows NT Service Control Manager to stop and start StreetTalk for Windows NT services (including the StreetTalk Naming service and the StreetTalk Security Service), turn off auto-restart polling first. Windows NT could generate an internal error if StreetTalk Server Service tries to start a service that the Windows NT Service Control Manager is trying to stop. ![]()
Only the Windows NT Service Control Manager can stop the StreetTalk Naming service, the StreetTalk Security Service, and the StreetTalk Server Service. These services are "eternal." If you must stop them, the usual practice is to stop the three of them together. If you stop just the StreetTalk Naming service and leave its startup value as Manual, the StreetTalk Server Service tries to start it. If you stop the StreetTalk Naming service, set the startup value to Disabled or turn off auto-restart polling by setting the polling value to 0.
The Network applet in the Control panel displays the network configuration for the server's LAN adapter card, as well as loaded and bound protocols. Use this applet to check settings and reconfigure the card or loaded protocols.
The Server applet in the Control Panel lets you gather statistics on the server's current usage of system resources. Statistics for file locks, sessions, and open named pipe handles can be monitored with this applet.
The Windows NT Performance Monitor takes a snapshot of how the server's resources are being used. You can display this information as a chart that continually updates. The percentage of privileged time, processor time, user time, and interrupts per second can all be color-coded and displayed on a graph with a scalable timeline.
The Performance Monitor displays the counters for StreetTalk for Windows NT communications. As you add services and users, check the counters regularly to determine when the number of sockets, number of SPP connections, and the communications heap size need to be increased.
Viewing Performance Monitor Statistics
The Windows NT Performance Monitor displays counters for StreetTalk for Windows NT communications protocols. Follow these steps to view the counters in a Performance Monitor chart:
1. Run Performance Monitor from the Administrative Tools program group.
2. From the View menu, select Chart.
3. From the Edit Menu, select Add to Chart or click on the Add counter button.
4. From the Object box, select StreetTalk Communications as the object to be monitored.
5. From the Counter box, select one or more StreetTalk communications counters (for example, Sockets in use, Heap Size, and so on). To display a brief description of the counter, click Explain.
6. Click Add and then click Done to display the chart.
Statistics
The Performance Monitor provides statistics on the StreetTalk for Windows NT protocols described in Table 4-4:
Protocol | Description |
VINES IP | VINES Internet Protocol is responsible for moving units of data called packets through the network. This protocol is also responsible for making routing decisions, which involve determining the appropriate paths packets should take to reach their destinations. A path is an interconnected pattern of data links and nodes that connects two nodes in a network. |
VINES IPC | VINES Interprocess Communications Protocol moves unreliable datagrams and reliable messages between transport layers on different network nodes. IPC handles reliable messages by creating a virtual connection between the IPC protocol entities on the host and destination nodes. IPC on the destination node reassembles reliable messages that consist of multiple packets and sends them to higher level processes in a single unit. IPC acknowledges these messages and guarantees that they are placed in the port queue only once. |
VINES RTP | VINES Routing Update Protocol distributes network topology information among servers using dynamic routing techniques. Banyan servers maintain and dynamically update a routing database that details the least-cost path for routing packets and uses a routing algorithm to resolve contention between two or more identical-cost links. Store-and-forward routing supports dynamic load balancing of redundant equal-cost paths and automatic re-routing around communication failure points. RTP also uses automatic hot backup paths whenever redundant links are available between two nodes. |
VINES SPP | VINES Sequenced Packet Protocol supports virtual connections for the transmission of data streams. An SPP virtual connection is an association between two transport layer ports anywhere in the network. In this way, the VINES transport layer handles multiple, simultaneous SPP virtual connections. SPP guarantees that data is delivered only once and in proper sequence. |
Table 4-5 lists and describes the StreetTalk communications statistics.
Counter | Description |
Sockets in use | The total number of configured sockets currently in use. A socket is an object that the transport layer uses to manage the flow of data between processes. Sockets provide an interface between a process and the transport layer protocol entity. |
Sockets Maximum Open | The largest number of sockets that were in use at any one time since the system was booted (high-water mark). |
Sockets Configured | The allowable, maximum number of sockets that can be open at one time. |
Socket Alloc Failures | The number of times that socket allocation attempts failed since the system was last booted. |
Heap Used (%) | The percentage of the total communications heap size currently in use. Each packet coming into or going out of the system results in buffer usage. As soon as the system processes the packet, it releases the buffer. Since all packets are not the same size, the space that is allocated and released varies in size. Certain conditions, such as LAN noise or heavy traffic, can make buffer use jump quickly into the 90% range or higher but the percentage depends on the total heap size configured. Communications buffers that are requested, but cannot be allocated, result in drops. Communications buffer use between 20% and 35% is typical of a system that is fully loaded and very busy, but healthy. If use is 50% or more, the system may not be able to handle peak loads or transient network errors without causing drops and performance degradation. |
Heap Size (KB) | The amount (in kilobytes) of system memory used for network communications. You can set the total communications heap size from the Network Setup icon. |
Heap Alloc Failures | The number of heap allocation attempts that failed since the system was last booted. Any non-zero number indicates a possible failure to perform some network operation. If the value is non-zero, increase the heap size. |
IPC Sends | Total number of IPC messages sent from this system |
IPC Send Errors | Total number of attempts to send IPC messages that failed due to an error. |
IPC Receives | Total number of IPC messages received on this system. |
IPC Receive Errors | Total number of received IPC messages that could not be processed due to an error. |
IPC Bytes Sent /sec | Number of IPC bytes sent per second. |
IPC Bytes Received /sec | Number of IPC bytes received per second. |
RTP Sends | Number of RTP messages sent from this system. |
RTP Receives | Number of RTP messages received on this system. |
RTP Updates Sent | Number of update packets sent. An update can consist of one or more update packets. Just the update itself is counted, not the number of packets sent. |
RTP Updates Rcvd | Number of RTP update packets received. An update can consist of one or more update packets. The total number of update packets received is counted. |
RTP Responses Sent | Number of RTP responses sent. A response can consist of one or more update packets. Just the response itself is counted, not the number of packets sent. |
RTP Responses Rcvd | The number of RTP responses received. A response can consist of one or more update packets (5.5x and greater and StreetTalk for Windows NT systems) or one or more response packets (5.0x). The total number of packets received is counted. |
SPP Sends | Total number of SPP messages sent. |
SPP Send Errors | Total number of attempts to send SPP messages that failed. |
SPP Receives | Total number of SPP messages received on this system. |
SPP Receive Errors | Total number of attempts to receive SPP messages that could not be processed due to an error. |
SPP Bytes Sent /sec | Number of SPP bytes sent per second. |
SPP Bytes Received /sec | Number of SPP bytes received per second. |
SPP Connections in use | Current number of SPP connections in use. |
SPP Max Connects | The maximum number of SPP connections that were in use at one time since the system was last booted. |
SPP Connections Configured | The allowable maximum number of SPP connections that can be in use by processes on the system at one time. This value is set from the Network Setup icon. |
SPP Disconnects Rcvd | Total number of disconnect packets received. When one end of an SPP connection wants to terminate the connection, it sends a disconnect packet to the other end. |
SPP Disconnects Sent | Total number of disconnect packets sent. When one end of an SPP connection wants to terminate the connection, it sends a disconnect packet to the other end. |
SPP Probes Rcvd | Total number of probe packets received. When one end of an SPP connection misses a packet, it sends a probe packet to the other end of the connection. The other end of the connection then retransmits the missed packet along with all other packets sent after it. |
SPP Probes Sent | Total number of probe packets sent. When one end of an SPP connection misses a packet, it sends a probe packet to the other end of the connection. The other end of the connection then retransmits the missed packet along with all other packets sent after it. |
VIP Sends | Total number of packets sent over VINES IP. VIP Sends include IPC, RTP and ICP packets, packets routed from other systems, and broadcast packets. |
VIP Send Errors | Total number of attempts to send VIP packets that failed due to an error. |
VIP Receives | Total number of packets received over VINES IP. VIP Receives include IPC, SPP, RTP, and ICP packets, packets routed from other systems, and broadcast packets. |
VIP Receive Errors | Total number of packets received over VIP that could not be processed due to an error. |
VIP Bytes Sent /sec | Number of VIP bytes sent per second. |
VIP Bytes Received /sec | Number of VIP bytes received per second. |
VIP Routed Packets | Total received packets routed to another node |
VIP Broadcast Packets | Number of broadcast packets that the system has sent, received, and routed. The system sends broadcast packets to perform various functions that range from routing table updates to StreetTalk updates. Client workstations issue broadcasts to perform various functions, such as finding a VINES Files service or an STDA service. The system will receive or route workstation broadcasts, as well as broadcasts from other servers. |
Changing Communications Settings
After you install StreetTalk for Windows NT software, connect client workstations, and install applications software, you may be required to change communications settings.
In some cases, your system may display COM162 errors (The communications layer did not have enough memory space to process the request.) or COM157 errors (The destination machine specified in the IPCPORT was reached, but no socket was open on the port.) Increasing communications resources as described below may alleviate the problem. In other cases, heavy server usage and inadequate server resources generate the error messages and performance problems. Changing communications settings may have little or no effect. Redistributing the server's load may be required.
Note: You must reboot the StreetTalk for Windows NT server whenever you change communications settings. If you do not reboot, the new setting does not take effect.
If you plan to run a large number of Windows workstations, a greater load is placed on server resources than if the clients were DOS workstations. Consider increasing the maximum number of SPP connections and the size of the communications buffer on the server.
Before increasing these values, use Performance Monitor statistics to determine if your current limits are adequate. Under a normal system load, you should have less than 60 percent of your maximum SPP connections in use and approximately 30 percent of your communications buffer in use. The maximum usage should never equal the configured limits.
You must set the total communications heap size large enough to handle the maximum concurrent SPP connections and open sockets you want to allow. Otherwise, the server will reject connection attempts.
Each SPP connection requires about 100 bytes of the communications buffer. Each open socket also requires 100 bytes of the communications buffer.
If you configure a StreetTalk File service, you can enable idle disconnects to disconnect network drives mapped to a StreetTalk share after being idle for a specified period time. Enabling idle disconnects allows you to conserve SPP connections. For more information, see Managing StreetTalk for Windows NT Services.
Calculating a required heap size is largely a matter of checking performance and then adjusting the setting if performance is impaired. Always check the Performance Monitor statistics before you make any changes to the default setting.
You may not have to increase the default communications heap size (1024 KB). This size is sufficient in most situations. However, if performance problems arise, increasing the default communication heap size by a small amount, such as 20 KB or 30 KB, is often sufficient to get your server functioning smoothly again.
Calculating the communications heap size that is best for your system is an iterative process. If your server has 32 MB of memory and you notice any allocate failures, gradually increase the size by 20 KB increments.
If your system has more than 32 MB of memory, resides on a LAN backbone in a large network, or acts as a router, and you estimate that your services have more than enough memory in which to run, do not hesitate to increase the communication heap size by a significant amount, such as 100 KB. You will still have enough memory left for services and the kernel.
An Empirical Estimate
One way of estimating the total communications heap size is to use an empirical formula. The following formula provides a rough estimate of the additional heap size required as you increase the load on your server. Actual heap size requirements are very sensitive to many factors including network topology and the type of traffic on the network.
MAX Concurrent SPP Connections X 100
+ MAX Concurrent Open Sockets X 100
------------------------------------------------------------------
= TOTAL Bytes Added to Communications Buffer
For example, suppose that you add more services that use SPP connections to a server. Using the Performance Monitor, you determine that the demand for communications buffer usage, SPP connections, and open sockets has increased. You used the defaults for all three limits; now you need to increase the maximum number of SPP connections and open sockets that can be in use at one time.
You decide your server can meet the demand for communications resources if you increase the maximum concurrent SPP connections by 400 and the maximum concurrent open sockets by 250.
You calculate the total additional communications buffer requirements as follows:
(400 X 100) + (250 X 100) = 65,000 (65 KB)
You should add 65 KB to the heap size already configured and monitor the heap size with the Performance Monitor.