HP 3000 Manuals HP 3000 Manuals
Using Checkpoint and Restart with DSCOPY 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, wherexx 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 the DSCOPYI File for Checkpointing Transfers initiated using the DSCOPYI command file can also use CHECKPT/RESTART. If a failure occurs during any of the transfers in the list, that transfer can be restarted in the normal way. When that transfer is complete, the next transfer in the list will take place as if no failure had ever occurred. When checkpointing from a DSCOPYI file note the following conditions. First, a separate restart ID will be returned for each transfer. Second, in order to restart a transfer from DSCOPYI, the same file equation that was specified for checkpointing must be in effect when the restart is attempted.
NOTE The RESTART keyword cannot be used from within a DSCOPYI file.
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 RESTART CHECKPT/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 RESTART If a restart returns an error, some possible explanations might be: 1. 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. 2. The transfer did not progress past the negotiation stage before it was aborted. 3. 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. 4. 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. 5. You are not using the same local logon as was used when checkpointing was specified. 6. 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. Local to Local DSCOPY can used (from the MPE XL 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: DSCOPY SFILE TO TFILE 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. DSCOPY SFILE:;TFILE 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 Remote to Local 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 XL prompt, requests a local copy of a remote file: DSCOPY FILEA:REMNODE TO FILEB Local to Remote 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 XL prompt): DSCOPY FILEY TO FILEZ:REMNODE[REMUSER.REMACCT] Remote to Remote 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 XL 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 Multiple Transfer 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/XL prompt, type: DSCOPY @BACK.PUB.MKTG TO @.AAA.ENG Global Specifications 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/XL prompt type the command as follows (user input is underlined 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: 1. 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]; CHECKPT=;FCODE=-401 2. 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 3. 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 4. This example shows a restart being specified as a global option. All other global options are ignored. The restart ID is 4. :DSCOPY+RESTART=4 5. 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 6. 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. :DSCOPY;;RESTART=IDFILE