This chapter explains how to correct problems with the TAS system. It includes instructions for collecting diagnostic information for customer support engineers using trace and csr.tn, as well as a compilation of common error messages that users might see and instructions for resolving them. This chapter contains the following sections:
"General Troubleshooting" -- A systematic approach to isolating problems.
"Realm-Specific Error and Activity Logs" -- Information on generating records of errors and activity, at the realm level.
"Error Messages and Solutions" -- A list of error message with instructions for resolving them.
"Error Conditions and Solutions" -- Solutions to error conditions not necessarily accompanied by error messages.
"Contacting Technical Support" -- Information needed to receive comprehensive technical assistance.
You can resolve many problems that occur in the TAS system if you start from the simplest possible causes for an error and work towards the more complex. Such a systematic approach helps you develop a theory, test it, and isolate and correct the problem.
The list of questions below provides a starting point for resolving problems this way. They address the following categories:
To make sure that the server recognizes the user name, attempt to open a telnet session from the client, with that user name.
If you can perform the process from UNIX, you may have incorrect attach point configuration or client connection--but keep in mind that you cannot replicate all actions performed from a PC, on UNIX. Open a telnet session and try the process from UNIX. For example, if you have printing problems, telnet to the server and use the lpr command to send a file to the printer. If the action works under UNIX, check the client and server configurations from the TotalAdmin sphere.
Check this using another program. For example, to check the TCP/IP configuration, use ping from UNIX.
If they do, the client cannot connect to the server because this protocol setup only works within the subnet. You must have NetBIOS-over-TCP/IP to connect a client and server on different subnets. NetBIOS-over-NetBEUI does not route.
In order for a client to find a NetBIOS name on the other side of a router, it must have the ability to map an IP address to that NetBIOS name. You can accomplish this by using static tables, Windows Internet Naming Service (WINS), or Enterprise Name Server (ENS) to configure the client to resolve the service name to its associated IP address.
Some older client software does not use the extended SMB protocol in the same way as the server. Follow these links:
LM-NT-OS/2 Realm->Manage File Services->[select the service]->Administer->Configuration
For SMB dialect, select core.
To force the client to revert to the core protocol from the UNIX command line, use this command:
tnservice -M -r NB -s servicename -a smb-protocol-level=on |
For the server network interface, make sure that you have configured the correct frame type and associated it with the correct hexadecimal NetWare network number. To find out the correct rame type/network number combination, look at Novell server configurations or run ipxprobe after shutting down IPXd. If your network does not contain a Novell server, you can use any hexadecimal number unique for the frame type.
TotalNET IPX supports full routing, which means that you can configure it to use more than one network interface, and it supports multiple frame types on each interface. TAS treats a single physical network as a collection of distinct logical networks using distinct interface frame types and performs routing among the logical networks just as it does their physical networks, so each frame type on the system must associate with a different net number.
You can configure each interface for a number of frame types with corresponding network numbers. For instance, interface_1 might have frametype_x with netnumber_x and frametype_y with netnumber_y, and interface_2 might have frametype_x with netnumber_x and and frametype_z with netnumber_z. You must use a unique net number for the internal frame type in the NetWare realm. Never delete the internal frame type.
Follow these links:
Transports->IPX/SPX Interfaces->[select the IPX/SPX interface]->Modify
To check frame types and network numbers from the UNIX command line, use the command
tniface -R -n tnipx |
To view all of the NetWare servers currently active on the network, access Network Neighborhood or, in DOS, use the slist command. If the NetWare server you need does not appear on the slist list, advertisements from the server do not reach your client. You may have a disabled server or a problem with Service Advertisement Protocol (SAP) advertisements. To see if you enabled your server, click Status at a Glance.
If you suspect a problem with SAP advertisements, contact a Technical Support engineer for further assistance. Before contacting Syntax, see "Contacting Technical Support".
Different versions of login programs used by NetWare vary greatly. For example, if you wish to use Novell 3.12 utilities to connect to a NetWare realm service, you must turn on secure authentication for that service, since the 3.12 utilities only send encrypted passwords. You do not need to turn on secure authentication for clients of versions later than 3.12, however, because they can send clear-text passwords.
Syntax provides login utilities for the NetWare realm in $TNHOME/NW/sys/login. They provide similar functionality to programs used by NetWare. To turn on secure authentication, follow these links:
NetWare Realm->Manage File Services->[select the service] ->Administer->Authentication and Service Mode Options ->Local authentication->Submit
Select the Password encryption option.
To configure secure authentication from the UNIX command line, use the tnservice command.
UNIX stores Macintosh files in three forks: the data fork, the resource fork, and the finder information fork. The data fork contains the actual data contained in the file, the resource fork indicates the application to launch when you open the file, and the finder information fork maintains data about the file's creator, type, location on the desktop, and icon.
TAS stores these parts in separate directories. When you create a file from a Macintosh client, TAS writes the data fork writes to the current directory, the resource fork to the subdirectory .tnatr:reso-fork, and the finder information to the file .tnatr:intf. If TAS cannot locate all of these pieces, the file may not launch correctly. In versions of TAS previous to 5.x, TAS writes the data fork to the current directory, the resource fork to the .resource directory and the finder information to the .finderinfo directory.
The finder maintains information about files, such as the file's creator, type, location on the desktop, and icon. When the server cannot locate finder information, it attempts to generate reasonable default values for this information based on data in the map file. These values may not contain the correct information.
An AppleTalk map associates file suffixes with Macintosh applications. The client operating system uses these associations to determine which application it should invoke when it accesses a file.
Follow these links to check mapping configuration:
AppleTalk Realm->Suffixes for AppleTalk Map->[select a suffix]->Modify
The Modify button does not appear if no maps exist.
To check mapping configuration from the UNIX command line, use the tnsuffix command.
Occasionally, these platforms cannot share files of the same program.
TAS generates a number of logs that you can use to monitor and manage the TAS system. Within each realm, a log generates during startup, and error messages sent within the realm append to the log as they occur.
You can enable an activity log that records information about all connections to file services; do so by enabling the Log activity attribute when you configure a file service. This attribute applies per service. The report generated by csr.tn or by clicking Generate Support Info includes the activity log.
Realm error logs reside in each realm's folder. The NetWare realm's log resides in $TNHOME/NW/log, the LM-NT-OS/2 realm's log resides in $TNHOME/NB/log, and the AppleTalk realm's log resides in $TNHOME/AT/log. These logs provide startup information for the realm and error messages generated during startup in a common log format. If a client cannot connect to a service in a particular realm, you can check the log for that realm for TAS startup errors.
To access such a log from TotalAdmin, follow these links:
realm->View realm Log File
To maintain a log of connection activity for a realm, you must enable the activity attribute on each relevant file service. This attribute applies per service. The activity log file activity.tn then registers the following statistics whenever service terminates in the realm:
UNIX account name
server machine name
server start time
file service realm
client machine name
client network address
number of transactions requested
number of kilobytes read
number of kilobytes written
number of kilobytes printed
total connection time
To cause an activity log to generate each time a client connects to the server, follow these steps:
Follow these links:
realm->Manage File Services->[select service]->Administer->Configuration
Select the Log activity option.
To enable activity logs from the UNIX command line, open a telnet session to the server and use the following command:
./tnservice -M -r NB -s service -a activity=on
This section provides solutions to error conditions accompanied by error messages.
The chart below details the exit codes that appear as tn-utilities error messages. The rest of this section lists causes and solutions for other common error messages.
0 |
Success |
1 |
Usage |
2 |
Incompatibility |
3 |
Invalid command line |
4 |
General memory allocation |
5 |
Disabled system |
6 |
Invalid realm, system, or service |
7 |
Application Interface error |
8 |
System call failure |
9 |
C library failure |
10 |
Invalid characters in volume, for specified realm |
11 |
Invalid characters in service, for specified realm |
12 |
Service name too long for specified realm |
13 |
Denied permission; superuser access only |
The user does not have privileges to either read a file, write a file, execute a program, or search a directory.
The NetWare-compatible client cannot access a UNIX directory. Verify that the directory has the execute permission bit set and resides below the virtual root of the volume.
The Windows interface on the network has one of these problems:
The correct driver has not loaded. Under the Windows Setup program on the client, check the Network option and verify that the correct network driver has loaded. For example, for a Microsoft-compatible client, the words Microsoft Network should appear. If they do not, click Change System Settings on the Options menu, then select the correct driver from the list under Network.
The drive connected using the Windows file manager and the existing file manager saved the settings. The user chose, under Windows Control Panel->Networks, to restore all connections at startup, and consequently used the drive letter for DOS to make a different redirection.
The system socket call failed on TAS startup for one of the following reasons:
You did not shut down NetBIOS. If the UNIX operating system contains NetBIOS, shut it down before starting TAS.
The system has used all of its sockets.
Another process has claimed one of the reserved NetBIOS ports.
The server uses the UNIX operating system to authenticate users, so the user account must exist on the UNIX host before you can log in. A Novell server's system administrator defaults to supervisor; the UNIX equivalent defaults to root. Typically, you must log in as root to administer the UNIX operating system.
The server has not validated the user's name or password. Make sure the name and password fulfill the following requirements:
Correct spelling.
Correct format for upper-case characters. A tilde (~) must precede each one.
Satisfaction of the following system limitations:
NetBIOS has a 14-character maximum.
NetWare has a 30-character maximum with TAS.
AppleTalk has an 8-character maximum.
Users with account names or passwords longer than eight characters may have difficulty making connections. On many UNIX systems, only the first eight characters of the password matter, so you may establish a connection by providing only the first eight characters of the password.
On systems with password aging supported and enabled, the password may have lost validity. Have the user log in to the UNIX host at the console or with a terminal emulator such as telnet and update the password.
The user name lists as restricted. Follow these links:
realm->Manage File Services->[select the file service] ->Administer->Authentication and Service Mode Options
If you chose the LM-NT-OS/2 or NetWare realm, choose the authentication type. In the screen that appears, check User restrictions. If the user name does not appear in the Users field with Allow selected, enter it. If the name appears in the Users field with Deny selected, delete it.
The name discovery phase succeeded, but the system rejected the connection request, for one of the following reasons:
The user made a connection attempt to a TAS host immediately after the user's previous connection terminated ungracefully, such as by client PC reboot, and the connection definition file still exists. Run tnck.
A user attempted to connect to a service with an invalid command in its service definition file.
You caused TAS to reject new connection attempts. Follow these links to make TAS accept connections:
System->System Administration->Accept Service Connections->OK
To accept services from the UNIX command line, use the tnaccept command.
TAS has reached its user limit. Multiple connections from a single client to the same service name count as a single user, but each connection to a new service name, even if it comes from the same client, counts as a separate user. Contact your Sun Microsystems sales representative to purchase additional licenses.
The time limit on your evaluation copy of TAS has expired.
The output of tninfo shows a connection that does not exist. The tninfo report normally shows only one connection per Ethernet address. Occasionally, a duplicate may list when the server has not yet recognized a connection termination. An ungraceful disconnection by the client, as when the client turns off the PC or reboots without logging out, usually causes this.
To detect dead connections, enable the keepalive function for the LM-NT-OS/2 and NetWare realms. This tells the server to send keepalive packets, similar to Novell watchdog packets, to determine whether clients remain attached. After sending the first keepalive packet, the server sends another packet every minute for 10 minutes. If it receives no response during this time, the server assumes that the connection died and updates the connection database accordingly. The client no longer lists in the tninfo report.
Follow these links to enable keepalives:
realm->Manage File Services->[select the service]->Administer->Configuration
For Keepalive, enter the number of minutes you want to have between dispatches of keepalive packets.
To enable keepalives from the UNIX command line, use the following command, where n represents the number of minutes for the server to wait after a connection establishes before sending the first keepalive packet:
tnservice -M -r NW -s nwhera:file -a keepalive=n |
A problem exists with the drive letter in a client command. This can occur when a client attempts to redirect a local drive, such as a diskette drive or a hard drive partition.
The user has attempted to redirect either a drive to a print device or a printer port to a directory.
The client did not receive a response from a server when it broadcast a request for a NetBIOS name, for one of the following reasons:
The user supplied an invalid service name when attempting to connect to a TAS host. Follow these links or use the tnstat command to make sure the service status contains the correct service name: LM-NT-OS/2 Realm->Configuration and Control-> LM-NT-OS/2 Realm Status.
When a client attempted to connect to a TAS host, the named service did not run. Follow the links LM-NT-OS/2 Realm->Configuration and Control->LM-NT-OS/2 Realm Status or use the tnstat command to see if the service status runs. If it does not run, restart LM-NT-OS/2 services by following "5.1.2 Shutting Down LM-NT-OS/2 Services", then "5.1.1 Starting LM-NT-OS/2 Services".
The user misspelled the server name. Use tnservice -l or check the service configuration at LM-NT-OS/2 Realm->Manage File Services->[select the service]->Administer->Configuration to verify the spelling.
The system has reached its NetBIOS session limit. Check the initialization file of the client protocol software to verify that the system allows sufficient NetBIOS sessions.
The server cannot run NetBIOS.
The NBname daemon does not run. NBname exits if it detects another network node with the same NetBIOS name. TAS then ignores name requests. Check the NetBIOS error log $TNHOME/NB/log on the host for an error message. Change the NetBIOS name, if necessary, and restart TAS as described in "4.1.2 Shutting Down TAS Services", then "4.1.1 Starting TAS Services", or with the tnshut and tnstart commands.
The server and client reside on different networks--they reside on different sides of a router or a bridge--and NetBIOS broadcasts do not propagate. Use the TAS Enterprise Name Server (ENS) as described in "6.1 Modifying TCP/IP Configuration" or by using the tntransport command. Alternatively, you could configure routers to propagate broadcasts using a p-node NetBIOS setup, but this substantially increases network traffic and lowers network capacity.
IP addresses have incorrect formats or content. Check the IP addresses with the tniface command or by following these links: Transports ->TCP/IP Addresses. On the server, you can find an IP address using the ifconfig command. The address should have four segments separated by periods, as in the following example, where A, B, C, and D represent sets of decimal numbers:
A.B.C.D
Determine the address with this table:
If A is: |
the network number is: |
---|---|
< 128 |
A |
128 - 191 |
A.B |
> 191 |
A.B.C |
The network mask for the client does not match that for the server. This table gives the default network masks for IP addresses:
If A is: |
the network mask is: |
---|---|
< 128 |
255.0.0.0 |
128 - 191 |
255.255.0.0 |
> 191 |
255.255.255.0 |
The broadcast addresses cannot work together. The original TCP/IP did not define a way to broadcast packets on the Internet. When this became desirable, enterprising corporations developed several different mechanisms, not all of which interoperate. To try a different broadcast style on the PC, see the client TCP/IP documentation.
In a PC's net.cfg file, you can list several frame types to use over the network card. The network uses only the first entry when transmitting packets. If a server host does not have the configuration to use the same type of frame as the client, the client cannot see that server; the server does not list from the slist utility or on the Windows NetWare interface.
This problem may occur with an inactive NBdaemon process. Follow the links LM-NT-OS/2 Realm->Configuration and Control->LM-NT-OS/2 Realm Status or use the tnstat command to verify that you started TAS. If you have not, follow "4.1.1 Starting TAS Services" or use the tnstart command.
NetWare servers broadcast routing information every 60 seconds using the Routing Information Protocol (RIP), and they broadcast service information every thirty seconds using the Service Advertising Protocol (SAP). On a very large internetwork or wide-area network, the RIP or SAP database can grow so large that the time necessary to download it exceeds the interval between downloads, especially if you have a low-speed WAN link. This can cause the apparent disappearance of volumes, printers, or servers or extreme delays in packet re-routing, if a node fails.
Novell will replace RIP and SAP with NetWare Link State Protocol (NLSP). NLSP associates multiple network interfaces with a single network number, distributing traffic across multiple network segments. If a node fails, NLSP can quickly establish an alternate path. NLSP builds a map of the network incrementally and sends updates only as needed. NetWare 3.11, 3.12, 4.11, and 4.12 servers support NLSP. They can still work with existing SAP/RIP servers.
The name-discovery phase succeeded, but the system cannot find the requested resource on the server, for one of the following reasons:
A user attempted a connection to a TAS host with an invalid UNIX name. Verify the validity of the user name at realm->realm Connected Users->Connection Information. Check the spelling and case. Make sure a tilde (~) precedes each upper-case character.
You set the NetBIOS naming scope incorrectly. The naming scope must match the one designated by NetBIOS Name scope at Transports->TCP/IP NetBIOS Configuration. You may also check it with the tntransport command. NetBIOS Name scope also defaults to no naming scope. If you do not set the NetBIOS Name scope attribute, TAS ignores the client's naming scope.
When a user attempted a connection to a TAS host, an attach point defined in TAS's configuration of .profile.file in the user's home directory matched a UNIX user name or directory. Change the name of the attach point at realm->Manage File Services->[select the service]->Administer->Attach Points or with the tnattach command and retry the connection.
The user attempted connection to a directory with a user limit, and the directory has reached its limit. Try again later.
A user attempted to establish a print service connection to a nonexistent printer. Verify that either the server configuration contains a reference to the printer, at realm->Manage File Services->[select the service]->Administer->Configuration->Printer references or with the tnservice command, or the user's .profile.file contains a prdefault or printer command for the requested printer.
An attempted extended connection contains a path to a nonexistent directory. Verify the directory exists and try again. Stop and restart TAS if you modify the directory configuration by following "4.1.2 Shutting Down TAS Services", then "4.1.1 Starting TAS Services", or with the tnshut and tnstart commands.
The user has attempted to exceed the number of connections allowed by the client computer's network operating system, NetBIOS, or TCP/IP. Update nb_sessions, tcp_sockets, or udp_sockets entries in the net.cfg file to allow more redirections. If you do not want to allow more redirections, cancel a redirection, then try again.
The age of the network card driver exceeds the age of the physical network board. Replace the board interface software with a newer version.
This section provides solutions to several error conditions not necessarily accompanied by error messages.
A TAS authentication error occurs when a user runs Windows NT 4.0 client with Service Pack 3 (SP3) installed, or Windows 98. If the user attempts to browse a TAS server for shared volumes, or to connect to a TAS volume, the following TAS error message is displayed:
Incorrect password or unknown username for \\serverName. |
This error occurs even if the user enters a valid UNIX username and password.
By default, Windows NT 4.0 SP3 and Windows 98 clients use secure authentication. The PC and the TAS server engage in a "challenge/response" exchange, which ensures that they agree on the validity of a password, without sending the actual password over the wire.
The client uses the password to encode a nonsense string (supplied by the server). The client then returns the encoded string to the server. The server performs a similar encoding and, if the nonsense strings match, authenticates the client.
To support this authentication scheme, TAS must maintain a private password file, distinct from the UNIX password file. To enable authentication, you must populate the TAS private password file with UNIX user names and passwords.
Complete these steps to enable secure TAS authentication and eliminate this error:
Click the TNAS TAS Administration and Configuration sphere icon to display TAS administration and configuration options.
Click LM-NT-OS/2 Realm.
In the LM-NT-OS/2 Realm panel, click: Manage File Services->
Select the file service you want to manage and click Administer.
On the resulting screen, click Authentication and Service Mode Options.
Enable Local authentication and click Submit.
Enable Password encryption and click Submit.
Click OK.
To establish entries in the TAS private password file, click these links in the TAS frame:
Passwords->type in the UNIX user name->Create
A user must have a valid UNIX account for you to enter the name into the TAS password file.
In the resulting form, enter and renter the user's password and click Submit. This user will now be authenticated correctly.
Repeat steps 7-9 for each UNIX user requiring TAS authentication.
Solaris printers appear available to TAS clients. Printers can be mounted and print jobs seem to spool to Solaris printers correctly. However, jobs are never printed.
In order for TAS PC client to print to a Solaris printer, TAS configuration must be modified as follows:
In the TNAS Main Menu (Left Frame), click System.
In the System Configuration and Administration Menu (Right Frame), click Printers.
Select the Solaris printer to update and click Modify.
Enter -c in the Spooler Options box, and click Submit.
Jobs will now print successfully on the Solaris printer.
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 permissions, at realm->Manage File Services ->[select the service]->Administer->Configuration->Umask or 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.
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
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.
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 at realm ->Manage File Services->[select the service]->Administer ->Configuration or with the tnservice command.
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.
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.
Files do not properly lock or unlock because the client PC rebooted and file locks did not clear. Run tnck to clear the locks.
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.
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 follow "4.1.1 Starting TAS Services" or use the tnstart command.
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.
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.
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.
Contact your local Sun Technical Support Center. Sun Technical Support Centers are listed at: http://www.sun.com/services/contacting/solution.html. Before contacting technical support, please have the following information ready:
your Sun Spectrum contract or ID number
your version of TAS
your UNIX version
the type of machine on which you installed TAS
circumstances leading to the problem, including other operating systems, software, and hardware involved
Any error messages displayed or logged