Troubleshooting Span

This topic includes guidelines for troubleshooting any problems you may encounter with Span.

  1. Read the Span report (MSGFILE).

    The report includes the following:

    • The name of the parameters file that Span read
    • The option settings that Span used
    • The output file destinations
    • The number of records replicated and the number of records skipped
    • The reason Span stopped processing

    See REPORT and Span Report Files.

  2. If only some data sets are updated, check the Mode column for each data set in the Span parameters file.
    • If the mode is 3, the DMSII data set was reorganized. You must change the mode to 2 and change the client format level to the DMS format level after you make the corresponding change in the client database.
    • If the mode is 4, the data set was initialized using DMUTILITY. You must change the mode to 2 after you purge the corresponding rows in the client database.

    Change the mode before you run Span again. For more details, see Complete a DMSII Reorganization.

  3. If Span renames files by adding the node …/BAD, check your entry for the HEADER option in the Span parameters file.

    Most likely the HEADER option is TRUE, but you have existing files that do not have the correct header. This could be because the HEADER option was previously FALSE when those files were created.

  4. If Span waits on a NO FILE for an audit file, it can't find the audit file (on disk or tape) it needs to continue processing. Do one of the following:
    • Mount the tape containing that audit file and let Span continue.
    • DS the DATABRIDGE/MISSING_AUDIT_FILE task, which tells it that you cannot provide the audit file now. In this case Span stops processing immediately. The next time Span runs, it requests the same audit file.

    If replication fails during the fixup phase, the fixup phase can be restarted. The Span receives COMMITs at the end of transaction groups during the fixup phase. You can restart the replication from the last COMMIT.

  5. If Span finds duplicate data file names on the host, remove the data files as you move them to the client system for processing or do the following:
    1. Change the data file titles

      CHANGE SPAN/DATA/databasename/datasetname TO READYTOMOVE/SPAN/DATA/databasename/datasetname

    2. Transfer the READYTOMOVE files to a client system or another location.
    3. Remove the READYTOMOVE files.
  6. Process Span anomalies.

    Since DBEngine does not have the opportunity to consolidate the changes that occurred during the extraction with the extracted records themselves, there is the possibility that during the fixup phase, Span will receive duplicate creates, deletes, or modifies for deleted records. DATABridge does not flag these anomalies; therefore, you should be aware that these anomalies can occur.

    1. When a duplicate record is encountered on a new record insert, replace the old record in the table with the new record to be created. For example, for duplicate creates, convert the second create to a modify.
    2. Ignore missing records when a delete function is requested. For example, when the delete function fails, ignore the second delete.
    3. When a modify function does not find a record in the client table, discard the modify.

    If the client cannot handle the anomalies, you can use Snapshot to create a clean snapshot of the data sets.