IFBOUT (HLI function): Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (link repair)
No edit summary
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The conventions used on this page are described in [[HLI: Function summary#Function call notation conventions|Function call notation conventions]].


==Function==
==Summary==
<p>
<dl>
The IFBOUT call (BACK OUT) backs out an incomplete transaction on the thread or threads that are active for the transaction in which the thread participates.</p>
<dt>Description</dt>
 
<dd>The IFBOUT call (BACK OUT) backs out an incomplete transaction on the thread or threads that are active for the transaction in which the thread participates.</dd>
==Thread type==
<dt>Thread type</dt>
multiple cursor IFSTRT, single cursor IFSTRT
<dd>multiple cursor IFSTRT, single cursor IFSTRT</dd>
<dt>IFCALL function number</dt>
<dd>71</dd>
</dl>


==Syntax==
==Syntax==
===Full syntax (71)===
<p class="syntax">IFBOUT(RETCODE)</p>
<p class="syntax">IFBOUT(RETCODE)</p>


===Compile-only syntax===
<dl>
<p>
<dt>Compile-only form</dt>
A compile-only form of IFBOUT is not available.</p>
<dd>Not available</dd>
<dt>Execute-only form</dt>
<dd>Not available</dd>
</dl>


===Execute-only syntax===
<p>
An execute-only form of IFBOUT is not available.</p>
===Parameters===
<table>
<table>
<tr class="head">
<tr class="head">
Line 31: Line 32:
</table>
</table>


==Notes and tips==
==Usage notes==
<p>
<p>
Use the IFBOUT call to activate the Model 204 backout mechanism. The backout function is valid only for transaction backout (TBO) files. </p>
Use the IFBOUT call to activate the Model 204 backout mechanism. The backout function is valid only for transaction backout (TBO) files. </p>
Line 48: Line 49:
<p>
<p>
Single cursor IFSTRT threads that are started in a multithreaded IFAM2 or IFAM4 HLI job participate in a multithreaded transaction. See [[HLI: Transactions]] for more information about transaction processing in an HLI job. </p>
Single cursor IFSTRT threads that are started in a multithreaded IFAM2 or IFAM4 HLI job participate in a multithreaded transaction. See [[HLI: Transactions]] for more information about transaction processing in an HLI job. </p>
<p>IFBOUT is not valid on a read-only type thread, that is, any thread that is started by IFSTRT with an update indicator of 0 for an IFAM2 / IFAM4 connection. </p>
===Record locking behavior===
<p>
IFBOUT releases the lock pending updates (LPU) exclusive lock on updated records and the single record enqueue (SRE) on the current record (if one exists) that were obtained by this thread. The transaction is ended for all participating threads and the backout and constraints log are freed. </p>
<p>
Found sets are not released and the current record does not change. In a multithreaded transaction the LPU and SRE locks obtained by other threads are still held. </p>
<p>
To ensure that all of the records and resource locks are released after the IFBOUT call executes in a multithreaded transaction, issue IFCMMT on all of the other single cursor IFSTRT threads participating in the transaction. </p>
<p class="note"><b>Note:</b> A completed transaction cannot be backed out.</p> <p>For more information about transaction backout, see [[HLI: Transactions]].</p>


==Completion return code (RETCODE)==
==Completion return code (RETCODE)==
<p>
IFBOUT is not valid on a read-only type thread, that is, any thread that is started by IFSTRT with an update indicator of 0 for an IFAM2 / IFAM4 connection. </p>
<p>
<p>
If the IFBOUT call is unsuccessful, Model 204 returns the following error completion codes:</p>
If the IFBOUT call is unsuccessful, Model 204 returns the following error completion codes:</p>
Line 68: Line 78:
</tr>
</tr>
</table>
</table>
===Record locking behavior===
<p>
IFBOUT releases the lock pending updates (LPU) exclusive lock on updated records and the single record enqueue (SRE) on the current record (if one exists) that were obtained by this thread. The transaction is ended for all participating threads and the backout and constraints log are freed. </p>
<p>
Found sets are not released and the current record does not change. In a multithreaded transaction the LPU and SRE locks obtained by other threads are still held. </p>
<p>
To ensure that all of the records and resource locks are released after the IFBOUT call executes in a multithreaded transaction, issue IFCMMT on all of the other single cursor IFSTRT threads participating in the transaction. </p>
<p class="note"><b>Note:</b> A completed transaction cannot be backed out.</p> <p>For more information about transaction backout, see [[HLI: Transactions]].</p>


==Coding example (COBOL)==
==Coding example (COBOL)==
Line 91: Line 92:
   CALL "IFBOUT" USING RETCODE.</p>
   CALL "IFBOUT" USING RETCODE.</p>


[[Category: HLI function calls]]
[[Category: HLI functions]]

Latest revision as of 22:04, 12 July 2016

The conventions used on this page are described in Function call notation conventions.

Summary

Description
The IFBOUT call (BACK OUT) backs out an incomplete transaction on the thread or threads that are active for the transaction in which the thread participates.
Thread type
multiple cursor IFSTRT, single cursor IFSTRT
IFCALL function number
71

Syntax

IFBOUT(RETCODE)

Compile-only form
Not available
Execute-only form
Not available
Parameter Description
RETCODE [O,i,r] The Model 204 return code is the required output parameter. The code is a binary integer value.

Usage notes

Use the IFBOUT call to activate the Model 204 backout mechanism. The backout function is valid only for transaction backout (TBO) files.

You can issue the IFBOUT call on the following IFSTRT threads:

  • In IFAM2/IFAM4, a single cursor IFSTRT thread with update privileges or a multiple cursor IFSTRT thread.

    Note: You cannot issue IFBOUT on a single cursor IFSTRT thread with read-only privileges, that is, with a thread type indicator of 0.

  • In IFAM1, a single cursor or multiple cursor IFSTRT thread.

    Note: Only the thread, or threads, that participate in the current transaction are backed out. Any IFAM1 type IFSTRT thread involves a single-threaded transaction.

Single cursor IFSTRT threads that are started in a multithreaded IFAM2 or IFAM4 HLI job participate in a multithreaded transaction. See HLI: Transactions for more information about transaction processing in an HLI job.

IFBOUT is not valid on a read-only type thread, that is, any thread that is started by IFSTRT with an update indicator of 0 for an IFAM2 / IFAM4 connection.

Record locking behavior

IFBOUT releases the lock pending updates (LPU) exclusive lock on updated records and the single record enqueue (SRE) on the current record (if one exists) that were obtained by this thread. The transaction is ended for all participating threads and the backout and constraints log are freed.

Found sets are not released and the current record does not change. In a multithreaded transaction the LPU and SRE locks obtained by other threads are still held.

To ensure that all of the records and resource locks are released after the IFBOUT call executes in a multithreaded transaction, issue IFCMMT on all of the other single cursor IFSTRT threads participating in the transaction.

Note: A completed transaction cannot be backed out.

For more information about transaction backout, see HLI: Transactions.

Completion return code (RETCODE)

If the IFBOUT call is unsuccessful, Model 204 returns the following error completion codes:

Code Error condition
4 IFBOUT called for a non-transaction backout (non-TBO) file or for a read-only thread.
40 IFBOUT call is encountered on a single cursor IFSTRT thread having read-only privileges.

Coding example (COBOL)

WORKING-STORAGE SECTION. 01 ARGS-FOR-CALL. 05 RETCODE PIC 9(5) COMP SYNC. . . . PROCEDURE DIVISION. . . . CALL "IFBOUT" USING RETCODE.