Flow of the Resend Request processing
Resending can also be carried out when you issue the Resend Request command (utlrecv) as a request from the receiving side. This is called the 'Resend Request' in HULFT. When you issue the Resend Request, the Send system carries out the transfer from the point where the Send processing was interrupted (checkpoint). This transferring is called the 'Checkpoint Resend Request.' 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 Request request without specifying the Checkpoint Resend Request, the data is transferred from the beginning. Use this option if it is necessary to transfer data from the beginning, such as when changes are made in the Send file after an unsuccessful transfer.
This processing is based on the assumption that both the Send daemon and the Observe daemon on the sending side and the Receive daemon on the receiving side have already been started.
The flow of the Checkpoint Resend Request is illustrated in Figure 2.6 .
1) Issuing the Resend Request command
The Observe daemon acknowledges the Resend Request from the receiving side. In the case of resending, the Pre-send Job is not started even when it is set in the Send Management Information.
2) Starting up the Observe process
When the Observe daemon acknowledges the Send Request from the receiving side, the daemon starts the Observe process. This is performed every time the request is acknowledged and the procedures from 3) onwards are executed. When a Pre-send Job is set in the Send Management Information, HULFT can execute the job before the operation described in 3) .
The Observe process issues the request for the Send processing to the Send daemon.
4) Writing the request to the Observe Log file
The Observe process writes the request from the receiving side into the Observe Log file.
5) Starting up the Send process
The Send daemon receives the Resend Request and activates a Send process according to the conditions that are registered in the Send Control file (Resend Queue file) (sddsendlist.dat) and each management information file.
6) Skipping reading of the Send file
The Send process determines the sent size and the sent record count from the Send Control file and skips the reading of data that has already been transferred.
7) Carrying out Send processing
The Send process carries out Code Conversion and file compression based on the settings of the transferred Send Management Information, then transfers the unsent data of the Send file to the remote host. Data is transferred from the checkpoint if resending from the beginning of the file is not specified when the host on the receiving side issues the Resend Request request.
8) Writing the result to the Send Log file
The Send process 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 process writes the information about the failed transfer into the Send Control file (Resend Queue file).
9) Starting up the Post-send Job
The Send process 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 sending or the one for the unsuccessful end of the sending, depending on the transfer result.
10) Writing the result to the Post-send Job Execution Log file
The Send process writes the job execution results to the Post-send Job Execution Log file.
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.