exception(1) — Commands
Digital
NAME
Exception − a run-time system-detected event that changes normal task execution flow
DESCRIPTION
Exceptions are caused by errors or other conditions encountered during the execution of an operation for a task, a processing procedure, or a presentation procedure.
An exception handler is the part of a task that is executed only when an exception occurs. In STDL, all exceptions must be passed back to the task. Processing procedures cannot contain exception handling because transaction control is handled in the task.
When an exception occurs, workspace fields passed as arguments are no longer valid. The transaction commits or rolls back, depending on the exception and the point within the transaction at which the exception occurs.
How Exceptions Are Raised
The ACMSxp run-time system raises exceptions under the following conditions:
•If any error is detected while performing an operation within a task.
•If an error occurs that prevents the continued execution of a processing or presentation procedure.
Applications can also raise exceptions, and user-written programs can check for exceptions. The application raises an exception as follows:
•For user-written tasks, by executing the RAISE EXCEPTION or RESTART TRANSACTION statements
•For user-written processing and presentation procedures, by setting values in STDL-defined einfo (C programming) or EINFO (COBOL programming) external variable. ACMSxp software reads the variable to determine the exception code and action to take.
The STDL coding for the EINFO data type definition determines the format of the error information as shown below:
TYPE einfo IS
RECORD
ECLASS INTEGER;
ECODE INTEGER;
EPROC TEXT CHARACTER SET SIMPLE-LATIN SIZE 32;
EPGROUP TEXT CHARACTER SET SIMPLE-LATIN SIZE 32;
ESOURCE INTEGER;
ECGROUP UUID;
END RECORD;
The fields in this data type definition correspond to fields in the system workspace EXCEPTION-INFO-WORKSPACE that ACMSxp uses to pass the error information to the task. The workspace man page describes the fields.
The general mechanism for ACMSxp software passing error information to the task for exception handling is the same for C and COBOL procedures. However, the details differ for the C and COBOL languages.
See the exception_handler man page for information about handling the returned exceptions.
TPsystem Actions to an Exception
When an exception is generated, the TPsystem performs the following actions:
1.If the TPsystem raises the exception, maps the implementation-specific exception code to the appropriate exception class.
2.If a top-level processing procedure or a presentation procedure exits or a task executes either a RAISE EXCEPTION or RESTART TRANSACTION, the TPsystem examines the application-defined exception code.
If the exception code is set to a nonzero value, the TPsystem maps the exception code to the appropriate exception class, as defined in the message group.
If the TPsystem cannot map the code to the class, it generates the AP-EXECUTION-FAULT exception.
3.Stores the exception information in the EXCEPTION-INFO-WORKSPACE system workspace (see below).
4.Increments the fault count attribute for each execution of a task or top-level processing procedure that results in an exception contained within the exception list.
5.If the fault count attribute exceeds the maximum fault limit attribute, disables the task or procedure.
6.If no applicable exception handler exists, terminates the task and passes the exception to the client program.
7.If a nontransaction, transient transaction, or permanent transaction exception was generated in the called processing procedure, returns to the calling task the same exception type that was generated in the processing procedure.
8.If a fatal transaction exception was generated in the called processing procedure, returns to the calling task a permanent transaction exception.
9.If any exception was generated in the called presentation procedure for a nontransactional send, receive, or transceive exchange, returns to the calling task a nontransaction exception.
10.If any exception was generated in a called presentation procedure for a transactional receive exchange, returns to the calling task a permanent transaction exception.
The remaining actions of the TPsystem depend on the type of exception. See below.
Exception Information
Before the TPsystem passes control to an exception handler when an exception is generated, ACMSxp software places the following information in the EXCEPTION-INFO-WORKSPACE:
Exception class
Exception code and exception code group
Exception level
Exception source
Exception location
Exception Class
An exception class is a grouping of exception conditions that is based on the type of recovery action that can be taken and that allows for portable exception handling. The exception class identifies the exception type as a nontransaction exception or as a transaction exception. Each exception class is initially raised as a specific exception type. The exception type can change depending on how the exception is reported. See the How Exceptions Are Raised section for an explanation of how an exception is raised and the Types of Exceptions section for a summary of how an exception type is changed.
The following are the STDL exception classes grouped by exception type and showing the STDL syntax or conditions that can raise each class. Each exception class has a corresponding numeric value. The table shows the exception type when the exception class is initially raised.
Nontransaction Exception Classes
Syntax or Condition
Class Value Raising Class
AP-PROCESSING-FAULT -9 Application can raise;
ACMSxp never raises.
ENV-EXECUTION-ERROR 6 CALL PROCEDURE
CALL TASK
EXCHANGE
ENV-EXECUTION-FAULT -7 AUDIT
DEQUEUE RECORD
ENQUEUE RECORD
SUBMIT TASK
INVALID-INPUT-ERROR 8 ACMSxp never raises.
NO-OUTPUT-ERROR 9 DEQUEUE RECORD
GET MESSAGE and
application can raise
REQUEST-TIMEOUT-ERROR 7 RECEIVE Exchange
Transient Transaction Exception Classes
Syntax or Condition
Class Value Raising Class
TXN-INCOMPLETE-ERROR 5 Application can raise;
ACMSxp never raises.
TXN-TIMEOUT-ERROR 4 Transaction time limit
exceeded
Permanent Transaction Exception Classes
Syntax or Condition
Class Value Raising Class
AP-EXECUTION-FAULT -6 AUDIT
CALL PROCEDURE
CALL TASK
COMPUTE
CONTROL FIELD MOVE
DEQUEUE RECORD
ENQUEUE RECORD
EXCHANGE
GET MESSAGE
IF THEN ELSE
MOVE
RAISE EXCEPTION
RESTART TRANSACTION
SELECT FIRST TRUE
SUBMIT TASK
WHILE DO
AP-INCOMPLETE-ERROR 3 Application can raise;
ACMSxp never raises.
AP-INVOCATION-FAULT -3 CALL PROCEDURE
CALL TASK
EXCHANGE
SUBMIT TASK
AP-RESPONSE-FAULT -5 CALL PROCEDURE
CALL TASK
EXCHANGE
ENV-INVOCATION-ERROR 1 CALL PROCEDURE
CALL TASK
EXCHANGE
SUBMIT TASK
ENV-INVOCATION-FAULT -4 CALL PROCEDURE
CALL TASK
DEQUEUE RECORD
ENQUEUE RECORD
EXCHANGE
SUBMIT TASK
TXN-FAILURE-ERROR 2 EXIT BLOCK
EXIT TASK
GET MESSAGE
GOTO and application
can raise
Fatal Transaction Exception Classes
Syntax or Condition
Class Value Raising Class
FATAL-EXECUTION-FAULT -2 Application can raise;
ACMSxp never raises.
FATAL-TIMEOUT-FAULT -1 CPU timeout exceeded
Exception Class Suffix
The suffix on the exception class name further classifies exception classes by the ability to retry the operation that generated the exception class.
The exception class suffixes are:
ERROR
Indicates that the exception is a soft error. The operation may be successful if retried, at some future time, without modifying the STDL source, standard program language source, or environment information. In some cases, data must be modified.
FAULT
Indicates that the exception is a hard error. Modifying the STDL source, standard programming language source, or environment information is required before the operation can be successfully retried.
The exception class suffix provides additional information about the type of recovery action that can be taken by the application developer.
The following exception classes are available to the application developer for raising exceptions from the application:
AP-INCOMPLETE-ERROR Permanent transaction exception
AP-PROCESSING-FAULT Nontransaction exception
FATAL-EXECUTION-FAULT Fatal transaction exception
NO-OUTPUT-ERROR Nontransaction exception
TXN-FAILURE-ERROR Permanent transaction exception
TXN-INCOMPLETE-ERROR Transient transaction exception
The following exception classes are not raised by the ACMSxp system:
AP-INCOMPLETE-ERROR
AP-PROCESSING-FAULT
FATAL-EXECUTION-FAULT
INVALID-INPUT-ERROR
TXN-INCOMPLETE-ERROR
Exception Code and Exception Code Group
An exception code is a detailed classification of an exception condition. For application-generated exceptions, the exception code is defined in a message group definition and this code is portable. For ACMSxp system exceptions, the exception code is not portable.
An exception code group is the identification of the group in which the exception code is defined. The ACMSxp system exceptions use exception code groups and an application can use them if the message group definition specifies a UUID.
ACMSxp examines the application-defined exception code when a processing or presentation procedure exits or a task executes a RAISE EXCEPTION. If the exception code is set to a nonzero value, ACMSxp maps the exception code to the appropriate exception class, as defined in the message group definition.
For an exception raised by the application, if the exception code is not defined in the message group definition, or if the exception class is not one of the standard, predefined exception classes, the ACMSxp system is unable to map the exception code to class. It generates an AP-EXECUTION-FAULT exception class.
For an exception raised by the system, the ACMSxp system maps the system-specific exception code to the appropriate exception class.
Exception Level
An exception level is a classification of exception conditions based on whether the exception was generated by:
oThe execution of the current task
oThe execution of a called task, processing procedure, or presentation procedure, which propagated the exception to the current task, processing procedure, user-written client program, or external client.
An exception level is defined as either current or propagated. An exception level is defined as current when the current task execution generates the exception and when an exception is encountered during the invocation of a task, processing procedure, or presentation procedure.
An exception level is defined as propagated when the execution of a task, processing procedure, or presentation procedure called by the current task, processing procedure, user-written client program, or external client generates the exception. A processing procedure, user-written client program, or external client cannot distinguish between a current exception and a propagated exception.
Exception Source
An exception source is a classification of exception conditions based on whether the exception was raised by the application or by the TPsystem. A task, a processing procedure, or a user-written presentation procedure can raise an application exception.
Exception Location
The exception location consists of two text fields in the EXCEPTION-INFO-WORKSPACE that contain names describing where the exception occurred:
•The name of the task (if the exception is raised by the RAISE EXCEPTION statement), processing procedure, or presentation procedure in which the exception occurred, or an arbitrary string filled in by the application
•The name of the task group (if the exception is raised by the RAISE EXCEPTION statement), processing group, or presentation group in which the exception occurred, or an arbitrary string filled in by the application
When an exception is raised in a task, ACMSxp software sets the exception procedure name to the task name, and the exception procedure group name to the task group name.
When an exception is raised by a processing procedure or presentation procedure, you can have the procedure set the exception procedure name and exception procedure group name in the einfo error information variable.
If the TPsystem raises the exception, it sets the exception procedure name to the name of the procedure executing when it raises the exception and sets the exception procedure group name to the name of the processing group or presentation group through which the executing procedure was called.
Types of Exceptions
Exception type is based on whether the exception prevents the current transaction from committing. The types are:
•Nontransaction
A nontransaction exception does not prevent the current transaction from committing. It causes the execution of an exception handler, if there is an applicable exception handler.
•Transaction
A transaction exception prevents the current transaction from committing and causes the current transaction to be rolled back. The following are the subtypes of transaction exceptions based on the actions of the ACMSxp software:
-Transient transaction
Causes the transaction to be rolled back and the TPsystem to retry the transaction.
-Permanent transaction
Causes the transaction to be rolled back and the TPsystem to execute an exception handler, if there is an applicable exception handler.
-Fatal transaction
Causes the transaction to be rolled back and the TPsystem to terminate execution of the task and to report the exception to the client program.
Each type of exception has a unique action when it is raised.
Nontransaction Exception Handling in Tasks
If a nontransaction exception is generated in a task or passed to a task, the TPsystem handling depends on whether the task is composable.
For a composable task, ACMSxp software:
1.If there is an applicable nontransaction exception handler, executes the exception handling code.
2.If there is no applicable nontransaction exception handler, terminates the task and returns the nontransaction exception to the client program.
A composable task is part of the transaction of the calling task and can handle only nontransaction exceptions.
For a noncomposable task, ACMSxp software:
1.If there is an applicable nontransaction exception handler, executes the exception handler.
2.If there is not an applicable nontransaction exception handler, changes the type of exception from nontransaction exception to permanent transaction exception.
A noncomposable task demarcates the transaction and can handle either a nontransaction exception or a transaction exception.
Transient Transaction Exception Handling in Tasks
Transient transaction exception handling depends on whether the task is restartable. A restartable task allows transient transaction exceptions. If the transaction rolls back and is retried with the same data (for example, a deadlock), this error might not recur. A nonrestartable task treats a transient transaction exception as a permanent transaction exception.
When a transient transaction is generated in the task or passed to the task, the action depends on whether the task is restartable.
For a task with the NOT RESTARTABLE task attribute, ACMSxp software:
1.Changes the transient transaction exception to a permanent transaction exception.
2.Performs the actions associated with a permanent transaction exception. The exception class, code, and source are not changed.
For a task with the RESTARTABLE task attribute, ACMSxp software checks whether the task is composable. If the task is composable, ACMSxp software terminates the task and returns the transient transaction exception to the client program. If the task is noncomposable, ACMSxp software:
1.Rolls back the current transaction.
2.If the exception was raised during the execution of a transaction exception handler, changes the type of exception from a transient transaction exception to a permanent transaction exception.
3.If the number of retries exceeded the transaction restart limit attribute for the procedure, or if the transaction included any nontransactional statements (nontransactional exchanges), changes the type of exception from a transient transaction exception to a permanent transaction exception. (The transaction restart limit attribute is set by a system administration directive.)
The ACMSxp software then performs the actions associated with a permanent transaction exception. The exception class, code, and source are not changed.
4.Increases the retry count by one.
5.Reexecutes the transaction that generated the transient transaction exception, unless:
oA CALL PRESENTATION with a nontransactional attribute and a send exchange with a broadcast list was performed.
oA CALL PRESENTATION with a receive exchange was performed.
oA nontransactional exchange was performed.
oThe transaction restart limit attribute was exceeded.
To enable transaction restartability for a restartable task, set to a nonzero value the transaction restart limit attribute on the procedure entity of the parent task server.
Permanent Transaction Exception Handling in Tasks
When a permanent transaction exception is generated in a task or is passed to a task, the action depends on whether the task that generates the exception is composable:
For a composable task, ACMSxp software:
1.Terminates the task.
2.Returns the permanent transaction exception to the client program.
For a noncomposable task, ACMSxp software:
1.Rolls back the current transaction.
2.If there is an applicable exception handler, executes the transaction exception handler.
3.If there is no applicable transaction exception handler in the called task, terminates the task and returns the transaction exception to the calling task or client program.
Fatal Transaction Exception Handling in Tasks
The type of exception returned depends on whether the called task that generates the exception is composable.
For a composable task, ACMSxp software terminates the task and returns a permanent transaction exception to the calling task.
For a noncomposable task, ACMSxp software:
1.Rolls back the transaction.
2.Terminates the execution of the task.
3.Returns a nontransaction exception to the calling task or client program.
AP-EXECUTION-FAULT Exception Class
The operation could not complete successfully because of either an error in application logic or a programming error.
This exception class indicates one of the following error conditions:
•The processing procedure specified by the processing procedure name in the CALL PROCEDURE (or in a nested procedure) contains an unhandled programming or logic error, such as an access violation or an unhandled divide-by-zero.
•The presentation procedure executed by the SEND, RECEIVE, or TRANSCEIVE exchange caused ACMSxp to generate an exception because of one of the following conditions:
-Access violation
-Unhandled divide-by-zero
-Other unhandled programming or logic errors caused by the execution of the presentation procedure
-Display error condition caused when the presentation procedure tried to access the display
•A client task called a noncomposable task to execute within the client task’s transaction.
•A client task called a composable task to execute independently from the client task’s transaction.
•The subscript used to reference an element in a fixed-length array is invalid (referring to A(n), where n < 1 or n > maximum size of array).
•The subscript used to reference an element in a variable-length array is invalid (referring to A(n), where n < 1 or n > the value of the DEPENDING ON field).
•The value of the DEPENDING ON field used when referencing an element of a variable-length array is invalid (the value of the DEPENDING ON field < minimum size of array or the value of the DEPENDING ON field > maximum size of array).
•The source and destination of a MOVE statement do not agree.
•The source field of a GET MESSAGE statement contains a value other than 0 or 1.
•IN message-group-name is specified and the value of source-field is 0 (for system).
•The exception class specified in a RESTART TRANSACTION or a RAISE EXCEPTION statement is not one of the standard predefined exception classes.
•The size of the workspace specified by the workspace name does not match the size of the target record identifier associated with the record queue. For a workspace or record that contains a variable-length array, the DEPENDING ON field determines the size of the workspace or record size.
•The value of the DEPENDING ON field was invalid when referring to a workspace or workspace field containing a variable-length array.
•The character set for the data type of the message text field cannot handle the human language of the message text.
•A DEQUEUE NEXT RECORD operation was unable to complete successfully because the previous operation was neither a DEQUEUE FIRST RECORD nor a DEQUEUE NEXT RECORD.
Respond to this exception class by correcting the application logic or programming error.
AP-INCOMPLETE-ERROR Exception Class
The task, presentation procedure, or processing procedure determines that the current operation cannot complete successfully because the data passed as arguments on the call are erroneous. The task, presentation procedure, or processing procedure wants to roll back any transactional resources modified during the operation.
This exception class indicates one of the following error conditions:
•Any exception code returned by the task, processing procedure, or presentation procedure that maps to this exception class in the message group
•This exception class returned by the task, processing procedure, or presentation procedure
Respond to this exception class as follows:
•Modify the input data and reexecute the called task, processing procedure, or presentation procedure.
•Based on the exception code, correct the problem that caused the permanent transaction exception.
•Record key events and any applicable data to the event log file.
AP-INVOCATION-FAULT Exception Class
The operation being requested cannot be started due to a specification or named record mismatch condition.
This exception class indicates one of the following error conditions:
•A specification mismatch occurred on a CALL PROCEDURE. The interface in the processing group specification for the called procedure that was used when processing the calling task into an executable task is incompatible with the interface in the called processing procedure.
•A specification mismatch occurred on a CALL TASK. The task group specification that was used when processing the calling task into an executable task is incompatible with the task group specification that was used when processing the called task into an executable task.
•A specification mismatch occurred on a SUBMIT TASK. The task group specification that was used when processing the submitting task into an executable task is incompatible with the task group specification that was used when processing the submitted task into an executable task.
•A specification mismatch occurred on a SEND, RECEIVE, or TRANSCEIVE exchange for a user-written SEND, RECEIVE, or TRANSCEIVE presentation procedure. The interface in the presentation group specification that was used when processing the calling task into an executable task is incompatible with the interface in the called presentation procedure.
•The send record name specified on the SEND exchange does not match the send record name specified in the forms system.
•The receive record name specified on the RECEIVE exchange does not match the receive record name specified in the forms system.
•The send record name or receive record name specified on the TRANSCEIVE exchange does not match the send record name or receive record name specified in the forms system.
•The receive control text specified using the exchange control text is of invalid format or length in the forms system.
•The send control text specified using the exchange control text is of invalid format or length in the forms system.
•The UUID in the task group specification used by the client program for the server task is not the same as the UUID used by the server task.
•The major version number used by the client program is not equal to the major version number used by the server task.
•The minor version number used by the client program is greater than the minor version number used by the server task.
Respond to this exception class as follows:
•Correct the task group, processing group, or presentation group specification that caused the specification mismatch to occur.
•Correct the task group, processing group, or presentation procedure in which the error occurred.
•Correct the forms system that caused the named record mismatch to occur.
•Correct the control text format or length in the forms systems.
AP-PROCESSING-FAULT Exception Class
The task, presentation procedure, or processing procedure determines that an error condition occurred doing the current operation. The operation may be successful if retried later.
This exception class indicates one of the following error conditions:
•The task, processing procedure, or presentation procedure returned an exception code that maps to this exception class in the message group definition.
•The task, processing procedure, or presentation procedure returned this exception class.
Respond to this exception class as follows:
•Based on the exception code, correct the problem that caused the nontransaction exception.
•Record key events and any applicable data to the event log file.
AP-RESPONSE-FAULT Exception Class
The operation being requested could not complete due to invalid results.
This exception class indicates one of the following error conditions:
•The results of the CALL PROCEDURE could not be returned to the task definition that called the processing procedure because of a syntax error.
•The results of the CALL TASK could not be returned to the calling task definition because of a syntax error.
•The results of the SEND, RECEIVE, or TRANSCEIVE exchange could not be returned to the task definition that called the presentation procedure because of a syntax error.
Respond to this exception class as follows:
•Correct the task group, processing group, or presentation group specification that caused the error condition to occur.
•Correct the task, processing procedure, or presentation procedure in which the error occurred.
•Correct the forms system that caused the error condition to occur.
ENV-EXECUTION-ERROR Exception Class
The requested operation began, but did not complete successfully because of an environment information problem. The operation may be successful if retried at some later time.
This exception class indicates one of the following error conditions:
•The task specified by the task name in the CALL TASK could not complete because of a system failure on the server TPsystem.
•The task specified by the task name in the CALL TASK could not complete and return results of the call because of a communications failure between the client TPsystem and the remote server TPsystem.
•The processing procedure specified by the processing procedure name in the CALL PROCEDURE could not complete because of a system failure on the TPsystem in which the task is executing.
•The presentation procedure executed by the SEND, RECEIVE, or TRANSCEIVE exchange could not complete due to a system failure on the TPsystem in which the task is executing.
•The presentation procedure executed by the SEND exchange could not complete due to the display not being available.
•The submitted task acceptor could not complete the forwarding operation and return results because of a communications failure.
Respond to this exception class as follows:
•Retry the operation at some later time when the TP system or system administration corrects the system failure problem.
•Retry the operation at some later time when the communications problem is corrected.
•If unsuccessful after retries, correct the problem based on the exception code that caused the exception.
ENV-EXECUTION-FAULT Exception Class
The requested operation began, but did not complete successfully, because of an environment information problem. A retry of the operation cannot be successful until the environment information problem is corrected.
This exception class indicates one of the following error conditions:
•The submitting TPsystem encountered a problem storing the submitted request on the request queue specified by the request queue name or defaulted to in SUBMIT TASK.
•The TPsystem in which the task is executing encountered a problem storing (enqueuing) an item into the record queue specified by the value of the record queue name in the ENQUEUE RECORD.
•The TPsystem in which the task is executing encountered a problem removing (dequeuing) an item from the record queue specified by the value of the record queue name in the DEQUEUE RECORD.
•The TPsystem in which the task is executing is unable to post the audit information to the event log.
•The submitted task acceptor could not complete the forwarding operation because of a problem encountered storing the submitted request onto the request queue.
Respond to this exception class by correcting the environment information.
ENV-INVOCATION-ERROR Exception Class
The operation being requested cannot be started because of the current setting of environment information or because system failure made the environment information unavailable. The operation may be successful if retried.
This exception class indicates one of the following error conditions:
•The processing procedure specified by the processing procedure name in the CALL PROCEDURE is disabled.
•The processing group specified by the processing group name in the CALL PROCEDURE is not available due to a system failure.
•The task specified by the task name in the CALL TASK could not be started due to the task instance high-water mark being exceeded on the server TPsystem.
•The task specified by the task name in the CALL TASK is disabled.
•The task specified by the task name in the CALL TASK could not be started because the server TPsystem was not available, because the system failed or was not started.
•The task group specified by the task group name in the CALL TASK is not available due to a system failure.
•The task specified by the task name in the CALL TASK could not be started due to a communications failure.
•The request queue is disabled.
•The presentation group specified by the presentation group name in the SEND, RECEIVE, or TRANSCEIVE exchange is not available because of a system failure.
•The display used by the SEND, RECEIVE, or TRANSCEIVE exchange is off line and not currently available for use.
•The submitted task acceptor is not available because of a system failure.
•The submitted task acceptor is not available because of a communications failure.
Respond to this exception class as follows:
•Retry the operation later when the TPsystem or system manager may have modified the environment attribute to allow for successful operation.
•Retry the operation later when the communications problem may have been corrected.
•Retry the operation at some later when the TPsystem or system manager may have corrected the system failure problem.
•If unsuccessful after retrying the operation, correct the problem using information in the exception code that caused the exception.
ENV-INVOCATION-FAULT Exception Class
The operation being requested cannot be started because of an environment information problem. A retry of the operation cannot be successful unless either the environment information is corrected or the syntactical reference to the environment information is changed.
This exception class indicates one of the following error conditions:
•The processing group specified by the processing group name in the CALL PROCEDURE is not defined within the environment information of the TPsystem in which the task is executing.
•The task group specified by the task group name in the CALL TASK is not defined within the environment information of the server TPsystem.
•The task specified by the task name in the CALL TASK could not be started because the requested access to the called task was denied.
•The destination specified by the destination name in the CALL TASK is not defined within the environment information of the TPsystem in which the task is executing.
•If the destination was not explicitly specified in the CALL TASK, the destination specified by the task group name is not defined within the environment information.
•The request queue is not defined within the environment information of the submitter TPsystem.
•The presentation group specified by the presentation group name in the SEND, RECEIVE, or TRANSCEIVE exchange is not defined within the environment information of the TPsystem in which the task is executing.
•The broadcast list specified by the broadcast list name in the DISPLAY exchange attribute for a SEND exchange is not defined within the environment information of the TPsystem in which the task is executing. A second task call was executed using a dialog that accepts only a single task call for each dialog.
Respond to this exception class as follows:
•Correct the environment problem by modifying the environment information to allow a successful operation.
•Correct the API problem by modifying the STDL source to allow a successful operation.
FATAL-EXECUTION-FAULT Exception Class
The task, presentation procedure, or processing procedure determines that the current task cannot complete successfully.
This exception class indicates one of the following error conditions:
•An exception code was returned by the task, processing procedure, or presentation procedure that maps to this exception class in the message group.
•This exception class was returned by the task, processing procedure, or presentation procedure.
Respond to this exception class as follows:
•Check the exception code and correct the problem that caused the fatal transaction exception.
•Write key events and any applicable data to the event log file.
FATAL-TIMEOUT-FAULT Exception Class
The operation in progress failed to complete before an applicable time limit.
This exception class indicates that the value set for the CPU time limit attribute of the procedure entity was exceeded. The CPU time limit attribute is used to detect infinite loops.
Respond to this exception class as follows:
•Correct the problem that caused the operation not to complete within the allotted CPU time.
•Write key events and any applicable data to the event log file within the operation that failed to complete.
•Modify the current value of the CPU time limit attribute.
Refer to the Developing and Managing Applications for information on enabling infinite loop detection.
INVALID-INPUT-ERROR Exception Class
The called task, processing procedure, or presentation procedure determines that the data passed as arguments on the call was erroneous.
This exception class indicates one of the following error conditions:
•Any exception code returned by the task, processing procedure, or presentation procedure that maps to this exception class in the message group
•This exception class returned by the task, processing procedure, or presentation procedure
Respond to this exception class as follows:
•Modify the input data.
•Retry the operation.
NO-OUTPUT-ERROR Exception Class
The requested operation was unable to return the requested data.
This exception class indicates one of the following error conditions:
•A DEQUEUE RECORD specifies BY KEY or IDENTIFIER. No record is found and no data is returned.
•The value of the message number specified in the GET MESSAGE did not match a message number defined in the message group definition. No message text is returned.
•Any exception code returned by the task, processing procedure, or presentation procedure that maps to this exception class in the message group.
•The value of the message group UUID specified did not match a known exception group or the value of the message group name did not match a known message group definition.
•This exception class returned by the task, processing procedure, or presentation procedure.
Respond to this exception class as follows:
•Take an alternate action.
•Retry the operation with different data.
REQUEST-TIMEOUT-ERROR Exception Class
The requested operation failed to complete before an applicable time limit. This exception class indicates that the value of the exchange time limit attribute of the procedure entity is exceeded.
TXN-FAILURE-ERROR Exception Class
The current transaction failed to commit successfully.
This exception class indicates one of the following error conditions:
•One of the resource managers participating in the transaction was unable to commit the transaction.
•One of the resource managers participating in the transaction failed to acknowledge a message when attempting to commit the transaction.
Respond to this exception class, based on the exception code, as follows:
•Correct the problem that prevented the transaction from committing.
•Retry the operation.
TXN-INCOMPLETE-ERROR Exception Class
The task, presentation procedure, or processing procedure determines that the current transaction cannot be completed successfully, but may be successful if retried.
This exception class indicates one of the following error conditions:
•Any exception code was returned by the task, processing procedure, or presentation procedure that maps to this exception class in the message group definition.
•This exception class was returned by the task, procedure, or presentation procedure.
Respond to this exception class as follows:
•Based on the exception code, correct the problem that caused the transient transaction exception.
•Record key events and any applicable data to the event log file.
TXN-TIMEOUT-ERROR Exception Class
The transaction in progress failed to complete before an applicable time limit set through the management interface. This exception class indicates that the time taken in the transaction exceeds the value of the transaction time limit attribute of the procedure entity. The transaction time limit attribute is used to detect deadlocks.
This exception class is not delivered to an exception handler unless the transaction retry limit attribute of the procedure entity is exceeded or a nontransactional exchange is performed during the execution of this transaction.
Respond to this exception class as follows:
•Correct the problem that caused the operation not to complete in the allotted transaction time.
•Record key events and any applicable data to the event log file.
•Review the value of the transaction time limit attribute on the procedure entity.
See the Developing and Managing Applications for information about enabling transaction restartability and enabling deadlock detection.
RELATED INFORMATION
Syntax: exception_handler(1), raise_exception(1), reraise_exception(1), restart_transaction(1), workspace(1), workspace_field(1)