Enscribe Programmer's Guide
1); ! positioning-mode = generic
! Note: In practice, it is only necessary to call
! KEYPOSITION once to establish the desired key range.
DO
BEGIN
Error := BEGINTRANSACTION(Trans^Tag); ! Start trans.
CALL READUPDATELOCK(QF^Num, Buffer, Rec^Len, Byte^Count);
! Read the next record
IF = THEN ! Check for errors
BEGIN ! No error occurred
Data[0] ':=' Buffer[Key^Len] FOR Byte^Count - Key^Len;
RETURN Byte^Count; ! Extract data and return
! Note: An ENDTRANSACTION call should be executed when
! the current queue record has been processed.
END;
!
! Process the READUPDATELOCK error
!
! Determine which error occurred
status := FILE_GETINFO_ (QF^Num, Error);
IF Error = 162 then ! Timeout occurred
BEGIN
status := ENDTRANSACTION; ! Release this transaction
END
ELSE ! Some other error
status := ABORTTRANSACTION; ! Abort this transaction
RETURN -1;
END ! Execute one dequeue operation
UNTIL 0;
END; ! PROC Get^Generic
Communication Path Errors
For queue file errors in the range of 200 through 211 (path loss, takeover, and CPU failure), and
for network path errors in the range of 246 through 249, the file system attempts recovery only if
the sync depth of the open file is greater than zero. However, dequeuing operations
(FILE_READUPDATELOCK64_/READUPDATELOCK[X] calls) require a sync depth of zero; therefore,
the file system cannot recover dequeuing failures due to path-related errors.
A process that only writes to (that is, it does not dequeue from) a queue file can ensure a recovery
attempt by setting the sync depth to one or greater (depending on how many outstanding
FILE_WRITE64_/WRITE[X] operations it intends to perform).
If the sync depth is zero but the file is audited, an application can recover from a path loss condition
by aborting the pending transaction.
Processes that dequeue (call FILE_READUPDATELOCK64_/READUPDATELOCK[X]) from an audited
queue file can invoke ABORTTRANSACTION and retry the
FILE_READUPDATELOCK64_/READUPDATELOCK[X] operation. This will ensure that if a record
was deleted prior to the failure, it will be reinserted. Note, however, that all records modified
during the current transaction will be restored. Therefore, the application must be capable of
retrying the entire aborted transaction from the beginning.
Processes that access unaudited queue files have little means of recovery from path-related errors.
There are two possible error conditions that could result in lost or extra records in a queue file:
• A FILE_READUPDATELOCK64_/READUPDATELOCK[X] operation could encounter a path-related
error after a record was deleted. In this case, the contents of the record would be lost.
• A FILE_WRITE64_/WRITE[X] operation that encounters a path-related error might have
successfully inserted a record into the file. An attempt to retry the same
FILE_WRITE64_/WRITE[X] operation would result in the insertion of a second copy of the
same record with a different unique key value (different timestamp value).
Communication Path Errors 121