Auto Resend
If a network-related error or a forced stop due to a failover occurs during a file transfer, HULFT can carry out resending automatically. At the time of an unsuccessful transfer, it is possible to transfer the data from the point where the error occurred (Checkpoint Resend File) by carrying out resending.
Flow of auto resending
The flow of auto resending is illustrated in Figure 2.7 .
1) Starting up the Send process
The Send daemon starts the Send process.
2) Connecting to the Receive process
The Send process connects to the Receive process and then transfers the file. If the Send process cannot connect to the Receive daemon, it repeats the connection process the number of times specified in Connect Retry Count (retrycnt) in the System Environment Settings.
3) Communication error or occurrence of failover on the receiving side
If an error occurs somewhere along the communication line during file transfer, or if a forced stop occurs due to a failover, the Send process detects an error and discontinues the processing.
4) Writing the result to the Send Log file and starting up the Post-send Job
The Send process writes the result on the communication error (failure) to the Send Log file (hulsndlog.db), and starts the job that has been registered as an unsuccessful job.
5) Auto Resend
If an error occurs in 3) , the Send process waits for the duration that is specified for Connect Retry Interval (retrytime) in the System Environment Settings. Then, it repeats steps 2) - 4) the number of times that is specified for Auto Resend Retry Count (sockerr_autoretry) in the System Environment Settings.
6) Sending notification of the send result
The Send process notifies the Send daemon of the send result.
7) Registering the information for resending
The Send daemon writes the information on the transfer in the Send Control file (sddsendlist.dat) when the send result that was received from the Send process is unsuccessful.
-
By executing the Resend File command (utlsend), you can manually carry out resending for records that are written in the Send Control file.
-
If a communication error occurs in 3) , the Receive daemon ends the Receive process on the receiving side which terminates the transfer. The Receive process is generated again when reconnected to from the sending side process for auto resending.
Auto Resend Error Code
HULFT carries out auto resending for the following error codes:
Error codes when a communication error occurs
If a communication error occurs during sending, one of the following detail codes is recorded in the Send Log:
- 208:
-
Reading of the communication socket failed.
- 212:
-
Writing of the communication socket failed.
Error codes when a failover occurs on the receiving host and the host is forcibly stopped
If a failover occurs on the host on the receiving side, one of the following error codes is recorded in the Send Log:
- 250-591
-
- 250:
-
Status code of the Send process (server error)
- 591:
-
Status code of the host on the receiving side indicating that the host was forcibly stopped
For details, refer to the following for the host type on the receiving side:
HULFT10 for Linux/AIX Error Codes and Messages :
A forced stop due to a failover on the host on the receiving side can be detected if the following products are installed on the host:
-
HULFT for Windows Ver.7.3.0 or higher
-
HULFT for Linux
-
Lower than HULFT for UNIX Ver.10.0.0
-
HULFT for AIX Ver.10.0.0 or higher
Error codes when a data verification error occurs on the receiving-side host
If a data verification error occurs on the receiving-side host, one of the following error codes is recorded in the Send Log:
- 250–535
-
- 250:
-
Status code of the Send process (An error occurred on the receiving side)
- 535:
-
Status code of the receiving-side host indicating that a data verification error occurred
For details, refer to the following for the host type on the receiving side:
HULFT10 for Linux/AIX Error Codes and Messages :