REStart subcommand

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:
- Issue the REStart subcommand.
- Save the check point file or data set. You will have to restore the check point file or data set before issuing the REStart subcommand.
  Restriction: Do not edit the check point 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.