Flow of the Resend File processing
If a transfer is interrupted due to some kind of trouble after you start the transfer, you can carry out the transfer again by issuing the Resend File (utlsend.exe) command. This request is called the 'Resend File' in HULFT. When you issue the Resend File, the Send system carries out the transfer from the point where the Send processing was interrupted (checkpoint). This transfer is called the 'Checkpoint Resend File.' This function is useful for Send files with a large data volume, because the data that has already been sent is not transferred again. If you issue the Resend File without specifying the Checkpoint Resend File, the data is transferred from the beginning. Use this option when it is necessary to transfer the Send file from the beginning, such as if some changes are made in the file after an unsuccessful transfer.
This processing is based on the assumption that both the Send process on the sending side and the Receive process on the receiving side have already been started.
The flow of the Checkpoint Resend File is illustrated in Figure 2.5 .
1) Issuing the Resend File command
Issuing the Resend File command to the Send Acknowledge thread starts resending. Even if a Pre-send Job has been set in the Send Management Information, the Pre-send Job will not be started.
2) Creating the Send thread
The Send Acknowledge thread receives the Resend File command and creates a Send thread according to the criteria in the Resend Queue file (sddreqls.dat) and each management information file.
3) Skipping reading of the Send file
For the Checkpoint Resend File, the Send thread determines the sent size and the sent record count from the Resend Queue file and skips the reading of data that has already been transferred.
4) Carrying out Send processing
The Send thread carries out Code Conversion and file compression based on the settings of the Send Management Information record for the transfer that was previously interrupted, then transfers the unsent data of the Send file to the remote host. Data is transferred from the beginning of the Send file if the Checkpoint Resend File is not specified when the Resend File command is issued.
5) Writing the result to the Send Log file
The Send thread writes the result of the Send processing in the Send Log file after the processing is complete.
In addition, if the Send processing ends unsuccessfully, the Send thread writes the information about the failed transfer into the Resend Queue file (sddreqls.dat).
6) Starting up the Post-send Job
The Send thread activates the Post-send Job that is registered in the Job Information according to the condition that is registered in the Send Management Information. HULFT activates either the job that is specified for the successful end of the Resend File processing or the one for the unsuccessful end of the Resend File processing, depending on the transfer result.
7) Writing the result to the Post-send Job Execution Log file
The Send thread writes the job execution results to the Post-send Job Execution Log file.
8) Triggering an email
The Send thread triggers to send an email according to the settings that are registered in the Mail Interface Information.
When HULFT carries out the Send File or Send Request, any queue records with the same criteria as the Send processing are deleted from the Resend Queue. To specify the criteria for the deletion, set Criteria to Delete Resend Queue (resenddel) in the System Environment Settings.