Error trap TPS

When an error message is transitioned to the error database, you can control the event processing through the error trap TPS. You can specify procs to be called before messages are sent to the error database.

For example, you can show, save, stop, resend, or NAK, the message before it goes into the error database.

Configuration locations include:

  • Network Configurator:

    The error TPS can be configured in the protocol thread and process levels. The NetConfig is:

    • Process level:
      process helloworld { 
          { ERRDBTPS { 
              { ERRTPSPROCS {{ARGS {{}}} {PROCS cl_show_err_msg} {PROCSCONTROL ENABLED}}} 
              { RETRIES  2 }    
          } } 
      } 
    • Protocol thread:
      protocol in { 
          { ERRDBTPS { 
              { ERRTPSPROCS {{ARGS {{}}} {PROCS cl_show_err_msg} {PROCSCONTROL ENABLED}}} 
              { RETRIES  2 }    
          } } 
      } 
  • Engine Output Configurator:

    EO module dbi:etps

  • Database Administrator:

    501: Error database TPS error

  • TPS disposition:

    A RETRY disposition is in the DispositionList of Tcl and Java UPoC.

  • Error database TPS:

    The error database TPS gives you a control point before a message is written to the error database. This means you have the opportunity to change the error message content and to route the message to another context.

    For example, you can:

    • Change the message content to add information before the message goes to the error database.
    • Stop the message so it does not go to the error database.
    • Send a NAK to the source to notify there is an error when processing the message.
    • Save the message to a file or another external source, and resend the message that is based on it.

Samples and templates include:

  • errdbtps.tcl
  • errdbtps_template
  • %HCIROOT/tclprocs

TPS mode message flow

These TPS processing modes indicate the timing and scenarios when the engine calls the corresponding Tcl code fragment:

  • TPS_MODE_START

    When the thread has started, but is not yet scheduled to run and process events, the engine calls the thread initialization function. This is the function in which it calls the DBI initialization function for error and recovery database setup. During DBI initialization, it sets up DBI thread specific data (DTD data). In this stage, it gets error database TPS specific data from the NetConfig file. It then sets the TPS context in the xlate thread data and protocol thread data. Then, it runs the TPS start mode.

  • TPS_MODE_RUN

    When the thread is processing an event and it goes to an error, it calls a function to transition a message to the error database. In this stage, it gets the TPS context from the DTD data. Then it sets the mode in TPS context to TPS_MODE_RUN, and runs TPS run mode code. After this completes, the message is written to the error database or goes somewhere else depending on the disposition state returned from TPS.

  • TPS_MODE_SHUTDOWN

    When the thread is shut down, it calls the DBI shutdown function to release resources that are related to the error and recovery database. In this stage, it runs the TPS shutdown mode code. Then, it frees the TPS context and destroys the Xlate thread data and protocol thread data to free the resource.

Note: TPS_MODE_TIME is not supported.

Error database TPS message flow

When the process transitions a message to the error database, it goes through these steps:

  1. Updates the monitorD statistic information that is based on the EDB state of the message, then goes to the next step.
  2. Updates the recovery database state of the error message. If this fails, then it returns with an error; otherwise, it goes to the next step.
  3. If message tracing is enabled, then it writes the tracing information for the error message. If this fails, then it returns with an error; otherwise, it goes to the next step.
  4. If an error database TPS is configured, then it calls the TPS procedure stack and passes the error message and error context for processing. After TPS processing, it does the callback function for disposition. When the disposition is continue, it goes to next step. Or, it goes to Step 1 when the disposition is error, or ends/drops the message when another disposition is found.
  5. Writes the error message to the error database. If this fails, then it returns with an error; otherwise, it goes to the next step.
  6. Writes the error message context to the error database. If this fails, then it returns with an error; otherwise, it goes to the next step.
  7. Removes the message from the recovery database.

Example: Finding and resending a message in ErrorDB

User 1 needs to search the Error Database for a specific message, edit it, and resend it.

To do this, User 1 launches the Error DB IDE tool and performs a regular expression search for “12345.”

One or more transactions are returned from the search. User 1 selects a transaction and edits it to change the user ID from “12345” to “54321.” The edits are temporary and not made to the stored data.

User 1 then resends the transaction.