After calling DBCHINI, set the crash/delay options as follows:
- Tell About Crash (or Tell Across Crash) to 'Y'
- Wait Across Crash (or Wait Across Delay) to 'Y'
Given this combination of options, a database crash or AP reset can be handled as follows:
- The application program calls DBCHCL for some function.
- The database crashes or an AP resets before or after receiving information from DBCHCL.
- CLI returns control to the application program, with return code of EM_DBC_CRASH_B or EM_DBC_CRASH_A.
- The application program can tell its user of the possible crash/delay and can ask the user whether to wait or disconnect.
- Assuming a wait, the application program calls DBCHCL for the fetch function.
- The database restarts or AP reset completes.
- The application obtains results of the Fetch:
- The database does not know anything about a request with that request number (Error parcel with error code 2825)
- The database aborted that request (Failure parcel with failure code 2828)
- The request completed successfully but the response has been lost (Error parcel with error code 2826)
- The application program takes action appropriate to the application.
Before submitting a request, save a copy of the request in case it must be re-submitted. If a transaction spans several requests, save a copy of each request in the transaction in case the transaction must be re-submitted.
Tell and wait can be useful to terminal-oriented applications to distinguish excessive response time from the unlikely, but possible, database crash, or AP reset.