Purpose
Use the REStart subcommand to restart
a check pointed file or data set transfer that has been interrupted.
Format
>>-REStart-----------------------------------------------------><
Parameters
There are no parameters for
this subcommand.
Requirements: - To restart a file transfer with the REStart subcommand, you must
have had check pointing enabled during the file transfer you want
to restart.
- Before you issue the REStart subcommand, set up the same file
transfer environment (such as file transfer mode, type, and CHPTPREFIX
file or data set) that you had configured during the file transfer
that you want to restart.
Guidelines: - Use the REStart subcommand to resume file transfer when a check
pointed file transfer request fails because of a temporary condition
such as the loss of the connection between the client and the server.
- Enable check pointing by the following steps:
- Configure a check point data set or file, and a check point interval
greater than zero. FTP uses the check point data set or file to store
the information that it needs to resume the data transfer. The check
point interval determines how often the client and server exchange
information needed to restart the file transfer.
- Transfer files and data sets with type EBCDIC and mode block or
compressed. Check pointing is available only for type EBCDIC file
transfers in block or compressed mode.
Rule: Do not enable check pointing
if the server you are logged into does not support the REST command.
By default, check pointing is enabled in both directions of file
transfer when you enable file transfer. You can control whether
check pointing is enabled for Get subcommand processing by configuring
RESTGET at the FTP client. You can use the LOCSIte subcommand, or
code the RESTGET statement in FTP.DATA, to configure RESTGET.
If you are logged into the z/OS® FTP server, you can control check pointing at the server with the
server CHKPTINT and RESTPUT configuration options.
- Every time when you start a new file transfer while check pointing
is enabled, FTP reuses the check point file or data set. To prevent
losing restart information after a failed or interrupted file transfer,
do one of the following steps before transferring another file or
data set:
- If you transfer two or more data sets simultaneously with check
pointing enabled, assign each session a different check point data
set to prevent two users from contending for the same check point
file or data set.
Results
- The REStart subcommand restarts the last checkpoint
file transfer request at the point of the last valid checkpoint stored
in the checkpoint data set.
- After a successful file transfer with check pointing enabled,
FTP deletes the check point file or data set.
- The LOCSIte NORESTGet subcommand prevents opening the checkpoint
data set for a Get request.
- The MVSGet or MVSPut subcommand supports checkpointing
for block mode restart of an interrupted file transfer only for physical
sequential data sets. The MVSGet and MVSPut subcommands
do not support checkpointing for block mode restart of PDS or library
data sets.