Testing restartable code

Additional testing should be performed to ensure that the application program that is using the QUICKSTART for MVS product behaves correctly during a restart. Consider the following steps:

1. Ensure that an adequate volume of test data exists so that the application program can execute for a reasonable length of time (for example, at least five elapsed minutes, or at least thirty CPU seconds). This allows an adequate number of transactions and checkpoints to have been processed by the application program.
2. Ensure that the job execution can be repeated, such that the ability exists to recreate and successfully process the input data stream. This is not a necessary step for nonupdating batch jobs.

3. Completely execute the batch job at least once. Ensure that the QUICKSTART initialization message is displayed on the System Console and that QUICKSTART checkpoint messages are also being displayed.

   Note

   If checkpoint messages are not appearing, the amount of input data may need to be increased, such that a checkpoint Threshold can be reached. Once the job has executed successfully, save any output datasets that will be used for comparison purposes later.

4. Restore the data so the job can be executed from the beginning.
5. On a subsequent execution, “Force” an ABEND after at least one checkpoint has been issued. This can be accomplished by any of several methods:
   • In Transparent Mode, specify the ABENDAFTER= parm card in QSCTRL1 dataset, or in API Mode, CALL the QUICKSTART utility program QSABEND for an imperative ABEND, or the QUICKSTART utility program QSCABEND which conditionally ABENDs, provided there is a DD Statement for the DDName QSCABEND. For example,
     //QSCABEND DD DUMMY
   • Submit the job and Cancel the job after at least one checkpoint has been issued.
   • Submit the job with a large amount of input data in a short-running job Class to incur a System 322 ABEND.

   • Introduce a programming error such as a “Divide by Zero” condition after at least one checkpoint has been issued.

     Note

     If using this method, the induced error will need to be removed and the program recompiled before the restart is attempted.

   • Introduce into the application program a parameter-driven ABEND. For example, in the presence of such a parameter, the application program should ABEND after having processed, say, 10,000 transactions.
6. Resubmit the job and test the Console Operator reply exercise if the option has been enabled.
7. Following a successful execution of the job, compare the sequential file outputs. A file Compare Utility would be helpful, if available. If possible, validate DBMS updates against online transaction screens, or compare DBMS backups/image copies from ABENDed/restarted runs and non-ABENDed runs.

This section contains the following topics: