Error Conditions and Solutions

This section provides solutions to several error conditions not necessarily accompanied by error messages.

Application on UNIX server inaccessible

The user cannot execute a program residing on a TAS host, for one of the following reasons:

• The application's file permissions deny access to the user. Log in as the owner of the directory that contains the application, or as root, and correct the file permission with the "tnservice" command. Remember, DOS programs need to have UNIX read permission.

• The application has a attribute that tells DOS the drive on which it resides, but the redirected drive uses a different letter.

Compilation problems in DOS window

Compiling programs on a network drive in a Windows DOS prompt window can cause data corruption or dropped connections. For Windows for Workgroups and Windows 3.1, add the following line in the section labeled [386Enh] in the PC's Windows system.ini file:

InDOSPolling=True

Connection failure

Some network boards have more than one cable connection, and some have transceivers on their boards. Make sure the physical hardware jumpers can use the same connection as the software settings.

Dead sessions not dropped

When a user turns off or reboots a client PC, the network connection breaks. If this happens during a data transfer, TAS notices immediately and terminates the appropriate process. If it happens when no traffic passes between client and server, TAS notices only after a few minutes. This timeout period, dependent on the host system, typically lasts about five minutes. After the timeout period elapses, TAS terminates the appropriate process.

TAS, by default, relies on the host's underlying transport layer keepalives to keep track of dead sessions. If other applications, such as telnet, do not drop dead connections, the transport vendor may not have keepalives implemented. You may have configured TAS to use NetBIOS keepalives instead by changing the keepalive attribute with the "tnservice" command.

Disconnected clients still appear connected

When a PC client terminates a session--that is, disconnects a redirected drive--the associated process attempts to close the session in an orderly fashion. This includes removing the file name.number from the directory $TNHOME/TAS/tn/tndb. The name variable represents the machine name of the client PC, and number represents the UNIX ID number of the associated process.

If the client cannot remove this file, it exits without error, but when you check connection status or issue a tnwho or tninfo command, the client appears connected. Verify that totalnet owns the program srm, which does the actual removing of entries from the circuits directory, that srm has a mode of 4511, that totalnet owns the circuits directory, and that the circuits directory has a mode of 755.

DOS commands yield unexpected results

Certain DOS commands may behave unexpectedly, for the following reasons:

• Networked drives where the user does not have write permission in the root directory do not support DOS pipes--commands that include the "|" character. This occurs because a DOS pipe tries to create a temporary file in the root of the current drive.

• Some DOS applications, such as edlin, delete a file and then rewrite it to modify it. If the file links to another UNIX file, the link disappears, and a new, independent file takes its place.

• Some DOS commands report errors that do not seem to relate to their causes. For example, the DOS type command returns Invalid path or filename: when it receives the Access denied message from the server. This can happen when DOS tries to type an inaccessible file. Verify that the device, path, and file names have validity on the server and that the user has access privileges to them.

File locking errors

Files do not properly lock or unlock because the client PC rebooted and file locks did not clear. Run tnck to clear the locks.

Free disk space indicated incorrectly

Client disk space calculation limitations have become too great. DOS has problems with any disk device, whether redirected or local, that reports cluster sizes of 64 kilobytes or larger. Large UNIX systems or machines with, for example, several CD-ROM drives mounted, may represent drives totaling more than four gigabytes. DOS cannot handle numbers of this magnitude.

NetBIOS does not start

When NetBIOS does not start, make sure that the NetBIOS processes completely shut down. Use the ps command to find out whether the NBname or NBdaemon process runs even after you use shut down TAS services. This problem occurs only when a process aborts abnormally. Use the UNIX kill command to terminate the offending process, then use the "tnstart" command.

Performance of network slow

Copying files to or from redirected drives, printing jobs over the network, or executing remote commands yields unduly slow responses, for one of the following reasons:

• The network segment has overloaded. Redesign your network to reduce the workload.

• The network generates too many broadcasts. Consider breaking the LAN into smaller segments.

• NFS generates a high amount of network traffic. If you rely heavily on NFS mounts for remote file systems, replace some by installing TAS on the remote hosts. If a client has to connect to a TAS host and file service requests route over an NFS connection to another computer, twice as much network traffic takes place than when the client connects directly to the second computer.

• TCP packet buffers or window sizes require modification. The procedure for modification on clients depends on the brand of TCP/IP installed. Check the documentation for the client's TCP/IP. In TAS, check, and possibly adjust, the values of the recvbuf and sendbuf attributes, using the "tntransport" command.

"Ping" does not work

This happens for one of the following reasons:

• The software settings in the configuration file do not match the physical hardware settings. Correct either one to match the other.

• The ifconfig command pings to the wrong address. Verify the network mask and the sending and receiving IP addresses.

• The target has an invalid IP address or does not have its TCP stack running. Check the destination computer to make sure it works properly.

• A network card with two network connectors uses a different type of network connector than the software. Adjust the hardware or software to use the proper connector.

• The network lacks one or more terminators. Install terminators at the ends of the network.

Printing problems

These happen for one of the following reasons:

• The network driver has not loaded. Under the Windows Setup program on the client, check the Network option to verify that the correct network driver has loaded.

• For Windows for Workgroups and Windows 3.1, the UNIX spooler misinterprets a PostScript file. When you print a PostScript file, your client sends a "CTRL-D" as the first character. The UNIX spooler, which cannot handle this, stops the print process and deletes the spool file. To correct this, add the following command to the client's Windows win.ini file under the section header [PostScript Printer,LPT1:]:

• CTRL-D=0:

• In some DOS applications, print jobs do not send until the user exits the program, because the PC buffers the print job and does not spool it until the application closes.