DIGITAL TCP/IP Services for OpenVMS
Management


Previous Contents Index

A.6.4 Inactivity Timer

The larger the inactivity timer, the longer FTP maintains sessions without timing out. Excessive inactive sessions might slow down performance, degrade security, or prevent other users from establishing sessions.

To increase the inactivity timer, change the value of the TCPIP$FTPD_IDLETIMEOUT logical name (default is 15 minutes).

Example:


$ DEFINE TCPIP$FTPD_IDLETIMEOUT 600

A.7 Printing: LPD

For LPD troubleshooting, use the following tools:

A.7.1 TCPIP$LPD_DEBUG and TCPIP$LPD_RCV Logical Names

The TCPIP$LPD_DEBUG and TCPIP$LPD_RCV logical names are independent, as follows:

To define TCPIP$LPD_DEBUG and TCPIP$LPD_RCV, enter:


$ DEFINE /SYSTEM LPD_RCV 7
 
$ DEFINE /SYSTEM LPD_DEBUG 7

If you have problems, turn on all the LPR/LPD diagnostics. Define TCPIP$LPD_DEBUG and TCPIP$LPD_RCV as 15. However, leaving these diagnostics on during normal use might impact the performance of LPD and produce large log files.

TCPIP$LPD_DEBUG and TCPIP$LPD_RCV are bit-mapped values. The low-order three bits turn on all diagnostics generated by either the sender or the receiver.

If you set the fourth bit, the LPD symbiont logs each buffer that it sends over the TCP/IP link, and the LPD receiver logs each buffer that it receives from the TCP/IP link. The log files let you see exactly what the LPD is sending (for outbound jobs) and receiving (for inbound jobs).

To set the fourth bit, enter:


$ DEFINE /SYSTEM LPD_RCV 8
 
$ DEFINE /SYSTEM LPD_DEBUG 8

A.8 Printing: TELNETSYM

To avoid potential problems with TELNET printing, be aware of the following situations and guidelines.

A.8.1 Using TCPIP$TELNETSYM for the First Time

If you use the public domain TELNET symbiont and want to switch to the TELNET symbiont, remember to change the value of /PROCESSOR on the TELNET symbiont queues. When you do this, include any command procedures that start up the queues. Change:


/PROCESSOR=TELNETSYM 

to:


/PROCESSOR=TCPIP$TELNETSYM 

A.8.2 Printing to DIGITAL Terminal Servers

When you print to a DECserver system, ensure that:

A.8.3 Stalled Print Queues

When you print a job to a TELNETSYM queue, a link must be established between the queue and the printer. If there is high contention for the printer, it might be busy, causing the first attempt at link-establishment to fail.

TELNETSYM continues to try to establish the link, according to the retry interval logical name TCPIP$TELNETSYM_RETRY_INTERVAL. Until the link is established, the execution queue stalls. When the link comes up, the job prints. A "stalled" TELNETSYM queue is not necessarily an error.

If the queue stalls while printing a job, the printer is probably out of paper.

If TELNETSYM causes a print queue to fail, reset the queue. Enter the following command:


$ STOP /QUEUE /RESET queue_name

A.8.4 TELNETSYM Logging

OPCOM messages sent by TELNETSYM include the name of the execution queue. In addition, each TELNETSYM queue has a log file named TCPIP$TELNETSYM_qname.LOG.

If you define the logical name TCPIP$TELNETSYM_SCRATCH, the log files are stored in the TCPIP$TELNETSYM_SCRATCH directory.

If you do not define TCPIP$TELNETSYM_SCRATCH, the log files go into TCPIP$LPD_SPOOL.

If TCPIP$LPD_SPOOL is not defined, the log files go into SYS$SPECIFIC:[SYSEXE].

A.8.5 Format Problems

To track down problems with wrong formatting on the printed page (for example, "garbage" for a graphics file or unwanted blank pages), use Bit 2 of the the TELNETSYM logical name TCPIP$TELNETSYM_DEBUG. Defining TCPIP$TELNETSYM_DEBUG helps determine whether the source of the problem is TELNETSYM. Follow these steps:

  1. Define TCPIP$TELNETSYM_DEBUG as 4 in the system table. Enter:


    $ DEFINE /SYSTEM TCPIP$TELNETSYM_DEBUG 4           
    $ STOP /QUEUE /RESET TELNETSYM_qname 
    $ START /QUEUE TELNETSYM_qname       
    

  2. Print the job that does not print properly.
  3. Look at the TELNETSYM log file for the queue.
    This file has messages that show you every byte sent over the link to the printer, such as control characters and setup/reset modules.
    If the raw TCP logical name is not defined, you see doubled IAC characters (hexadecimal FF).
    If you print /PASSALL with the raw TCP logical name not defined, the job starts with the TELNET options negotiation sequence "do binary, will binary".
  4. Identify the problem. Either fix it or report it to your DIGITAL support representative.
  5. Start the TELNETSYM queue.

A.8.6 Buffer Dumps

TELNETSYM logs control characters and nonprinting characters by preceding the hexadecimal value of the byte with a backslash. For example, this sequence:


Carriage Control 
Form Feed 
Carriage Control 
Line Feed 
Tab 
the text "Use Your Screen Saver to Conserve Energy." 
Carriage Return 
Line Feed 

is logged as:


\0D\0C\0D\0A\09Use Your Screen Saver to Conserve Energy.\0D\0A 

The "do binary, will binary" sequence starting off a /PASSALL job appears as:

\FF\FD\00\FF\FB\00

A.9 PPP

To troubleshoot PPP problems, check the configuration against the following criteria:

A.10 SLIP

To debug SLIP problems, use the following methods:

A.11 SMTP

To narrow down the cause of an SMTP problem, follow these steps:

  1. Check the directory SYS$SPECIFIC:[TCPIP_SMTP] for the following log files:
    Purge this directory regularly.
  2. Use the logical name TCPIP$SMTP_LOG_LEVEL debugging tool to define one of the following values:
    Value Description
    0 or undefined No logging
    1 Log daily activities (similar to UNIX sendmail)
    2 Log relevant headers
    5 Log full debugging messages (same as smb_debug)
  3. Check the mail in the TCPIP_SMTP account.
    Lost mail is delivered to the Postmaster's mailbox (TCPIP_SMTP). Forward SMTP mail to the SYSTEM account for monitoring. By default, there is no remote login allowed into TCPIP_SMTP.
  4. Check the directory SYS$SPECIFIC:[TCPIP_SMTP] for lost mail.
    If a mail message was undeliverable, and the error message was also undeliverable, an SMTP temporary file is placed in this directory, not in the queue.
  5. Check the consistency of the SMTP queues against the directories with the SMTP utility files.
    Enter the ANALYZE MAIL command (see Section A.11.1).

A.11.1 Verifying SMTP Control Files

The ANALYZE MAIL command verifies the consistency of the SMTP queues with SMTP control files. ANALYZE MAIL does the following:

Example 1:
This command encounters a problem, displays a description and solution, and then requests confirmation before fixing each record.


TCPIP> ANALYZE MAIL /REPAIR /CONFIRM
 
%TCPIP-E-ANA_SUP_BADIICGSIZE, Problem: Bad initial inode cell 
group size: bad_value
Solution: Will be replaced by 
default size: good_value
        CONFIRM [Y/N/G]: 

Example 2:
This command creates a summary of SMTP entries and control files for user DRAKE.


TCPIP> ANALYZE MAIL DRAKE
 
%TCPIP-I-ANA_RUNING, ANALYZE runs on node DODO 
 
%TCPIP-I-ANA_NOENTR, no queue entry found for file 
NEST3$:[DRAKE]93042311394417_DRAKE.UCX_DODO;1 
 
%TCPIP-I-ANA_COMPLE, ANALYZE completed on node DODO 
 
%TCPIP-I-ANA_FEPAIR, found 0 file-queue entry pairs 
%TCPIP-I-ANA_DELQEN, deleted 0 queue entries 
%TCPIP-I-ANA_FILNOQ, found 1 files with no queue entries 
%TCPIP-I-ANA_FILHLD, holding 0 files in directory 
%TCPIP-I-ANA_FILDEL, deleted 0 files from the Postmaster directory 
%TCPIP-I-ANA_SUBFIL, submitted 0 files to the generic queue 
%TCPIP-I-ANA_FILACE, encountered 0 file access errors 
%TCPIP-I-ANA_NONCFF, found 0 non-unknown files in Postmaster directory 
%TCPIP-I-ANA_FILCOR, found 0 corrupted CF files in Postmaster directory 

Example 3:
This command:


TCPIP> ANALYZE MAIL DRAKE /REPAIR /DELETE=BEFORE=24-NOV-1997

A.12 SNMP

To make sure that SNMP functions correctly on your system, follow the guidelines in this section.

A.12.1 Guidelines for Enabling Set Commands

To ensure that the master agent processes SNMP set commands from SNMP clients correctly:

If SNMP is not responding to set commands or to other requests:

A.12.2 Entering the SET CONFIGURATION SNMP Command

When you enter the SET CONFIGURATION SNMP command and qualifiers, take the following information into consideration:

A.12.3 Error Messages Returned by the MIB Browser

The SNMP MIB browser supplied with TCP/IP Services returns the following error messages. You might see other messages, depending on your configuration or related network operation.

Invalid host argument: agent,

Explanation: The host name is not located in the namespace or the syntax is incorrect. Note that if TCP/IP Services is not running, this error message returns for valid host names as well.
User Action: Enter the command again and confirm that the host name you specified for the agent parameter is valid and spelled correctly. Confirm that TCP/IP Services is running.
Invalid operation,

Explanation: The request_type parameter is not a valid SNMP command.
User Action: Enter the command again and make sure the request_type parameter you specify is one of the valid SNMP commands: get, getnext, getbulk, or set. Note that the SNMP Version 2 request type inform is not implemented in TCP/IP Services.
Invalid wait_seconds_max argument: 0,

Explanation: The value specified with the -w option is invalid.
User Action: Enter the command again and make sure you specify a value for the -w option that is greater than 0.
Invalid max_repetitions argument: 0,

Explanation: The value specified with the -m option is invalid.
User Action: Enter the command again and make sure you specify a value for the -m option that is greater than 0.
Invalid port argument: 0,

Explanation: The value specified with the -p option is invalid.
User Action: Enter the command again and make sure you specify a port number for the -p option that is greater than 0.
Invalid version argument: 0,

Explanation: The value specified with the -v option is invalid.
User Action: Enter the command again and make sure you specify one of the two valid values for the -v option: 2c or 1.
Invalid variable list,

Explanation: The values specified are not in the correct OID format.
User Action: Enter the command again and make sure you specify a valid OID for the OID value. Note that you can specify only one OID for a MIB-walk.

A.13 Troubleshooting POP

The following sections describe ways to troubleshoot problems associated with using the POP server. Some of these include:

A.13.1 Reviewing POP Server Messages

Many of the problems encountered using POP pertain to failed or misinterpreted commands or authorization errors. Therefore, you should review the messages provided by the POP server as the first step toward solving problems.

The POP server logs command error and OPCOM (authorization) messages. By default, the POP server sends informative error messages to the client about specific errors. If the SERVICE database log option REJECT is set, the POP server sends OPCOM messages when it rejects POP client commands due to authorization failures. These errors include the receipt of a client's USER command with an invalid user name or a PASS command with an invalid password.

By default, OPCOM messages are displayed on the client system and are listed in the log file. To disable OPCOM messages, disable the REJECT logging option for the POP service as follows:


$ TCPIP SET SERVICE POP/LOG=NOREJECT 


Previous Next Contents Index