Click above to get retro games delivered to your door ever month!

 Transaction tracking functions overview
------------------------------------------------------------------------------
 Novell's Transaction Tracking System (TTS) has been a successful part of
 NetWare for many years. TTS allows more than one workstation to protect its
 own transactions while operating in a multi-user environment. If a
 workstation crashes, or the connection fails during a transaction, any
 changes made by the workstation to the database files can be cancelled or
 "backed out" without affecting other users. The Novell Transaction Tracking
 System works in the following way:

 .  A transaction is started with a call to the TTS, or when a certain
 threshold is passed.
 .  A workstation program writes data to a file on the file server.
 .  The file server first stores the new data in main cache memory. At
 this stage the file itself remains unchanged.
 .  The file server then scans the file to find the old data that the
 new data is about to change. It copies this old data into main cache
 memory, also storing the name of the file, its path, and the offset and
 length of the old data. At this stage the file itself still remains
 unchanged.
 .  The file server then writes the old data, along with the filename
 and path etc., from main cache memory to a special file called the
 transaction work file. This file is a hidden system file normally located
 in the root directory of Volume SYS, unless told otherwise at installation
 time.

 .  The file server then writes the new data from main cache memory to
 the file itself, at which point the data file changes to reflect the
 updated information.
 .  Steps 2 through 6 are repeated every time the workstation attempts
 to write to a file on the file server. The transaction work-file grows
 larger and larger as more and more writes are made.
 .  The transaction is ended with a call to the TTS or when another
 threshold is passed.

 For example, a single transaction may consist of creating a customer
 invoice with multiple records and updating the customer balance in the
 customer master file.
 When the transaction is ended, the old data stored in the transaction work
 file is scrapped and the transaction is said to have been successful.
 However, if during the transaction the workstation crashes or loses its
 connection, the file server will write all the old information from the
 transaction work file back to the data file, thereby restoring it to the
 condition it was in before the transaction was started. This is called
 "Backing Out".
 There are two types of transaction implemented by TTS - implicit and
 explicit.
 An implicit transaction is started, firstly if the data file is flagged
 transactional using the Novell extended file attributes, and secondly when
 the file server sees a predefined number of concurrent record locks
 implemented. This can be the number of locks implemented by the workstation
 or just the program ( for multitasking operating systems such as Windows ).
 For example if the workstation lock threshold is set to 5, this means a
 transaction will not be started unless there are more than 5 concurrent
 record and/or file locks. The transaction is not ended until ALL the locks
 are released. The workstation lock threshold can be set using the NOVLIB
 function TTSWSThresholdSet() and the program threshold can be set using
 TTSAppThresholdSet().

 An explicit transaction is where the workstation issues a direct system
 call to the Netware operating system to start a transaction and
 subsequently end the transaction. This can be done using the NOVLIB
 functions TTSBegin() to start the transaction, TTSEnd() to end the
 transaction and TTSAbort() to abort the transaction. All the files to be
 tracked must be flagged TRANSACTIONAL, using the FLAG.EXE command line
 utility.

 CA-Clipper:

 TTS does have some unfortunate restrictions when used in conjunction with
 CA-Clipper. Firstly TTS has difficulty with the 1 billion + recno() byte
 locking scheme used by CA-Clipper because TTS expects to see byte range
 locks that are within the file.
 When TTS is active inside a CA-Clipper program, it imposes physical locks
 on the regions being written to, in addition to the logical locks performed
 by CA-Clipper. Due to the way CA-Clipper writes the .DBF files, the
 physical locks can restrict the use of the program to only one user with an
 active transaction at any point in time.