Message and error states
This table shows the recovery database message states:
1: On IB pre-TPS queue | 2: On IB post-TPS queue |
3: Sent by ICL to xlate | 4: Staged at ICL received by xlate |
5: On pre-xlate queue | 6: Currently in xlate processing |
7: On post-xlate queue | 8: Sent by ICL to destination |
9: Staged at ICL received by destination | 10: On OB pre-TPS queue |
11: On OB post-TPS queue | 12: On FWD pre-TPS queue |
13: On FWD post-TPS queue | 14: Successful delivery |
15: Failed delivery | 16: OB reserved for IB reply |
17: OB prewrite | 18: Unbacked queue |
19: On Java IB protocol | 20: On Java OB protocol |
This table shows the error database message states:
100: Failed to get Trx ID | 101: Unsupported Trx ID |
103: Tcl failure in Trx ID determination | 104: No destination for reply |
105: No destination for message | 106: Disallowed Gateway routing |
107: Incorrect remote ICL server See State 107 note |
108: Incorrect dest to
receive EDB_ROUTE_DESTNOTMATCH |
200: Failure in IB Reply TPS eval | 201: Failure in IB Data TPS eval |
202: Failure in OB Reply TPS eval | 203: Failure in OB Data TPS eval |
204: Failure in FWD Reply TPS eval | 205: Failure in FWD Data TPS eval |
300: XLT config file unloadable | 301: Internal XPM Tcl failure |
302: Tcl callout error | 303: Tcl callout abort |
304: XPM data retrieval failed | 305: XPM data store failed |
306: XPM bulkcopy operation failed | 307: Input data validation failure |
308: Output data validation failure | 309: XPM default value retrieve failed |
310: XPM math operation error | 311: $xlateOutVals unset |
312: XPM numeric comparison error | 313: XPM string comparison error |
314: XSLT transformation failure | |
400: Failure in protocol startup | 401: Failure in ACK/NAK proc |
402: Failure in SENDOK proc | 403: Failure in SENDFAIL proc |
404: Failure in REPLYGEN proc | 405: Retry count exceeded |
406: Tcl failure in startup SendOk TPS | 407: Tcl failure in startup SendFail TPS |
408: Tcl failure in protocol driver TPS | 409: Tcl failure in pre-write TPS |
410: Failed to recover reserved outbound message | 414: User code error in UPoC protocol read TPS |
415: User code error in UPoC protocol write TPS | 416: Inbound encoding conversion
error See State 416 note |
417: Outbound encoding conversion error | 418: Unable to deliver to specified server connection |
419: Bad data (error) in message writing | |
500: Internal failure: Unable to read message data chain | 501: Error database TPS error |
1000: Internal failure: Start route | 1001: Internal failure: Bad route config |
1002: Internal failure: No route config | 1003: Internal failure: Bad route detail |
1004: Internal failure: Bad format |
State 107 note
Error database state 107: EDB_ROUTE_REMOTEICLDEST (Incorrect remote ICL server) happens when an inter-site routing message, recovery database state 7 RDB_XLATE_POST_XLATE, is being recovered from the start-up of the engine. If both the remote ICL server (ICL destination) are unresponsive and the ICL destination definition is changed in NetConfig, then the message is moved to the error database with state 107.
The message is put into the error database during recovery from the recovery database if both of these conditions are met:
- The message cannot be
delivered to the port it thinks it should go to.
If this is the case, then the message stays in the recovery database and in the queue because the server might be unresponsive.
- The configuration, as
loaded when the process/thread is started, no longer matches the port the message
expects.
If this is the case, then the message stays in the recovery database because the configuration has changed. The message can be delivered, so that delivery continues when possible.
During the error database resend, the port is corrected as the newly configured port.
The destination, including port number, is set when a message is routed, not when the message is delivered.
State 416 note
A message with this error state indicates an error happened during encoding from the encoding setting to UTF-8 when it is received in the inbound protocol thread. For example, the encoding setting of the inbound thread does not match the real message. In this situation, the message keeps its original encoding in the SMAT.
When resending such a message from SMAT, the engine converts it from
the -e
option that is given by the resend command to
the encoding setting of the inbound thread. It then puts the message in the engine
queue. In the engine queue, the message is treated as a new message from the inbound
thread. The engine does the encoding conversion from the encoding setting of the inbound
thread to UTF-8 again.
If the resend command does not give the -e
option, then the engine skips the first encoding conversion. It directly
puts the message from SMAT to the engine queue.
Use one of these methods to fix the encoding error and resend the error message:
- All the messages coming to
the inbound thread have another encoding from the thread setting. The thread setting
is incorrect.
Stop the thread and change the encoding setting to the correct one. Then, start the thread and resend the error message with/without the
-e
option.If
-e
is given, then the encoding argument is the same as the message. - Only the error message has
another encoding from the thread setting. Other messages coming to the thread still
have the same as thread setting.
Resend the error message with the
-e
option without changing the thread properties. The encoding argument is the correct one of the message.