When Crash or AP Reset Occurs - Call-Level Interface Version 2

Teradata Call-Level Interface Version 2 Reference for Mainframe-Attached Systems

Product
Call-Level Interface Version 2
Release Number
16.10
Published
May 2017
Language
English (United States)
Last Update
2018-05-07
dita:mapPath
jen1488824663137.ditamap
dita:ditavalPath
Audience_PDF_include.ditaval
dita:id
B035-2417
lifecycle
previous
Product Category
Teradata Tools and Utilities

When an application is running and either a Teradata Database crash or AP reset occurs, the following steps occur:

  • The TDP session numbers are preserved and can continue to be used.
  • If a restart is detected during logoff processing, CLIv2 reconnects the session and resubmits the logoff request.
  • Affected Teradata transactions are aborted and all of the databases involved are rolled back to the state they would have been in if the transactions had not begun.
  • Affected requests that have not completed are aborted, and any work they have performed is rolled back.
  • Affected spool files on the Teradata Database, including those that the Teradata Database has kept for completed requests, are discarded.
  • Applications already waiting for a response before the event occurs will be notified. (For when and how, see What the Application Does.)
  • Applications submitting a request during the crash and recovery process may be notified. See What the Application Does.
  • Applications later using the abort, fetch, rewind, or end request function for a Teradata SQL request aborted by the event, or submitting a new request in a transaction that was in progress when the event occurred and thus was aborted in the recovery process, will be notified. See What the Application Does.