Syntax
ABORT [ literal [ literal | object_name ] ]
Parameters
literal
The message to display.
This parameter is restricted to a maximum length of 50 characters.
literal or object_name
A string expression naming the class or ispec to recall following the termination. Acceptable values include: a classname, an ispecname, a quoted alias, or an attributename, where the attribute contains the class’s alias. For example, where “Customer” is the name of an ispec to recall, and “Cust” is the alias name, valid values are:
Abort "ErrorMessage" "Customer" Abort "ErrorMessage" "Cust" Abort "ErrorMessage" Customer Move "Cust" RecallIspec Abort "ErrorMessage" RecallIspec
In MCP systems, this cannot be a national string.
Description
The Abort logic command terminates current transactions and restores the database.
To enable the Abort logic command to roll back the Glb.Work built-in segment attribute, set the segment's Preserve Session Data property to true.
If a message literal is not specified, the message (which might be translated), "ABORTED: System commanded Abort of this transaction" is displayed.
Abort and ispecs
The following issues are encountered while using the Abort logic command in ispec methods:
Any incomplete transactions are rolled back and session data might be lost. Consequently, any Auto or Flag logic statements executed by the ispec are also rolled back, except external automatic entries, as they do not use two-phase commit.
If executed in a Construct method, the method terminates and displays the ispec user interface.
If executed after the Glb.Param built-in segment attribute is set, its value is passed to the ispec.
If executed after the value of the Glb.Work built-in segment attribute has changed, it is rolled back to its value at the start of the transaction.
If an identifier is specified:
Updates of the specified ispec are performed, even though the calling ispec was rolled back.
If the Abort logic statement is invoked by a copy ispec or copy event that is processing the last iteration (when Glb.Copy = Glb.MaxCopy), the copy ispec or copy event is not recalled and the message is displayed on the user interface instead.
In all other cases, the copy ispec or copy event is recalled and the message is displayed on the user interface.
For MCP-based and Windows-based systems, the screen remains unaltered, and the message will be displayed on the Status line.
If an identifier is not specified, the message is displayed on the status line.
Abort and reports
The following are encountered while using the Abort logic command in report methods:
Reports are rolled back to the last commit point; for example, a CriticalPoint or Sleep logic statement. Updates up to the last commit point are retained, regardless of the method of report initiation.
After a report is aborted and rolled back, it is your responsibility to restart it.
To retain recovery records in the database, set the segment's Extended Report Recovery property to true.
Abort when application is an OLTP Server
When processing an OLTP-originated transaction, the Abort command aborts the local transaction processing, rolls back any changes made to the local database, and notifies the client system of the failure.
The behavior of the database rollback process depends on the setting of Two phase commit (2PC) in your application, and whether any descendent transactions are part of a Global transaction that includes the aborting server. The term descendent transaction refers to a further OLTP transaction initiated by the server (as a client).
For descendent transactions:
If any descendent transaction is part of the client Global transaction (refer to 2PC option), it is aborted and rolled out of its local database.
If any descendent transaction is not part of the client transaction (refer to 2PC option), it is not aborted and not rolled back. Completed non-2PC transactions is retained, even though their initiating client transaction will have been aborted.
Non-OLTP Automatic Entry transactions depend on whether 2PC is used. If 2PC is used, the descendent transactions are aborted and rolled back. If 2PC is not used, descendent transactions will have been committed previously, and cannot be rolled back.
For the client of the aborting server:
If the client is an application that is using 2PC, its transaction will be aborted and rolled back. Any logic following the command is not executed, any other descendent 2PC OLTP transactions of the client transaction are aborted and rolled out of their local databases, and any other descendent non-2PC OLTP transactions are not aborted or rolled back. Completed non-2PC transactions are retained, even though their client transaction has been aborted.
If the client is an application that is not using 2PC, it is notified that the server transaction aborted. Glb.Status is set to five asterisks (*****), and Glb.HubStatus is set to TRANS.AbortED.
If the client is not a Runtime application, it will receive a TPESVCFAIL result, and its transaction will be marked as ROLLBACK REQUIRED if the message was a part of the global transaction of the client.
Abort when Application is an OLTP Client
The Abort command aborts the local transaction processing, and roll back any changes made to the local database.
If the local transaction initiated an OLTP global transaction, a rollback (TXROLLBACK) is performed, and any descendent 2PC OLTP transactions are also aborted and rolled out of their local databases.
Descendent non-2PC OLTP transactions are not aborted or rolled back. Completed non-2PC transactions are retained, even though their parent transaction has been aborted.
Non-OLTP Automatic Entries continue to function as in previous releases. Abort and rollback depend on whether or not you used 2PC with the transactions:
If you used 2PC, descendent transactions are aborted and rolled back.
If you did not use 2PC, descendent transactions will have been previously committed, and cannot be rolled back.
Abort in Messenger Cycle
When an Abort command is executed in a Messenger Cycle the transaction is aborted and any database updates performed in the transaction prior to executing the Abort command are rolled back.
Abort command has a variant, with an optional clause to specify the name of the Ispec to be recalled after aborting the current Ispec. This does not apply for Messenger cycle, and hence if the additional clause is specified, it would be ignored.
Examples
Example 1
This example aborts the transaction and displays the message "Error 1 encountered" if Error1 has the value "Yes".
If Error1 = "Yes" Abort "Error1 encountered" EndExit
Example 2
This example aborts the transaction, displays the default message, and recalls the Errs ispec if Error2 has the value "Yes".
Note: When recalling an ispec and also using the default message, an additional set of inverted commas containing at least one space character is required, preceding the ispec identifier.
If (Error2 = "Yes")
Abort " " Errs
EndExit
Example 3
This example aborts the transaction in a Messenger Cycle, rolls back the database update performed in the transaction, and displays the message "Abort in Messenger".
Determine Actual PersistentClass persistentClass.StringData := "thisData" persistentClass.Update() End Abort "Abort in Messenger"