Input transactions that cause a COMSTP program to terminate abnormally are backed out of the database by DMS II.

If a transaction fails, COMS restarts the COMSTP program if it has terminated, and resubmit the original input. If the transaction fails again, one more attempt is made to try to establish if this is a transient error, such as a DMS deadlock.

Fatal Error Messages

If the error was fatal, the restarted COMSTP program outputs one of the following error messages to the Status line, indicating INPUT was rejected.

The following message covers unknown errors, accidental terminations (DS), and so on:

INPUT rejected due to FATAL program error

The following message usually indicates a DMS II limit error. You should check ODT messages and SUMLOG:

INPUT rejected due to FATAL DMS error

Deadlock Messages

In the case of a DMS Deadlock condition, if two successive retries are unsuccessful, you receive the following message:

RESOURCE LOCKED OUT. XMIT to retry.

Recovery

Only the COMSTP program that fails enters recovery. Any other input transactions continues independently. Transaction independence is provided by DMS II.

When a transaction is recovered and the LINCSUPPORT library has closed down since the original transaction was processed, the transaction is reprocessed with a new Glb.Unique value.

In Reports, the built-in attribute Glb.Recover is set to 1 to indicate that recovery is in process.

Refer to the Agile Business Suite Programming Reference Manual for more information on the value of built-in attributes in recovery.