Instructions

UM-0085-B09 DT80 Range User Manual Page 226
RG
If the session is still OK then the problem must be either a problem with the FTP server, or the unload command is
incorrect (e.g. an invalid server name or credentials were specified). Either way, the DT80 will now retry the FTP transfer,
using a similar strategy to that for session retries. That is, it will wait for the configured
RETRY_DELAY_S time then
retry, with this time being multiplied by 60 on every third attempt.
By default, these retries will continue indefinitely. However, you can also set a retry limit, as follows:
PROFILE UNLOAD FTP_RETRIES=10
which will perform up to 10 retries, then delete the data file from the queue. Setting the profile to 0 means that only a
single attempt will be made (no retries), while
INFINITE will retry indefinitely.
Note: If a data file from an incremental unload (one which specified start=new) is abandoned, then the time period covered by the
failed unload will be missing from the data set on the FTP server, even if communications with the server subsequently recover. The
data for this time period will then need to be manually recovered, e.g. using the dEX web interface "retrieve data" function.
 How Many Retries?
To avoid having to manually recover data after a prolonged server outage, it is important to carefully consider the
FTP_RETRIES setting. The best setting depends on the application:
• If you have a simple job which does periodic incremental unloads to a single FTP server then the default
FTP_RETRIES=INFINITE is normally appropriate. If the server goes down then unload files won't be able to
be sent and will remain in the FTP queue indefinitely. If the queue fills up completely then when subsequent
unloads occur the resulting file will not
be able to be queued. In this case the "last record unloaded" pointer will
not
be updated so it will be as if the unload never happened. When the next scheduled unload occurs, the
resulting file will contain data for both the previous and current intervals. The bottom line is that, provided that
the main data storefile is large enough, there will be no gaps in the data on the server when it eventually
recovers.
• If your job outputs to multiple FTP servers, or there is a possibility that some FTP transfers could succeed while
others continue to fail, then a finite value for FTP_RETRIES is preferred. Otherwise, the FTP queue may
eventually fill up with requests for the bad server, which will prevent requests for the good server being
processed. (Note that a full FTP queue will not prevent emails or SMS messages being sent.)
Remember that if the logger loses its network connection for a period of time (as opposed to an FTP server outage) then
it will be the session
that is failing, not the FTP transfer. The FTP_RETRIES setting is therefore not relevant in this
case. The session will be retried indefinitely.
 File Transfer Process
When the DT80 sends a file to an FTP server, it will first create a temporary file on the server, which will have a .tmp file
extension. Once the transfer is complete, this will be renamed to the correct file name.
If a transfer fails half way (e.g. due to a mobile network drop out) then an incomplete file will be left on the server.
However, because such files have .tmp file extensions they will be easily distinguishable from complete files (which will
normally have a .csv or .dbd file extension).
If communications failures are frequent, a number of incomplete .tmp files may accumulate on the FTP server. Some
periodical FTP server housekeeping may be required, to delete old temporary files.
Email Failures
A email data unload, e.g.
COPYD dest=mailto:[e-mail]
may fail because of:
• a general configuration error, e.g. an incorrectly specified SMTP server name, username, password or return
email address in the profile settings
• an invalid destination email address in the
COPYD command
• a network problem, e.g. the modem's connection to the mobile network has dropped out.
• a transient server problem, e.g. the SMTP server may be temporarily overloaded
• the SMTP server is down
Note: The DT80 will consider that an email has successfully been sent if the message (and data file, if any) is accepted by the SMTP
server. However, acceptance by the SMTP server does not
mean that the message will necessarily make it to the recipient's email
inbox. This is simply the nature of email. For example, the user's inbox may be full, or the message may be blocked or mistakenly
interpreted as "spam" by a mail server or the user's email client. If a message is dropped in this way then a "bounce" message may be
sent to the configured return email address, although this is not guaranteed.
 Retries
The retry strategy for email is similar to that for FTP. If any error is detected during while connecting to the SMTP server
or during the transfer, the DT80 first determines whether the network is still functional. If the network has failed (e.g. the
modem has dropped out, or the DNS/ping network check fails) then this is a session failure and will be dealt with as
described in Session Failures (P224).