Monitoring target servers

The Communication Server SMTP (CSSMTP) application automatically monitors the target servers for certain failures when the application is unable to communicate with the servers. Console messages (messages EZD1817I, EZD1818I, and EZD1819I) are generated for each target server. In some cases, the target servers can communicate with the CSSMTP application but the target servers cannot accept the mail message due to temporary error conditions. For temporary error conditions, the target servers pass the reply code 4xx. See RFC 2821 for more information about reply code processing. See Related protocol specifications for information about how to access RFCs.

To understand and handle the temporary error conditions, perform the following steps:
  1. Determine how the CSSMTP application handles temporary error conditions.
    Two configuration statements control how CSSMTP handles temporary error conditions:
    RetryLimit
    Mail messages are saved in memory and wait to be retried. The JES spool data set is held and waits for mail messages to be sent or failed permanently. This state is called long retry.
    ExtendedRetry
    Mail messages are saved in the z/OS® UNIX file system and wait to be retried. The JES spool data is deleted if there are no other errors to report in the spool data set. This state is called extended retry.
    Use the MODIFY DISPLAY,CONFIG command to determine the current value of these statements.
  2. Monitor whether temporary errors are occurring. Use the MODIFY DISPLAY,TARgets command to determine the number of mail messages currently in retry processing and check the following cases:
    • Check whether the number is increasing or is high under the GLOBAL INFORMATION: CURRENT RETRY label for mail messages in long retry.
    • Check whether the number is increasing or is high under the EXTENDED RETRY: CURRENT label for mail messages in extended retry.
  3. Use traces to determine the temporary errors. The target servers must be available.
    1. Issue the MODIFY LOGlevel,LEVEL=logLevel command. Set the logLevel value to the current level plus 32, which is the value at which message-level TCP/IP messages are logged. This command traces the CSSMTP commands and remote SMTP target server replies between CSSMTP and the TCP/IP network.
    2. Look for the remote SMTP server replies that contain any of the following information:
      • A reply code that begins with of the number 4, for example, 450.
      • A reply message that indicates a timeout with the servers.
    If mail messages are not being sent when traces are activated, you can force the mail messages off the retry queues and return to the active queue.
    • For mail messages in long retry, use the MODIFY FLUSHRetry,TKID=tkid command, where tkid is the task ID associated with the JES spool data set.
    • For mail messages in extended retry, use the MODIFY FLUSHRetry,AGE=days command.
  4. Handle the temporary error conditions.
    • If the target server is short of resources such as memory or space, take one of the following actions:
      • Add resources to existing target servers.
      • Add a target server that has extra resources to the target server list in CSSMTP configuration file. The maximum number of possible target servers is four. Use the MODIFY REFRESH command to make the CSSMTP application update the target server list.
    • If the recipient's mailbox is full, take corrective actions at the target server where the mailbox is located.
    • If timeout errors occur during the communication between CSSMTP and target servers, check the configured timeout values in the CSSMTP configuration file and the configured timeout values at the target servers, and increase the values.
Parent topic: Diagnosing Communications Server SMTP application problems