status (F,6) provides the return code. 0=success, else error. Negative numbers represent system or network errors such as unable to connect, no route to host, etc. The string associated with the error will be returned in errmsg or output to the specified file. Positive numbers greater than 100 are the actual codes returned by the SMTP server with the remainder of the message returned in errmsg. Positive numbers between 71 and 99 are application or miscellaneous errors. The more common status values are defined in EMAILX.DEF (++include in your application) as shown below:
Symbol |
Value |
Type |
Description |
|---|---|---|---|
EMS_OK |
0 |
B,1 |
Ok |
EMS_TOOFEW |
71 |
B,1 |
Too few parameters |
EMS_TIMEOUT |
72 |
B,1 |
Timed out |
EMS_NOTO |
73 |
B,1 |
No to address |
EMS_NOBODY |
74 |
B,1 |
No body text |
EMS_BADRESP |
75 |
B,1 |
Bad SMTP response |
EMS_NOSOCKET |
76 |
B,1 |
No socket open |
EMS_NOCFG |
77 |
B,1 |
Specified CFG file not present |
EMS_BADCFG |
78 |
B,1 |
Syntax error within CFGFILE |
EMS_BADSIG |
79 |
B,1 |
Bad signature file |
EMS_BADATT |
80 |
B,1 |
Bad (empty or missing) attachment |
EMS_B64ERR |
81 |
B,1 |
Base64 encoding error |
Definition file: emailx.def |
|||
Values 1-70 would indicate ASB error conditions. Consult sys:errmsg.usa or use DERR to get the text message associated with the error number.
Error 80 (EMS_BADATT) indicates that the specified attached is missing or empty, not that its contents are somehow bad. A likely cause—other than the obvious bad filespec—is that you're creating the file immediately prior to emailing it as an attachment, and you either failed to close it, or the creation mechanism uses an external process (e.g. PDFX) that may be taking longer than expected. One debugging technique for verifying that the filespec is at least correct is to activate the FOPENS and XDEBUG TRACE flags prior to running your program, and then check the ashlog file.
Negative values represent system network errors. To get the error message associated with a negative value of STATUS, use XCALL TCPX, TCPOP_ERRMSG, STATUS, MESSAGE$, TCPFLAGS (where TCPFLAGS must contain TCPXFLG_TLS if either of the EMF_TLS or EMF_STARTTLS bits are set in opflags). Also see the ERRMSG parameter, which may contain a useful message, typically the last command sent to the server or last response from it.
Values in the range of 200-599 are SMTP reply codes. (The SMTP protocol consists of a series of command/requests, each of which receives a response beginning with one of these reply codes. When the code indicates a failure, EMAILX will abort and return that code in the status parameter.) You can get a more complete picture of the conversation between EMAILX and the SMTP server by examining the log file (see the LOGFILE and LOGLVL parameters in the configuration file). For a complete understanding of the theory and interpretation of the SMTP protocol, including the reply codes, consult the relevant RFCs, particularly RFC 5321. The log file may also show additional enhanced "status codes", typically presented in the form of x.x.x, which may provide more information about the nature of the problem. A simple web search for "SMTP reply codes" or "SMTP status codes" will help you locate a variety of websites with simplified lists of the codes (the RFC is thorough and academic, but not conducive to a quick look-up), as well as forum/support/blogs discussing typical SMTP problems. Because these issues are generally specific to the particular SMTP server or network, EMAILX can do little more than report the information returned from the SMTP server, and this documentation can do little more than provide this general advice before sending you off to the web for more troubleshooting.
