begin work Statement

The begin work statement starts a transaction.

Syntax

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

Parameter(s)

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.

Description

A transaction is used to perform a series of updates to the database in an atomic manner. To begin the sequence, use the begin work statement followed by the desired updates. To commit the updates to the database, use the commit work statement. If a problem develops during the series of writes that prevent the correct completion of the transaction, use the rollback work statement to undo the changes.

Once a transaction is active, the variables below contain:

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.

These operations perform differently in a transaction:

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.

The system-coldstart procedure automatically rolls backward any pre-commit transactions and rolls-forward (if possible) any post-commit transactions if the system halts unexpectedly.

These features are not currently supported within a transaction:

Using bridge correlatives.
Using remote (distributed) files.
Using non-D3 files.

BASIC Transaction Bracketing

For the FSI: BASIC Transaction Bracketing is supported in Flash only.

For the VME: BASIC Transaction Bracketing is supported in both nonFlash and Flash. Operations on OSFI files may be included in a transaction, but in the event of recovery from a system failure (rollback or roll forward) those operations will be ignored because the file handles to the remote files will no longer be valid.