begin {work|transaction} {name} {then|else statement.block}

work

Optional and is provided only for SQL compatibility.

transaction

Optional and is provided only for SQL compatibility.

name

Name of the transaction. This name displays when using the TCL transaction utility status option to monitor transaction processing, or when the system is recovering after a halt. The name makes it easier to identify work-in-progress in these situations.

Variable

Description

@transaction

This numeric value is nonzero when a transaction is active.

@transaction.ID

Current transaction.ID number, or zero if no transaction is active.

@transaction.name

If name is specified in the begin work statement, this variable contains that name. Null if no transaction is active.

NOTE

Nested transactions are not allowed and cause the begin work statement to fail.

execute

Executes a system command. No special checking is done on executed system-level commands, and no atomicity is asserted by the system. The programmer is responsible for assuring that all executed retrievals are atomic by performing the necessary filelock and readu statements before invoking execute. Updates performed by an executed system command do not participate in the transaction. These execute operations generate a run-time abort if attempted within a transaction: create-file, clear-file, delete-file, create-index, delete-index, and resize-file.

filelock

For the FSI: Not Supported. Sets an exclusive lock on a file disallowing other users from updating or locking that file. It is necessary to execute this statement before an operation that can reference the file sequentially during a transaction.

fileunlock

For the FSI: Not Supported. Releases a file lock. This statement is ignored during a transaction because all locks are held until the transaction completes.

key

Returns index information. This operation never participates in a transaction. Index entries are never updated until commit time, and no user-specific cache is provided. This means that it is invalid to access index entries for records that have been updated within a transaction before that transaction has been committed. Also, if strict transaction ordering is required, it is necessary to set a file lock prior to using the index.

read/readu

Reads a record. By default, this operation sees updates already made by the process, but not yet committed (unless transaction cache off has been run in the program previously). The readu form should always be used within a transaction to guarantee serialized schedules.

readnext

Reads an item-ID from a select list. To use this validly within a transaction, each readnext must be followed by a read of the associated item-ID. This allows verification that the item has not been deleted within the transaction. Items that have been inserted within the transaction are returned by the readnext after all of the pre-transaction IDs are exhausted.

release

Releases item locks. This operation is ignored during a transaction because all locks are held until commit or rollback.

select

Selects a list of items. To enforce transactions that are serialized, the user must lock the specified file before performing the select. If the select list is based on a prior execute, then the filelock must be performed prior to that execute.

write

Writes a record. This operation always participates in the transaction (that is, the effects of the write, including the release of any associated locks, are not committed to the database until the commit). The same rule applies to all variants of the write (writeu, writev, writevu, matwrite, and matwriteu).

stop

Stops the program. If a transaction is active, then the stop statement or any other condition that terminates the program causes the equivalent of a rollback to occur.