 |
» |
|
|
|
If you specify CHECKPT in
the DSCOPY command line, the file transfer will
occur normally, but an additional handshake sequence will occur
between the source and target HP 3000 systems at periodic intervals
(optionally specified by you). If a failure occurs, it is then possible
to restart the transfer from the point where the last handshake
took place. A restart ID is a number
that uniquely identifies a transfer. The restart ID
is returned to you before a file transfer actually begins. For example,
if a transfer were 44% complete when a handshake occurred, and the
link were to fail at some time before the next handshake, the transfer
could be restarted at a later time with at least 44% of the transfer
already complete. To restart an aborted transfer, specify the keyword RESTART
in the DSCOPY command line along with the same
restart ID that was returned to you when CHECKPT
was specified. You must be logged on to the
same local environment where CHECKPT
was specified. NFT will then attempt to restart the transfer from
the point where the last handshake sequence took place. The restarted
transfer will continue to be checkpointed and may be restarted in
the event of a subsequent failure. In order to use CHECKPT/RESTART,
the producer and consumer environments cannot be the same; that
is, checkpointing will not be done for local transfers. When you restart a transfer by using the RESTART
option, you can also invoke the CHECKPT
option in order to modify the checkpoint interval;
all other options will be ignored. | | | |  | NOTE: You can access and change source and target files between
checkpointing and restarting. If you change the source file, you
might not get the exact file you want on the target side. In this
case, you should probably restart the entire transfer again. | | | | |
New Restart Files Created During Checkpointed Transfer | |
In order to store restart information that will survive a
system failure, NFT creates files called restart files. One file
is created in the group and account of each role being played by
NFT, that is, initiator, producer, and consumer. If more than one
role is being played by a single environment, the restart file will
be shared. The name of the restart file will be NFTRxx,
where xx is a number from 1 to
99. These files will be purged upon successful completion of the
file transfer. If an intermediate failure occurs, the files will
not be purged. Therefore, transfers that fail and are not restarted
to a successful completion will leave restart files unpurged; NFT
will not purge unused restart files. Similarly, for generic transfers a permanent file called GENSETx,
where x is a number from 0 to 9,
is created to hold the list of files to be transferred on the producer
node. This file is purged when the generic transfer is complete.
Likewise, a file called NFTSCRxx,
where xx is a number from 0 to
99, is created on the consumer node when the REP
option is specified. This file is used as a scratch file to hold
the target file during the transfer. When the transfer is complete,
the old target file is purged and the scratch file is renamed to
the target file name. Again, if an intermediate failure occurs,
these files will not be purged. If the transfer is not restarted
to a successful completion, these files will remain unpurged; NFT
will not purge unused generic or scratch files. Using CHECKPT and RESTART in Shared Environments | |
Checkpointing is allowed when the producer or consumer environments
were created using REMOTE HELLO.
If a restart is necessary, however, NFT will always attempt a programmatic
logon to the producer or consumer nodes. In other words, NFT will
set up its own, temporary environment, equivalent to your using
the square brackets to specify the remote logon. If a password is
needed to access one or both of these environments, it will not
be available to NFT, and the restart will fail. The only way to
ensure that this problem will not occur is to use the programmatic
logon feature of NFT when CHECKPT
is specified. The password(s) will then be available to NFT, so
that a subsequent restart will be able to logon to the remote node(s). Files Not Allowed with CHECKPT and RESTARTCHECKPT/RESTART is not allowed
with message or circular files. It is also not allowed with files
of variable length records in interchange mode. Troubleshooting After Using CHECKPT and RESTARTIf a restart returns an error, some possible explanations
might be: One or more of the necessary files
for restarting has been lost or corrupted, that is, NFTRxx,
GENSETx, or NFTSCRxx,
or the source or target files. The transfer did not progress past the negotiation
stage before it was aborted. The error was not one from which a restart can be
done; examples include a file lockword violation or an unknown node
name. A restart can only be done if the transfer has progressed
past the negotiation stage to the data transfer stage. The circumstances that caused the failure have not
cleared; that is, the remote system is still down, or the link has
not yet been reestablished. You are not using the same local logon as was used
when checkpointing was specified. The file equation for DSCOPYI
is not the same as it was when checkpointing was specified, or the
command file has been purged or corrupted.
HP 3000 to HP 3000 Copying Examples | |
Following are examples of how to use the DSCOPY
command for copying files between HP 3000s. DSCOPY can be used (from
the MPE/iX prompt) to make a local copy of a local file. If no global
location specifications are in effect, the following names will
be interpreted as local files: The node name delimiter (colon or comma) used alone will override
any global specification and indicate that the file is local. In
this example a semicolon replaces TO,
since TO would be misinterpreted
as the source environment ID following the colon. The following (still local) example copies a file named INFO
in the PUB group of the MKTG
account into a (new) file of the same name in the user's
logon group and account: DSCOPY INFO.PUB.MKTG TO INFO |
In the next example we assume that a remote session has been
established on REMNODE and that
no global tfileloc specification is in
effect. This command, typed at the MPE/iX prompt, requests a local
copy of a remote file: DSCOPY FILEA:REMNODE TO FILEB |
If a remote session has not already been established, and
if there is no global or DSLINE
logon for the remote environment, you must include a logon sequence
in the transfer specification. The following is a local-to-remote
transfer (typed from the MPE/iX prompt): DSCOPY FILEY TO FILEZ:REMNODE[REMUSER.REMACCT] |
In the next examples we'll assume that remote sessions have
already been established. From your local system you can copy one
remote file to another on the same remote node. At the MPE/iX prompt,
type: DSCOPY FILE17:REMNODE TO FILE18:REMNODE |
You can also copy a file from one remote system to another: DSCOPY FILE1:REMNODEA TO FILE2:REMNODEB |
This example shows how to use the @
character to copy a set of files. All files in the PUB
group of the MKTG account whose
last four characters are BACK are
copied to the AAA group of the
ENG account. The target files will
have the same file names as the source files. At the MPE/iX prompt,
type: DSCOPY @BACK.PUB.MKTG TO @.AAA.ENG |
Finally, you can establish global transfer specifications
by putting a + before the specification
sequence. If you include the global specifications in the DSCOPY
command line, you will be placed in the subsystem, from which you
can issue further commands. For example, at the MPE/iX prompt type
the command as follows (user input is bold for clarity): DSCOPY + :REMNODEB TO :REMNODEA; MOVE; COMP |
DSCOPY THISFILE TO THATFILE |
After the first DSCOPY command establishes
global specifications, the command at the subsystem prompt moves
THISFILE on REMNODEB
to THATFILE on REMNODEA,
purging the original file. The data are compressed during the transfer.
Assume that remote sessions have already been established. CHECKPT and RESTART Examples | |
Following are examples of how to use CHECKPT
and RESTART: The following example shows checkpointing
being initiated for an IMAGE dataset
file. The checkpoint interval is the default (5 minutes).
The restart ID will not be written to
a file, but will be written to $STDLIST
if QUIET has not been specified
or if output has not been disabled. :DSCOPYSFILE;TFILE:REMNODE[REMUSER.REMACCT]; |
The following example shows checkpointing being
initiated for the remote producer case. You have specified a new
checkpoint interval (60 seconds), a restart ID file
(IDFILE), and a record in that
file where the restart ID will be written
(12) DSCOPYSFILE:REMNODE[REMUSER.REMACCT];TFILE; CHECKPT=60,IDFILE,12 |
This example shows checkpointing being initiated
in a generic transfer. You have specified a new checkpoint interval
(600 seconds) and a restart ID file (IDFILE).
The restart ID will be written to the
first record in the file, by default. :DSCOPY@.PUB;@:REMNODE[REMUSER.REMACCT];CHECKPT= 600,IDFILE |
This example shows a restart being specified as
a global option. All other global options are ignored. The restart ID
is 4. This example shows a restart being specified as
a non-global option. The restart ID is
2. Checkpointing is also specified
in order to change the previous checkpoint interval to 100 seconds.: :DSCOPY;;CHECKPT=100;RESTART=2 |
This example shows the restart option with the restart ID file
specified. The restart ID will be obtained
from the first record of this file.
|
