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.

(1) Flow of auto resending

The flow of auto resending is illustrated in Figure 2.7 .

Figure 2.7 Auto Resending

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.

= Remarks =

  • 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.

(2) 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 Error Codes and Messages of the host type on the receiving side.

= Remarks =

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 UNIX/Linux

  • HULFT for Windows Ver.7.3.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 Error Codes and Messages of the host type on the receiving side.